From: Volkov, Dmitry (Toronto - BCE) (dmitry_volkov@xxxxxxxxx)
Date: Thu Aug 29 2002 - 10:52:19 GMT-3
Rick,
I agree with this method - this is exactly what CCO said at
http://www.cisco.com/warp/customer/125/traffic_shaping_6151.html
This is option 2 in Colin Barber posting.
Can You comment Carlos Mendioroz posting ?
Thanks,
Dmitry
> -----Original Message-----
> From: Bauer, Rick [mailto:BAUERR@toysrus.com]
> Sent: Thursday, August 29, 2002 8:28 AM
> To: 'Volkov, Dmitry (Toronto - BCE)'; 'ccielab@groupstudy.com'
> Subject: RE: I need FRTS help or review
>
>
> Sorry, it helped me when I was where you guys are. I also modeled the
> traffic shaping for my 1200 location Frame relay network on
> the information
> here.
>
> Keep in mind that this example is for over subscription. That
> is why the hub
> BE + BC = AR 192000 and the remote BC + BE (0) = AR 64000. It
> is just math.
>
> HTH...
>
> Rick, #9482
>
> Here is the pertinent part.
>
> Assuming that the traffic is sent with a burst of 80000 bits,
> this is sent
> out of the PVC in 8 Tc intervals (125 msec each). We can achieve this
> because, in the first interval, the credit available is Bc +
> Be = 8000 +
> 16000 = 24000 bits. This means that the rate is 24000 bits /
> 125 msec = 192
> Kbps.
>
> In the next seven intervals it is only Bc = 8000 bits. Hence
> the rate is
> 8000 / 125 msec = 64 Kbps.
>
> If, for example, we receive a burst of 88000 bits, we will
> not be able to
> send all this traffic in 8 Tc intervals. The final 8000 bits
> will be sent in
> the 9th Tc interval. Thus, this traffic is delayed by the
> traffic shaping
> mechanism.
>
>
>
> -----Original Message-----
> From: Volkov, Dmitry (Toronto - BCE) [mailto:dmitry_volkov@ca.ml.com]
> Sent: Wednesday, August 28, 2002 3:20 PM
> To: 'Bauer, Rick'
> Cc: 'ccielab@groupstudy.com'
> Subject: RE: I need FRTS help or review
>
>
> Rick this doc is well known.
>
> But it doesn't make more clear this subj.
>
> You pointed to "The first couple of lines" :
> "excess burst plus committed burst (Bc + Be) = maximum speed
> for the virtual
> circuit (VC)"
>
> Now take a look little bit below that (just above diagram):
>
> Committed Information Rate (CIR)
> The CIR is the allowed amount of data which the network is
> committed to
> transfer under normal conditions. The rate is averaged over a
> increment of
> time Tc. The CIR is also referred to as the minimum
> acceptable throughput.
> Bc and Be are expressed in bits, Tc in seconds, and the
> access rate and CIR
> in bits per second.
>
> Bc, Be, Tc and CIR are defined per data-link connection
> identifier (DLCI).
> Due to this, the token bucket filter controls the rate per
> DLCI. The access
> rate is valid per user-network interface. For Bc, Be and CIR
> incoming and
> outgoing values can be distinguished. If the connection is
> symmetrical, the
> values in both directions are the same. For permanent virtual
> circuits, we
> define incoming and outgoing Bc, Be and CIR at subscription time.
>
> Peak = DLCI's maximum speed. The bandwidth for that particular DLCI.
> --------------!!!!
> Tc = Bc / CIR
> Peak = CIR + Be/Tc = CIR (1 + Be/Bc) -----------------!!!!!!!!!!!!!
> If the Tc is one second then:
>
> Peak = CIR + Be = Bc + Be
> EIR = Be
>
> Dmitry
>
> > -----Original Message-----
> > From: Bauer, Rick [mailto:BAUERR@toysrus.com]
> > Sent: Wednesday, August 28, 2002 2:55 PM
> > 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
> > > -----Original Message-----
> > > From: Omer Ansari [mailto:omer@ansari.com]
> > > Sent: 28 August 2002 10:56
> > > To: ccielab@groupstudy.com
> > > Cc: steven.j.nelson@bt.com; Jim.Brown@caselogic.com;
> > > kip.palmer@verizon.net
> > > Subject: RE: I need FRTS help or review
> > >
> > >
> > > Guys,
> > >
> > > so bottom line is Jim and Steve have correctly done this right?
> > > It seems good to me, and I too want to stick this once
> and for all.
> > >
> > > omer
> > >
> > > On Mon, 26 Aug 2002 steven.j.nelson@bt.com wrote:
> > >
> > > > All
> > > >
> > > > Jim is correct in this one, his figures pan out as follows
> > > >
> > > > CIR 96000
> > > > MINCIR 64000
> > > > BE 32000
> > > > BC 8000
> > > > TC 0.125Ms
> > > >
> > > > So in 8 time slots (1 Second) he will transmit :-
> > > >
> > > > 0.125Ms 40000 (BC+BE)
> > > > 0.125Ms 8000 (BC)
> > > > 0.125Ms 8000 (BC)
> > > > 0.125Ms 8000 (BC)
> > > > 0.125Ms 8000 (BC)
> > > > 0.125Ms 8000 (BC)
> > > > 0.125Ms 8000 (BC)
> > > > 0.125Ms 8000 (BC)
> > > >
> > > > Which is equivalent to 96K per second.
> > > >
> > > > And when no tokens are available then the MIN CIR will be
> > > met by the 8000
> > > BC
> > > > * 8 = 64000
> > > >
> > > > Thanks to Jim for this one.
> > > >
> > > > Steve
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Jim Brown [mailto:Jim.Brown@caselogic.com]
> > > > Sent: 26 August 2002 15:24
> > > > To: 'kpalmer'
> > > > Cc: 'ccielab@groupstudy.com'
> > > > Subject: RE: I need FRTS help or review
> > > >
> > > >
> > > > After your e-mails I rethought my stance on FRTS. I did a
> > > little more
> > > > research and I believe my original configuration at the
> > > bottom of the post
> > > > is the correct answer from a lab or testing context for a
> > > 96Kbps port and
> > > > 64Kbs contracted CIR.
> > > >
> > > > map-class frame-relay TestShape
> > > > frame-relay cir 64000
> > > > frame-relay be 32000
> > > > frame-relay bc 8000
> > > >
> > > > I'm basing this on a single new piece of information I
> > > turned-up. Check
> > > the
> > > > Networkers 2002 CCIE Power Session, in their FRTS example,
> > > they configure
> > > > the parameters exactly as I have described below.
> > > >
> > > > I still stand by my original assessment of Cisco's CIR
> set to the
> > > providers
> > > > CIR and Cisco's BE set to the difference between providers
> > > CIR and port
> > > > speed.
> > > >
> > > > I'm posting this back to the list to hopefully open up
> > > discussion again.
> > > >
> > > > -----Original Message-----
> > > > From: kpalmer [mailto:kip.palmer@verizon.net]
> > > > Sent: Sunday, August 25, 2002 8:27 PM
> > > > To: 'Jim Brown'
> > > > Subject: RE: I need FRTS help or review
> > > >
> > > >
> > > > Line speed | Access Rate | Port Speed
> > > > =======================================
> > > > What you bought from the Provider. Per DLCI.
> > > >
> > > >
> > > > Average Rate | configured CIR (not mincir)
> > > > =======================================
> > > > When Shaping 128 to 64, it's 64k, with Bc ='s the Average
> > > Rate of remote
> > > > 64, /8.
> > > >
> > > > -----Original Message-----
> > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]
> > > On Behalf Of
> > > > Jim Brown
> > > > Sent: Sunday, August 25, 2002 1:04 PM
> > > > To: ccielab@groupstudy.com
> > > > Subject: I need FRTS help or review
> > > >
> > > >
> > > > Everything I have read about FRTS doesn't seem to clear up
> > > the use of
> > > > BE, BC, CIR, and MINCIR. I have been unable to locate a
> > > solid resource
> > > > explaining the concept with any finality.
> > > >
> > > > I've read most of the relevant Usenet postings on Deja,
> > watched the
> > > > threads on groupstudy, scoured CCO, and examined the QOS
> > v1.0 course
> > > > material.
> > > >
> > > > I will throw out my assumptions and let list members either
> > > verify or
> > > > shoot holes on my take of FRTS.
> > > >
> > > >
> > > > A few definitions up front:
> > > >
> > > > AR is the Access Rate or Port Speed of the connection to
> > > the frame relay
> > > > cloud. This is the maximum number of bits that can be
> > > transmitted to the
> > > > cloud.
> > > >
> > > > CIR is the Committed Information Rate. This is the
> > maximum number of
> > > > bits the provider promises to transmit. Anything above the
> > > CIR and below
> > > > the access rate will have the DE bit marked and is eligible for
> > > > discard/drop during times of congestion.
> > > >
> > > > Lets take a hypothetical circuit for instance, a port speed
> > > of 96Kbps
> > > > and a CIR of 64Kbps.
> > > >
> > > > The way I read the documentation, in a Cisco configuration
> > > CIR should be
> > > > set to the actual provider CIR or 64000. The BE or burst
> > > excess should
> > > > be set to the difference between the access rate and the
> > > CIR. I think BE
> > > > should be set to 32000, the difference between 96 and 64.
> > > >
> > > > Here is a brief sample config:
> > > >
> > > > map-class frame-relay TestShape
> > > > frame-relay cir 64000
> > > > frame-relay be 32000
> > > >
> > > >
> > > > The map-class could then be applied to the frame map or the
> > > interface. I
> > > > was previously under the impression you would set the Cisco
> > > CIR to the
> > > > port speed and the minCIR to the provider contracted CIR. I
> > > don't think
> > > > this is really the case?
> > > >
> > > > Here is an example:
> > > >
> > > > map-class frame-relay TestShape
> > > > frame-relay cir 96000
> > > > frame-relay mincir 64000
> > > >
> > > > Comments or suggestions? Is this wrong, why or why not?
> > > >
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:41 GMT-3