From: Chris Hugo (chrishugo@xxxxxxxxx)
Date: Wed Aug 28 2002 - 18:22:53 GMT-3
>From this link I grabbed off CCO pub it specifies we should not even think abo
ut configuring Be if our CIR is at the same rate as the Access-Rate. This is be
cause Be can ONLY accumulate when port traffic is less than CIR.
It also talks about the token bucket being completely depleted after the FIRST
Tc.
My point is maybe the interface can buffer some data but it won't be any more t
han the AR due to the nature of the beast.
chris hugo
frame relay be
The amount of excess data allowed to be sent during first Tc interval in bits o
nce credit is built up. Configure Be only if the Frame Relay CIR value is less
than the AR. . The router only bursts (Be) when there are tokens in the token b
ucket. The token bucket does not accrue tokens unless the amount of traffic bei
ng sent out is less than the CIR. The router can only burst for the first Tc, a
fter which the token bucket is empty. The value of Be by default is zero bits.
Colin Barber wrote: Sorry about that, it's been a long day. At least I was con
sistent in my
error!
Correction:
CIR = 64000
Access rate = 96000
Tc = 1/8th sec
BC=8000
To burst up to the AR what is the value of BE?
option 1 BE=32000 (8*BC)+BE = 96000
option 2 BE=4000 at one Tc BC+BE=12000*Tc = 96000
-----Original Message-----
From: Volkov, Dmitry (Toronto - BCE) [mailto:dmitry_volkov@ca.ml.com]
Sent: 28 August 2002 20:59
To: 'Colin Barber'; Bauer, Rick
Cc: ccielab@groupstudy.com
Subject: RE: I need FRTS help or review - TIME TO VOTE
> -----Original Message-----
> From: Colin Barber [mailto:Colin.Barber@telewest.co.uk]
> Sent: Wednesday, August 28, 2002 3:30 PM
> To: Bauer, Rick; ccielab@groupstudy.com
> Subject: RE: I need FRTS help or review - TIME TO VOTE
>
>
> I think the confusion is:
>
> can (BC+BE)/Tc be greater than AR as Jim is saying because
> the interface
> will buffer the excess or
>
> (BC+BE)/Tc <= AR because the burst has to be transmitted within one Tc
>
> Your link states that the parameters control the rate of
> traffic onto the
> interface but not onto the line so is the interface buffering
> any excess and
> can you have a large excess?
>
>
> To put it another way: if your CIR is less than the access
> speed of the
> interface and you wish to burst to the full access speed, do
> you work out BE
> so that the access rate is achieved only in the first Tc or
> the access rate
> is achieved over a full second?
>
> I think we need a vote on the two options - I'm for option 2
>
> For example:
>
> CIR = 64000
> Access rate = 96000
> Tc = 1/8th sec
> BC=8000
>
> To burst up to the AR what is the value of BE?
>
> option 1 BC=32000 (8*BC)+BE = 96000
!!!!!!!!!! BE=32000 not BC !!!!
>
> option 2 BC=4000 at one Tc BC+BE=12000*Tc = 96000
!!!!!!!!!! BE=4000 not BC !!!!
>
> Colin
>
> -----Original Message-----
> From: Bauer, Rick [mailto:BAUERR@toysrus.com]
> Sent: 28 August 2002 19:55
> To: 'ccielab@groupstudy.com'
> Subject: RE: I need FRTS help or review
>
>
> This should help. The first couple of lines will answer your
> question in
> regard to CIR, BE, BC.
>
> http://www.cisco.com/warp/customer/125/21.shtml
>
> Rick, #9482
>
> -----Original Message-----
> From: Volkov, Dmitry (Toronto - BCE) [mailto:dmitry_volkov@ca.ml.com]
> Sent: Wednesday, August 28, 2002 2:07 PM
> To: 'Jim Brown'; 'Colin Barber'; 'Omer Ansari'
> Cc: 'ccielab@groupstudy.com'
> Subject: RE: I need FRTS help or review
>
>
> Jim,
>
> You are right traffic will be delayed and sent within 9th Tc interval
> (assuming Tc=1/8 sec).
> But Be is still Be - it is number of bits, and Be+Bc =< Port Speed
> (clocking) * Tc.
>
> We have to put actual number in config.
>
> 40000 bits will not be transmitted during 1st Tc - only 12000 bits.
> Other bits will be delayed until 9th Tc.
>
> Be - number of bits will be transmitted within 1st Tc ==> be = 12000
> -8000(Bc) = 4000 bits
>
> and this number 4000 we have to put in config as Be. The
> other bits will be
> delayed / dropped, whatever.
>
> I'm not 100% sure about it, but I got this logic from CCO.
>
> Colin right - the documentation on this subj is very unclear.
>
> This subj is like religion for me - believe or not believe :)
>
> Dmitry
>
> > -----Original Message-----
> > From: Jim Brown [mailto:Jim.Brown@caselogic.com]
> > Sent: Wednesday, August 28, 2002 11:35 AM
> > To: 'Colin Barber'; 'Omer Ansari'; 'ccielab@groupstudy.com'
> > Subject: RE: I need FRTS help or review
> >
> >
> > You do not necessarily need 320Kps available during the first
> > interval. The
> > packets are software queued before they are placed onto the
> > TxRing. This is
> > the whole idea behind shaping.
> >
> > They are not placed on the wire at exactly the same speed
> > designated per TC
> > interval.
> >
> > List, if I'm way off base please correct me and help me see
> the light.
> >
> > -----Original Message-----
> > From: Colin Barber [mailto:Colin.Barber@telewest.co.uk]
> > Sent: Wednesday, August 28, 2002 9:09 AM
> > To: 'Omer Ansari'; 'ccielab@groupstudy.com'
> > Subject: RE: I need FRTS help or review
> >
> >
> > What's the access speed of the interface? If it's 96k then this is
> > incorrect. In the first time slot BC+BE=40000. For that
> > amount of data to be
> > transferred in the first timeslot the access speed will need to be
> > 40000*8=320kbps.
> >
> > Colin
>
> --------------------------------------------------------------
> ----------------
> Live Life in Broadband
> www.telewest.co.uk
>
>
> The information transmitted is intended only for the person
> or entity to which it is addressed and may contain
> confidential and/or privileged material.
> Statements and opinions expressed in this e-mail may not
> represent those of the company. Any review, retransmission,
> dissemination or other use of, or taking of any action in
> reliance upon, this information by persons or entities other
> than the intended recipient is prohibited. If you received
> this in error, please contact the sender immediately and
> delete the material from any computer.
>
>
> ==============================================================
> ================
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:41 GMT-3