02-16-2008 01:53 AM - edited 03-15-2019 08:52 AM
Hi,
i am wondering if this is true
Bandwidth=384=>CIR=384*0.95=364.8=100% available bandwidth
on the LLQ we can configure 75% of the 364.8 and the 25% is for the default queue
for instance:
class rtp
priority percent 50
class sig
bandwidth percent 10
class any
bandwidth percent 15
class class-default
fair-queue
++++++
map-class frame-relay FRTS
frame-relay cir 364800
frame-relay mincir 182400
frame-relay bc 3648
frame-relay be 0
++++++
Is this right above
1) Why we only use 95% of the existing bandwidth
2)what drives the FRTS config, i mean the min CIR is half the CIR and the bc is 1% of the CIR: this is a very commun configuration !!!!
Good day
Solved! Go to Solution.
02-18-2008 02:28 PM
Ok - back to basics here about frame relay.
If you owned the full bandwidth of the link you could transmit at the actual line (access) rate. This would be a leased line.
Since bandwidth is (was) expensive, providers offered a Committed Information Rate (CIR) where they guarantee to transmit a certain number of bits every second. The CIR is always less than the actual access rate.
Frame relay traffic shaping (FRTS) allows you to use this CIR better. To ensure you don't send over the CIR, FRTS allows you to shape the traffic rate to the cponfigured CIR - this ensures you don't exceed the rate at which the provider will transport your data without droppoing it.
As an example, if you have a 256K access rate and a 128K CIR, you can reliably transmit traffic for exactly half a second over any one second period. This is what the minCIR value sets.
If you want to run the risk of sending above what you purchased off the provider, you can set a higher rate by configuring the CIR to be above your minCIR. The router will send at this rate until it gets some kind of notification (by BECN or FECN) , it will then drop back down to minCIR.
The Bc sets the shaping interval - in the example above we COULD send 256Kbits over a 1 second period, but the minCIR ensures we only send 128Kbits every second.
The question is should we send this 128K in the first 0.5 seconds, or should we break it into smaller intervals and shape the traffic over the full 1 second period. We still send 128K over the 1 second period, but we send it as smaller groups with small periods in between.
These smaller groups of traffic are set by the Bc. For voice , the best setting is a Bc of 1/100th of the minCIR. This sets the shaping interval Tc based on this formula -
Tc=Bc/minCIR
so in this case Tc=1280/128000 = 0.01 seconds , or 10msec.
So we have broken the actual minCIR down to 100 seperate groupings of 1280 bytes, which will be sent in any 10msec period.
We still send 128Kbits of traffic over a 1 seconds period, but it gets sent as 100 seperate groups of 1280 bits.
Having 100 seperate periods to send the voice is perfect - a normal voice call sends 50 packets per second, so you can fit 50 voice packets and 50 data intervals - the traffic flow is very smooth, and overall jitter is minimised. Since you do not exceed the CIR the provider offers you, there is no risk of packet loss. The traffic shaping minimises overall jitter of the voice traffic and prevents packet loss affecting the voice quality.
Hope this explains things :-)
02-18-2008 03:44 AM
Some service providers offer the CIR based on bit rate at layer 2 , so you need to take into account the frame relay headers in the frame relay traffic shaping. This would/could explain the 5% difference.
Secondly, for VOIP traffic shaping , you should set the CIR and minCIR to be the actual CIR purchased off the service provider. The minCIR is the minimum bit rate the router will drop down to , so this is the CIR the SP gives you. If you want to shape above CIR , then you set a maximum value in the actual CIR. The problem is that the router will only drop down to the minCIR when it gets some kind of notification via FECN or BECN. By the time the router has been told about the network congestion via the FECN or BECN, your voice traffic will have likely been dropped and you get voice QOS issues.
For VOIP, you set the Bc to be 1/100th of CIR to give an interval of 10msec. This seperates a 1 second period into 100 intervals of 10msec, which is absolutely perfect for fitting voice packets (at 50 packets per second) in one interval, data in the next interval , then voice in the next interval ... 50 voice intervals and 50 data intervals.
For your shaping class above, you should use the following (assuming the purchased CIR is around 192Kbps and you want to take into account layer 2 headers)
map-class frame-relay FRTS
frame-relay cir 182400
frame-relay mincir 182400
frame-relay bc 1824
frame-relay be 0
no frame adaptive shaping
service-policy
It's possible your SP may allow you to run above the CIR - you can always adjust the FRTS class to test this.
Refer here for more details -
http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a00800d6788.shtml
02-18-2008 07:08 AM
Hi again,
very interesting info above.
for point 1: checked.
for second point, i read it like three time but no success ;-) i think i will need to read over the Bc but where the 50 packets comes from
last part:
1) where you enable service-policy under FRTS you are using 182400 as maximum for configuration of 75%.
2) you have no frame adaptive shaping: is it on by default, and why we are disabling it?
Good day
02-18-2008 02:28 PM
Ok - back to basics here about frame relay.
If you owned the full bandwidth of the link you could transmit at the actual line (access) rate. This would be a leased line.
Since bandwidth is (was) expensive, providers offered a Committed Information Rate (CIR) where they guarantee to transmit a certain number of bits every second. The CIR is always less than the actual access rate.
Frame relay traffic shaping (FRTS) allows you to use this CIR better. To ensure you don't send over the CIR, FRTS allows you to shape the traffic rate to the cponfigured CIR - this ensures you don't exceed the rate at which the provider will transport your data without droppoing it.
As an example, if you have a 256K access rate and a 128K CIR, you can reliably transmit traffic for exactly half a second over any one second period. This is what the minCIR value sets.
If you want to run the risk of sending above what you purchased off the provider, you can set a higher rate by configuring the CIR to be above your minCIR. The router will send at this rate until it gets some kind of notification (by BECN or FECN) , it will then drop back down to minCIR.
The Bc sets the shaping interval - in the example above we COULD send 256Kbits over a 1 second period, but the minCIR ensures we only send 128Kbits every second.
The question is should we send this 128K in the first 0.5 seconds, or should we break it into smaller intervals and shape the traffic over the full 1 second period. We still send 128K over the 1 second period, but we send it as smaller groups with small periods in between.
These smaller groups of traffic are set by the Bc. For voice , the best setting is a Bc of 1/100th of the minCIR. This sets the shaping interval Tc based on this formula -
Tc=Bc/minCIR
so in this case Tc=1280/128000 = 0.01 seconds , or 10msec.
So we have broken the actual minCIR down to 100 seperate groupings of 1280 bytes, which will be sent in any 10msec period.
We still send 128Kbits of traffic over a 1 seconds period, but it gets sent as 100 seperate groups of 1280 bits.
Having 100 seperate periods to send the voice is perfect - a normal voice call sends 50 packets per second, so you can fit 50 voice packets and 50 data intervals - the traffic flow is very smooth, and overall jitter is minimised. Since you do not exceed the CIR the provider offers you, there is no risk of packet loss. The traffic shaping minimises overall jitter of the voice traffic and prevents packet loss affecting the voice quality.
Hope this explains things :-)
02-18-2008 10:43 PM
Perfect, yap everything is clear now.
thanks a lot and have a good day
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: