From: ccie1@hotmail.com
Date: Wed Apr 16 2003 - 15:27:21 GMT-3
no, its over a tc period.
So if you had a cir of 64k and your min was 32, your bc would bc would be
8k. if your remote link had a higher cir then you would have the be set to
the difference of cir. so if the remote site had a cir of 128k then you
would have a be of 16k
----- Original Message -----
From: "OhioHondo" <ohiohondo@columbus.rr.com>
To: "Brian Dennis" <brian@5g.net>; <ANDF@nnpi.com>; <ccielab@groupstudy.com>
Sent: Thursday, April 17, 2003 9:27 AM
Subject: RE: FRTS Revealed (was RE: MINCIR = CIR?)
> Brian
>
> Just for a clarification -- are the credits that Be uses in the 1st time
> interval built up over the 1 second period (using all of the unused Bc
bits
> in a 1 second period) OR over a single Tc period (Using the unused Bc bits
> of let's say a 125 millisecond period).
>
> If the first is true, then Be could be a much larger value than Bc.
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Brian Dennis
> Sent: Thursday, April 17, 2003 11:09 AM
> To: ANDF@nnpi.com; ccielab@groupstudy.com
> Subject: RE: FRTS Revealed (was RE: MINCIR = CIR?)
>
>
> Since Be is made up of unused Bc bytes from the previous interval (Tc)
> Be can not contain more bytes than Bc. So if Bc is 4000 how can you ever
> have a Be value more than 4000?
>
> Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
> Director of CCIE Training and Development - IPexpert, Inc.
> Mailto: brian@ipexpert.net
> Toll Free: 866.225.8064
> Outside U.S. & Canada: 312.321.6924
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> ANDF@nnpi.com
> Sent: Thursday, April 17, 2003 6:46 AM
> To: brian@cyscoexpert.com; ccielab@groupstudy.com
> Subject: RE: FRTS Revealed (was RE: MINCIR = CIR?)
>
> Brian,
>
> I appreciate your input on this. On page 66 of the 2002 CCIE Power
> Session
> slides they show Be = 32000 when CIR = 32000, port speed = 64000, Bc =
> 4000
> and Tc = 125ms. Are they incorrect? Shouldn't Be have been 4000?
>
> Thanks,
>
> Andy Fernandes
>
> -----Original Message-----
> From: Brian McGahan [mailto:brian@cyscoexpert.com]
> Sent: Thursday, April 17, 2003 12:40 AM
> To: 'OhioHondo'; 'Jonathan V Hays'; ccielab@groupstudy.com
> Cc: 'Mike Williams'
> Subject: FRTS Revealed (was RE: MINCIR = CIR?)
>
>
> Due to incorrect documentation, FRTS is one of the most
> misunderstood topics within the CCIE domain. Since this is my favorite
> lecture which I usually end up giving 5 or 6 times per week, I'll just
> go
> for the complete explanation to start with :)
>
> To calculate FRTS values, we will use the following formulas:
>
> Bc = (CIR * Tc) / 1000
> Be = ((AR - CIR) * Tc)/1000
>
>
> In the CCO example you are referencing, the hub has an
> access-rate
> of 192000bps, while the remote only has an access-rate of 64000bps.
> Therefore, the fastest speed that can be sustained over the second is
> 64000bps. This is what we want to average per second, which is Cisco's
> term
> CIR.
>
> Hub:
> AR = 192000
> CIR = 64000
>
> Remote:
> AR = 64000
> CIR = 64000
>
> Since CIR <= 640Kbps, the default Tc is 125ms. (I'll explain
> this
> later) Now we have the following:
>
> Hub:
> AR = 192000
> CIR = 64000
> Tc = 125
>
> Remote:
> AR = 64000
> CIR = 64000
> Tc = 125
>
> Now that we have both CIR and Tc, we can solve for Bc. Since
> both
> the CIR and Tc are the same for the Hub and the Remote, Bc will be the
> same:
>
> Bc = (CIR * Tc)/1000
> Bc = (64000 * 125)/1000
> Bc = (8000000)/1000
> Bc = 8000 bits
>
> Now we have:
>
> Hub:
> AR = 192000
> CIR = 64000
> Tc = 125
> Bc = 8000
>
> Remote:
> AR = 64000
> CIR = 64000
> Tc = 125ms
> Bc = 8000
>
> Now we must solve for Be, starting with Hub:
>
> Be = ((AR - CIR) * Tc)/1000
> Be = ((192000 - 64000) * 125) / 1000
> Be = ((128000) * 125) / 1000
> Be = (16000000) / 1000
> Be = 16000
>
> Now the Remote:
>
> Be = ((AR - CIR) * Tc)/1000
> Be = ((64000 - 64000) * 125) / 1000
> Be = ((0) * 125) / 1000
> Be = (0) / 1000
> Be = 0
>
>
> So far, our calculations have nothing to do with how our line is
> actually provisioned. Instead, we have simply calculated how our token
> bucket will shape the traffic. The example then states "In case of
> congestion, it can drop down to 32Kbps at the minimum." This statement
> implies that the provider has provisioned 32000bps for us on this VC. In
> order to dynamically react to congestion from the cloud, we must enable
> BECN
> adapt, which is where the following two statements come
> from:
>
> frame-relay mincir 32000
> frame-relay adaptive-shaping becn
>
>
>
> The following statement in the document is wrong:
>
> "Ideally for data PVCs Bc = CIR/8 so that Tc = 125msec."
>
> There is a maximum Tc value per CIR. The greater the CIR the
> smaller the Tc value must be. Unfortunately, this behavior is not
> documented. In the following example, the frame-relay map-class X is
> applied to an interface with one VC. We can test this behavior based on
> the
> following:
>
> Suppose we have a CIR of 640000. If Bc = CIR/8, then Bc =
> 640000/8
> = 80000.
>
> map-class frame-relay X
> frame-relay cir 640000
> frame-relay bc 80000
> no frame-relay adaptive-shaping
> end
>
> Rack2R6#show traffic-shape
>
> Interface Se0/0
> Access Target Byte Sustain Excess Interval Increment
> Adapt
> VC List Rate Limit bits/int bits/int (ms) (bytes)
> Active
> 604 640000 10000 80000 0 125 10000 -
>
>
>
> This indicates that we have 8 intervals per second (1000ms per
> second, 125ms per interval), and are sending 80000 bits per interval,
> which
> works out to an average of 640000bps. So far so good.
>
> Now let's change our CIR to 800000bps:
>
> Current configuration:
> !
> map-class frame-relay X
> frame-relay cir 800000
> frame-relay bc 100000
> no frame-relay adaptive-shaping
> end
>
> Rack2R6#sh traffic
>
> Interface Se0/0
> Access Target Byte Sustain Excess Interval Increment
> Adapt
> VC List Rate Limit bits/int bits/int (ms) (bytes)
> Active
> 604 800000 6300 100000 0 63 6300 -
>
>
> Notice that our interval is not 125ms now, but our Bc still
> conforms
> to the formula Bc = CIR/8. In actuality, we have (bear with
> me) 1000/63 = 15.873015873015873015873015873016 intervals per second. At
> 100000 bits per interval, we are averaging about 1587301bps, which is
> clearly beyond 800Kbps. This is due to the fact that for a CIR of
> 800Kbps,
> the maximum Tc value is 63ms.
>
> Instead, let us compute Bc using 63 as the Tc:
>
> Bc = (CIR * Tc) / 1000
> Bc = (800000 * 63) / 1000
> Bc = 50400
>
> Rack2R6#sh run map-class
> Building configuration...
>
> Current configuration:
> !
> map-class frame-relay X
> frame-relay cir 800000
> frame-relay bc 50400
> no frame-relay adaptive-shaping
> end
>
> Rack2R6#sh traffic-shape
>
> Interface Se0/0
> Access Target Byte Sustain Excess Interval Increment
> Adapt
> VC List Rate Limit bits/int bits/int (ms) (bytes)
> Active
> 604 800000 6300 50400 0 63 6300 -
>
>
> We still have 1000/63 = 15.873015873015873015873015873016
> intervals
> per second. If we are sending 50400bits every
> 15.873015873015873015873015873016ms, we will be averaging 800000bps.
>
> I'm not sure exactly where the cutoff values are for the max Tc,
> but
> the router will tell you the appropriate Tc value for a CIR if you enter
> it
> in the map-class, apply it, then show traffic-shape.
>
>
> Hope I didn't confuse you all further :)
>
>
> Brian McGahan, CCIE #8593
> Director of Design and Implementation
> brian@cyscoexpert.com
>
> CyscoExpert Corporation
> Internetwork Consulting & Training
> Toll Free: 866-CyscoXP
> Outside US: 847.674.3392
> Fax: 847.674.2625
>
>
> > -----Original Message-----
> > From: OhioHondo [mailto:ohiohondo@columbus.rr.com]
> > Sent: Wednesday, April 16, 2003 10:08 PM
> > To: Jonathan V Hays; 'Brian McGahan'; ccielab@groupstudy.com
> > Cc: 'Mike Williams'
> > Subject: RE: MINCIR = CIR?
> >
> > This new equation/explanation for calculating FRTS parameter -- I've
> never
> > seen it before. It doesn't make sense with anything I've read on the
> > subject. How does it relate to the CCO iformation found at:
> >
> >
> http://www.cisco.com/en/US/tech/tk713/tk237/technologies_configuration_e
> xa
> > mp
> > le09186a00800942f8.shtml
> >
> > where:
> > Bc=CIR*Tc
> > Be= (AR*Tc) - Bc
> >
> > Where is the source of your information?
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>
> > Jonathan V Hays
> > Sent: Wednesday, April 16, 2003 9:00 PM
> > To: 'Brian McGahan'; ccielab@groupstudy.com
> > Cc: 'Mike Williams'
> > Subject: RE: MINCIR = CIR?
> >
> >
> > > -----Original Message-----
> > > From: Brian McGahan [mailto:brian@cyscoexpert.com]
> > > Sent: Wednesday, April 16, 2003 1:33 PM
> > > To: 'Jonathan V Hays'; ccielab@groupstudy.com
> > > Cc: 'Mike Williams'
> > > Subject: RE: MINCIR = CIR?
> > >
> > [snip]
> > > The following formulas hold true for Cisco's implementation of
> > > Frame-Relay Traffic Shaping:
> > >
> > > Bc = (CIR * Tc)/1000
> > > Be = ((AR - CIR) * Tc)/1000
> > >
> >
> > Brian,
> >
> > What units are you using to require division by 1000? Most Cisco
> > documents seem to give Bc= CIR * Tc.
> >
> >
> http://www.cisco.com/en/US/tech/tk713/tk237/technologies_configuration_e
> > xample09186a00800942f8.shtml
> >
> > See the document I cited in my earlier post (included above) under
> > "Nonconfigurable parameters - interval (Tc)" -
> > ---
> > "The time interval during which you send the Bc bits in order to
> > maintain the average rate of the CIR in seconds.
> >
> > Tc = Bc/CIR in seconds.
> >
> > The range for Tc is between 10 ms and 125 ms."
> > ---
> > In the example given in the Cisco document, Bc is 8000 bits, CIR is
> > 64000 bps, then Tc = 8000 bits / 64000 bps = 1/8 second.
> >
> > Or if you use Bc = CIR * Tc, then
> > Bc = 64000 bps * 1/8 second = 8000 bits.
> >
> > What does dividing by 1000 get me?
> >
> > Thanks.
This archive was generated by hypermail 2.1.4 : Thu May 01 2003 - 13:35:56 GMT-3