From: Daniel Cisco Group Study (danielcgs@imc.net.au)
Date: Fri Apr 25 2003 - 02:14:05 GMT-3
Thanks Brian.
Makes a lot of sense.
A couple of questions:
(1) Say an 800 bit packet is ready to be transmitted and the bc bucket contains only 400 credits bits, and the be bucket contains say 2000 bits. Would it be correct to say that 400 bits would come out of the bc bucket, emptying that bucket, and 400 would come out of the be bucket, leaving only 1600 bits? Your explanation implied that all the bits would come from the be bucket in this scenario. Which is correct? Maybe it wouldn't matter....
(2) What happens when the bc value is set to a very small value, such that when a packet requests credits for transmission, it is requesting more than exists in the bc (and be) buckets? For example:
map-class frame-relay SingleBucket
frame-relay cir 16000
frame-relay bc 2000
Here, bc is only 250 bytes, and be=0. A 1500 byte packet cannot be serviced, as there will never be enough bc credits. Does some sort of debt scheme kick in? Do we then borrow credits from one or more future Tc's, to service the request?
Daniel
-----Original Message-----
From: Brian Dennis [mailto:brian@labforge.com]
Sent: Friday, 25 April 2003 10:00
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 email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
This archive was generated by hypermail 2.1.4 : Thu May 01 2003 - 13:36:06 GMT-3