From: Jonathan V Hays (jhays@jtan.com)
Date: Thu Apr 24 2003 - 23:21:04 GMT-3
Thanks, Brian. Well worth the wait!!
-Jonathan
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> Behalf Of Brian Dennis
> Sent: Thursday, April 24, 2003 8:00 PM
> To: ccielab@groupstudy.com
> Subject: Frame-Relay Traffic Shaping "Be" Value
>
>
> After testing FRTS I can say that Be can be larger than the
> previous "internal interval" (Tc) and even the previous
> "interval" (full second). There does not appear to be a limit
> as to how long Be can continue to build up credits (aka
> tokens). This means that Be can hold credits from a multitude
> of previous Tc's and even a multitude of full seconds. I've
> tested FRTS scenarios where Be credits built up over 10
> minutes (CIR = 16000 and Be = 12000000).
>
> For those interested in understanding FRTS let me explain it
> from the perspective a single "bucket" (i.e. Be = 0) FRST
> configuration and then from a dual "bucket" (i.e. Be > 0)
> FRST configuration.
>
> Let's start off the single bucket explanation:
>
> map-class frame-relay SingleBucket
> frame-relay cir 16000
> frame-relay bc 2000
>
> When we first apply FRTS to an interface (or DLCI) we will
> start out with a single bucket full of credits. Every Tc the
> amount of credits equaling Bc is added to this bucket. When a
> packet needs to be sent the router will check to see if there
> are enough credits to send the packet (1 credit equals 1
> bit). If there are enough credits, the router will send the
> packet and removes the amount of credits equaling the size of
> the packet. If there are not enough credits the packet gets
> "shaped" and placed in the FRTS hold queue awaiting enough
> credits to send the packet.
>
> Since this is a single bucket configuration we do not store
> excess credits and theoretically can never send more than Bc
> amount of bits per Tc. If this bucket has credits left over
> when the next Tc starts these left over credits will be lost.
> This is because at the start of every Tc Bc amount of credits
> are added to this bucket that can only hold Bc amount of credits.
>
> In contrast to CAR FRTS will never borrow credits from future
> Bc's and will theoretically never go into debt. This ensures
> that with FRTS the router is always guaranteed to have
> credits to send every Tc. As a side note remember that CAR on
> the other hand does not really guarantee bandwidth. CAR only
> limits bandwidth.
>
> Now the dual bucket explanation:
>
> map-class frame-relay DualBucket
> frame-relay cir 16000
> frame-relay bc 2000
> frame-relay be 62000
>
> When we first apply FRTS to an interface (or DLCI) we will
> start out with two buckets full of credits. Lets call the
> first bucket the Bc bucket and the second bucket the Be
> bucket. When a packet needs to be sent the router will check
> to see if the Bc bucket has enough credits to send the
> packet. If it does have enough credits the packet is sent and
> the amount of credits equaling the size of the packet is
> removed from the Bc bucket. If the Bc bucket does not have
> enough credits the router will check the Be bucket. The
> packet will be sent if there are enough credits in the Be
> bucket and the amount of credits equaling the size of the
> packet will be removed from the Be bucket. If there aren't
> enough credits in the Bc or Be buckets the packet is stored
> in the FRTS hold queue till there are enough credits built up
> to send the packet.
>
> At the start of every Tc Bc amount of credits are added to
> the Bc bucket. If the bucket has credits left over when the
> next Tc starts those credits will cause the Bc bucket to
> overflow but the overflow credits will be caught by the Be
> bucket. The Be bucket can only hold Be amount of credits. If
> the Bc and Be buckets are both full the new credits added
> each Tc will be lost.
>
> This is actually my short explanation of FRTS ;-)
>
> 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
This archive was generated by hypermail 2.1.4 : Thu May 01 2003 - 13:36:06 GMT-3