From: aansar@sscomp.com.sg
Date: Fri Apr 25 2003 - 00:46:27 GMT-3
If i am correct BE=0 in voip ..
"Nguyen Hoang
Long" To: <ccielab@groupstudy.com>
<ng-hlong@hn. cc:
vnn.vn> Subject: Re: Frame-Relay Traffic Shaping "Be"
Sent by: Value
nobody@groups
tudy.com
04/25/2003
10:29 AM
Please
respond to
"Nguyen Hoang
Long"
Hi Brian,
hmmm!? what value I should use if the question is somthing like:
CIR=64k
AR=128k
configure the end router so you can have data transmited as maximum as
possible.
I believe the Proctor won't tell me any about configuration specific.
thanks
Long.
----- Original Message -----
From: "Brian Dennis" <brian@labforge.com>
To: <ccielab@groupstudy.com>
Sent: Friday, April 25, 2003 7:00 AM
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