From: R.J.Neill Craven (ncraven@xxxxxxxxxxxxxxx)
Date: Thu Oct 18 2001 - 12:51:52 GMT-3
10ms is 1/100 of a second, so the simple answer is you divide the CIR
by 100 to find the Bc. Therefore, CIR 64000bps implies Bc of 640
bits. Be sure to pick a fragment size which is consistent with the 10
ms rule as well. For example, a 1500 byte packet takes 187.5 ms to
process on a 64Kbps interface. Obviously, we cannot allow a big
packet to block the head of the line for such a long time. Somewhat
like you wanting to get cash from an ATM but the person currently at
the machine reaches for an envelope. So you will want to make sure no
fragment takes longer than 10 ms to transmit. For a 64Kbps interface,
this is 80 bytes which coincidentally, is 640 bits. (The
fragmentation rule is based on the clock rate of the interface; the
Bc is based on the CIR. When the clock rate and the CIR are the same,
the Bc and fragment size will be the same, but remember, Bc is in
bits and fragment is in bytes.)
For VoFR be sure to add the "frame-relay voice bandwidth" command,
otherwise voice calls will fail. The default voice bandwidth is 0;
unless you set it to a value (usually a multiple of 12000), you will
not be able to set up any VoFR calls. Note, though, this command is
not needed or wanted if you are carrying VoIP traffic over a Frame
Relay network.
But don't stop there. You should enforce traffic shaping (that is,
not adaptively), and enable fair queueing. The following would be my
recommendation for releases 12.0(7)XK and later. We use 12.1(2)T in
our labs.
interface serial 0
ip address ...
encapsulation frame-relay
frame-relay traffic-shaping
class ccie
map-class frame-relay ccie
frame-relay cir 64000
frame-relay bc 640
no frame-relay adaptive-shaping
frame-relay fair-queue
frame-relay fragment 80
frame-relay voice bandwidth 48000 ! This is needed for VoFR
! but not for VoIP over FR
By the way, you could attach the map-class to each DLCI instead and
have different map-classes for different DLCIs if you needed to.
Notice I have not configured Be. I don't want to borrow from my
future "allowance" and then be forced to delay a voice packet because
I had borrowed. Data works on the principle of "better late than
never", but voice (or any real time traffic, for that matter)
operates on the principle of "better never than late"; I want to pace
myself.
Cheers,
Neill
At 12:59 PM +0000 18/10/01, Brian Lodwick wrote:
>Ron,
> It sounds like you have quite a grasp on this information. I'd like
>to run something by you and see if you can help clear something up
>I've been having difficulties with?
> In the best documentation I have found on VoIP over Frame-Relay QOS
>it notes the ideal Tc value is 10ms. It also says that 10ms is the
>lowest configurable value. I understand this is optimum because it
>will provide for very small time gaps between packets. The problem I
>am encountering is how to mathmatically calculate this formula.
>I found something saying something saying it was Tc = Bc/CIR
>But then it goes on to say In this example we have a CIR to 64000,
>and have set the Bc to 600 (forcing the Tc to it's minumum
>configurable value)
>Wouldn't that give you a Tc of 106.66....?
>
>>>>Brian
>
>>From: "Ron Royston" <ccie6824@hotmail.com>
>>Reply-To: "Ron Royston" <ccie6824@hotmail.com>
>>To: John.K.Feuerherd@WellsFargo.COM, ccielab@groupstudy.com
>>Subject: Re: QOS configs
>>Date: Wed, 17 Oct 2001 17:20:20 -0500
>>
>>No. I believe they are different. Scott Keagy talks about this in
>>"Integrating Voice and Data Networks". CIR is typically expressed in Bps
>>and is the AVERAGE rate of traffic guaranteed by the carrier; Bc and Be are
>>expressed per unit of time, Tc, and are the ACTUAL number of bits that the
>>carrier commits to transport. Cisco routers take CIR as Bps, and Bc as
>>Bits.
>>
>>The only practical reason that you should use the latter of your examples is
>>to malipulate the value of Tc, which plays an important role in controlling
>>pausing time (which can manifest itself as jitter and delay in real-time
>>apps.) You don't explicitly configure Tc, you configure Bc and CIR and IOS
>>implies the Tc from there.
>>
>>I believe that these are the same (note the Be, not Bc):
>>
>>map-class frame-relay sample1
>> frame-relay traffic-rate 9600 19200
>> no frame-relay adaptive-shaping
>>-and-
>>map-class frame-relay sample2
>> frame-relay cir 9600
>> frame-relay be 19200
>>
>>Having the bc set to 19200, as in your example, would double the Tc to 2
>>seconds, telling the router to push out 2xCIR bits every 2 seconds at the
>>port speed. If the port speed is high, and the CIR low, your data gets sent
>>in short bursts followed by a long pauses and will likely exceed your CIR
>>from the carriers vantage point. The carrier's Tc is less than 2 seconds,
>>so they'll be getting 2 seconds worth of bits in less than 1 second if your
>>port speed is high enough, and they'll De, discard eligible, that data.
>>Right?
>>
>>-Ron
>>
>>PS IMHO, CCO needs more understandable info on this subject, but you can
>>check out, http://www.cisco.com/warp/customer/125/21.shtml. That's all I
>>can find.
>>
>>
>>
>>
>>>From: John.K.Feuerherd@WellsFargo.COM
>>>Reply-To: John.K.Feuerherd@WellsFargo.COM
>>>To: ccielab@groupstudy.com
>>>Subject: QOS configs
>>>Date: Tue, 16 Oct 2001 19:56:49 -0700
>>>
>>>Hello all,
>>> I have a quick question about traffic shaping. I think I understand
>>>this, but I just want to make sure:
>>>
>>>This two configs are basically the same right.....
>>>
>>>map-class frame-relay sample1
>>> frame-relay traffic-rate 9600 19200
>>> no frame-relay adaptive-shaping
>>>
>>>
>>>map-class frame-relay sample2
>>> frame-relay cir 9600
>>> frame-relay bc 19200
>>>
>>>Thanks in advance!
>>>
>>>JF
>>>John Feuerherd
>>>Wells Fargo Bank
>>>CCNP CCDP
>>>1-505-766-6118 <- Office
>>>1-505-301-1966 <- Cell
>>>John.K.Feuerherd@Wellsfargo.com
>>>MAC: Q2129-074
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 22:33:21 GMT-3