From: Larry Roberts (larryr@xxxxxxxxxxxx)
Date: Thu Jun 20 2002 - 01:09:30 GMT-3
You are welcome. I was also very frustrated by the lack of information and
misconceptions about this topic when I was studying for my CCIE. Glad I
could help.
----- Original Message -----
From: "elping" <elpingu@acedsl.com>
To: "Larry Roberts" <larryr@inetbeam.net>
Cc: <ccielab@groupstudy.com>
Sent: Wednesday, June 19, 2002 8:34 PM
Subject: Re: CIR, Be, Bc
> Larry:
>
> This is why I love this list ....you took the time to write all this down
> clearly...
>
> I thank you...
> I undertand now .....
>
>
> El ping
>
>
>
> Larry Roberts wrote:
>
> > Shaping mechanisms, such as Frame Relay Traffic Shaping (FRTS) and
Committed
> > Access Rate (CAR) use a token bucket mechanism. The token bucket
basically
> > regulates the amount of data that can be sent during a time period. Data
can
> > only be sent if there are enough free tokens in the token bucket
equivalent
> > to that amount of data. If there are enough tokens, the data is sent and
the
> > appropriate amount of tokens are removed from the Token Bucket. If there
is
> > not enough tokens, the router will buffer the data until the Token
Bucket
> > has enough tokens to send the data and then remove the appropriate
amount of
> > tokens. There are many terms and formulas you must understand to grasp
this
> > concept:
> >
> > CIR (Committed Information Rate) - This is the average amount of data
that
> > either you (or your service provider) wants you to be able to send
> > Bc - (Committed Burst) - This is the amount of data that can be sent
during
> > a time interval. There is really no bursting at this point. This is just
the
> > amount of data that you are allowed to send each time interval to meet
your
> > CIR.
> > Be - (Excess Burst) - Here is where bursting happens. This is normally
the
> > difference between your CIR and actual line access rate (or another
> > pre-defined parameter by your service provider).
> >
> > Be + CIR = the depth of the token bucket
> > Bc = the rate at which tokens are added to the bucket
> >
> > Now, in order to put all of this together we need one more important
piece
> > of data. That piece of data is the time interval or Tc.
> > Tc = Bc/CIR
> > This usually comes out to 0.125 or 125ms. This is the default setting on
> > Cisco routers.
> >
> > Example - I have a 128k Frame Relay circuit. I have configured the CIR
as
> > 64k. By default, the Tc is 125ms. So, 0.125 times 64,000 = 8,000.
Therefore,
> > my default Bc is 8,000. Therefore, my token bucket fills at this rate
and
> > allows me to send 8k every 125ms. 125ms is one eighth of a second. So,
8,000
> > times 8 equals 64,000 or 64k per second. Now, my actual line speed is
128k.
> > I can configure a Be of 64k. This will allow my Token Bucket to fill to
a
> > capacity of 128k. This means that if I don't send any data for a period
of
> > 128,000 divided by 8,000 = 16 time intervals, which equals 2 seconds, my
> > token bucket will fill to capacity and during the next time interval I
can
> > send 128k worth of data or burst to 128k. However, I would then go into
a
> > period of quite time where I couldn't send any data at all until the
token
> > bucket filled back up to CIR, which would be CIR (64,000) divided by Bc
> > (8,000) = 8 time intervals or one second.
> >
> > Now, this is probably the perfect example of how to do this right.
However,
> > when you get into higher data rates, the quite time after the burst can
get
> > quite lengthy. Also, a Tc of 125ms works great for data, but this should
be
> > adjusted to 10ms if you are running Voice across the Frame Relay
circuit.
> >
> > HTH,
> > Larry Roberts
> > CCIE #7886 (R&S / Security)
> >
> > ----- Original Message -----
> > From: "elping" <elpingu@acedsl.com>
> > To: <ccielab@groupstudy.com>
> > Sent: Tuesday, June 18, 2002 11:43 PM
> > Subject: CIR, Be, Bc
> >
> > > Can some one post an explanation of these frame relay
> > > CIR, Be, Bc
> > >
> > > I am a bit confused on the whole thing ...i did not find the doc on
> > > cisco helpfull
This archive was generated by hypermail 2.1.4 : Tue Jul 02 2002 - 08:12:38 GMT-3