From: weibing gu (guwb@xxxxxxxxxxxxxxxxxxxx)
Date: Tue Aug 14 2001 - 05:33:04 GMT-3
Hi,
You can read at http://www.cisco.com/univercd/cc/td/doc/cisintwk/idg4/nd2009.ht
m#xtocid1346023
It said that the MAXr=(Be+Bc)/Bc*CIR.
So the be is used every interval, not the first interval.
>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
Guwb
guwb@gd.bank-of-china.com
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:31:50 GMT-3