From: Lachlan Kidd (lkidd@xxxxxxxxxxxxxxxxxxx)
Date: Sat Aug 11 2001 - 20:54:25 GMT-3
Hi Dan,
Looks pretty good to me. The only comment I would make is as follows.
Cisco's doco of the FRTS parameters is pretty dodgy. The doco around on this
is really inconsistent. The web site has a number of examples where the
calculations have been done exactly how you've done them. If I was in a lab
environment I would do them that way. However, Pat Bodin (who works for
Cisco) on this list posted a mail in which he showed a different way of
calculating the parameters. From more reading his way makes more sense. Pat
are you still out there ? Any comments ?
>From reading the Ciscopress QoS book, Be is the amount of excess bust data
that can be sent during the first time interval (Tc) if the token bucket is
full. After that first time interval if there is less than Bc bits
transmitted in any given time interval, credit is built up such that in the
next time interval up to Bc+Be bits can be transmitted. O.K, taking this and
applying it to an example like yours...
Lets assume that in the first Tc interval (125ms), there is 14000 bits to
send. Because this is the first Tc we can send Be+Bc bits, so that's fine,
everything can go. Next Tc (250ms) we've got 8000 bits to send. We've got no
credit built up so we can only send Bc (6000) bits. So we've got 2000bits
left over. Next Tc(375ms) we've got 2000 bits to send plus 2000 bits from
the last Tc so 4000 bits go out. We've not used our total credit for this Tc
so next time round we can send 8000 bits out.
O.K.....If what I've said is correct and taking your figures we get
14000, 6000,6000,6000,6000,6000,6000,6000=56Kbits/sec (max)
or if we had really bursty traffic we could get
14000,0,12000,0,12000,0,12000,0=50Kbits/sec
Now, if we set Be=16000 we get
22000, 6000,6000,6000,6000,6000,6000,6000=64Kbits/sec
Just to prove that the web site indicates your way is correct
http://www.cisco.com/warp/customer/788/voip/fr_traffic.html
Look at the data PVC example. But I'm still not convinced. Anyone else got
any comments ?
HTH,
Lachlan
----Pat's original mail----
This should help!
Terminology:
Tc = Bc/Cir ! time interval (the internalized version of Tc where the
time interval can't exceed 125ms)
CIR = Average rate you want to send out (This is generally not the
same as the CIR you get from your provider unless you aren't
allowed to send above CIR) This is measured in bits/second.
Bc = Amount of data to send per each Tc interval. This is
measured in bits.
(this also gets internalized and real amount of data sent per
interval is expressed in bytes by the "increment" variable).
Be = Amount of excess data allowed to be sent during first
interval once credit is built up. Also measured in bits.
Mincir = Minimum amount of data to be sent during periods of congestion.
This defaults to half of CIR.
Interval = Bc/CIR with the maximum size being 125ms.
byte increment = Bc/8 . Must be > 125. Upper side has no bound
or limitation except if interval is locked at 125ms.
limit = byte increment + Be/8 (measured in bytes)
--------------------------------------------------------------------
OK let me throw some numbers in which may help explain this better.
Let's say you have a frame relay link with following parameters:
Physical port speed 64KB
CIR = 16KB (In this case I mean CIR your provider has guarenteed
you in their network)
Now let's say your provider has told you that you can send data on your PVC
up to port speed as long as there is no congestion in their network but that
when there is congestion they will only guarantee you CIR on your PVC.
Here is what you should configure on the router:
encap frame-relay
ip address 10.10.10.1 255.255.255.0
frame-relay traffic-shaping
frame-relay map ip 10.10.10.2 200 broadcast
frame-relay interface-dlci 200
class 64KB
map-class frame-relay 64KB
frame-relay cir 64000 ! This is rate you want to normally send at
when
there is no congestion
frame-relay bc 8000 ! This is amount you will send per interval.
rule of thumb is to make it 1/8 CIR
frame-relay be 0 ! This is extra amount to send in first
interval. In this case you are already
sending at port speed so this should be 0.
frame-relay mincir 16000 ! This is what you will slow down to during
congestion. This should be set to your true
CIR that your provider has guarenteed you
when
there is congestion in their network
*Note that BECN Response(ie dropping down when receiving BECNs) is
enabled by default in 11.2
Now here are a couple of other numbers that are used in traffic shaping:
Tc= Bc/CIR where Tc is the measurement interval. This value should
be no larger than 1/8 second for good shaping to take affect.
So in above example Tc = 8K/64K = 1/8 second
So basically here is what you would see transmitted in 1/8 second intervals:
8000(Bc+Be), 8000(Bc), 8000, 8000, 8000, 8000, 8000, 8000
which equals 64000bits/second.
Now if you actually had a 128KB port speed but you left all numbers the same
except you changed Be = 64000 then here is what you would see.
72000, 8000, 8000, 8000 ....
You would keep sending at Bc(8000) until you had an idle interval or only a
partially used interval and you built up credit again. The maximum credit
you
can build up is Be.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Dan
Sent: Sunday, 12 August 2001 8:44 AM
To: ccielab@groupstudy.com
Subject: FRTShaping config
Can someone take a look at my config and let me know if it is correct?
I'm trying to accomplish the following:
CIR is 48k burstable to 64k. BECN will be sent by provider.
I want to lower the speed to 16k when receiving BECN and I'm using Tc of
125ms.
interface Serial0
ip address 101.1.6.71 255.255.255.224
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay class shape
frame-relay map ip 101.1.6.74 102 broadcast
no frame-relay inverse-arp
map-class frame-relay shape
frame-relay cir 48000
frame-relay bc 6000
frame-relay be 8000
frame-relay mincir 16000
frame-relay adaptive-shaping becn
**Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:31:49 GMT-3