GroupStudy.com GroupStudy.com - A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
RE: Frame-Relay Traffic Shaping "Be" Value posted 04/25/2003
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


I won't say there is a hard and fast rule of what Be should or shouldn't
be because it's really dependant on the needs of the network. If a
network had voice traffic going across the frame-relay cloud Be should
be set to 0 and CIR should equal the provider's CIR. If there was a lot
of traffic that needs to burst then a Be value could be configured. 

In the end it's up to the network administrator to configure a Bc and Be
value that works for their network. But keep in mind when configuring Be
the line rate and the queue sizes (hardware and FRTS). If you configure
a very large Be value on a slow line you could create the possibility of
overrunning the queues and in turn cause the router to drop packets. If
you need to have a large Be value on a slow line I would recommend
increasing the FRTS queue and interface output queue.

Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
Director of CCIE Training and Development - IPexpert, Inc.
Mailto: brian@xxxxxxxxxxxx
Toll Free: 866.225.8064
Outside U.S. & Canada: 312.321.6924


-----Original Message-----
From: nobody@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx] On Behalf Of
Connie Nie
Sent: Thursday, April 24, 2003 7:13 PM
To: ccielab@xxxxxxxxxxxxxx
Subject: RE: Frame-Relay Traffic Shaping "Be" Value

Dennis: What would be the formula to calculate be then? Does the formula
(be+bc)/tc=AIR still stand? 

Connie
-----Original Message-----
From: Brian Dennis [mailto:brian@xxxxxxxxxxxx] 
Sent: Thursday, April 24, 2003 7:00 PM
To: ccielab@xxxxxxxxxxxxxx
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@xxxxxxxxxxxx
Toll Free: 866.225.8064
Outside U.S. & Canada: 312.321.6924