From: OhioHondo (ohiohondo@columbus.rr.com)
Date: Fri Apr 25 2003 - 00:12:26 GMT-3
Brian
Thanks for the explanation. I have a question. All the info about only using
Be in the first Tc -- is this bogus? Can Be credits be used in ANY Tc time
period??
-----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