From: stefan vogt (stefan-uwe_vogt@web.de)
Date: Sat Jan 04 2003 - 11:07:27 GMT-3
Hello Tony,
I have some problems to understand your example.
I agree to
R1
CIR=512000 (port speed of local)
MinCIR=384000 (carrier enforced CIR)
But how do you derive
Be=1544000 (port speed of remote)
Bc=193000 (1/8th port speed of remote)?
http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a00800d6788.shtml
states that
1. The Tc value is not directly configured on Cisco routers. It is calculated after the Bc and CIR values are configured
2. Tc cannot exceed 125 ms
When using Tc = Bc / CIR with your values then Tc=193000[kbit]/384000[kbit/s]~0,5s... I think I have to use the carrier enforced Cir in this equation?
Who can help me out of this?
Thanks,
Stefan
> ----- Original Message -----
> From: "Tony Schaffran" <tschaffran@cconlinelabs.com>
> To: "Joe Chang" <changjoe@earthlink.net>; <ccielab@groupstudy.com>
> Sent: Friday, January 03, 2003 12:22 PM
> Subject: Re: FRTS Question
>
>
> > Actually, that is not quite correct. The CIR and MinCIR is the only
> > parameter provided by the service provider. FRTS, as I understand it, is
> a
> > way to get more out of your service provider by bursting until congestion
> is
> > detected and lowering your risk for packet drop's. CIR, Bc, and Be are
> used
> > to calculate an expectable burst rate based on your router port speeds you
> > have negotiated with your service provider. (ie. 384k CIR burst to 512k)
> > 512k being your port speed.
> >
> > Let's keep it simple and say that is what you have negotiated with your
> > provider on R1 and 768k burst to T1 at R2. For FRTS, these would be your
> > settings:
> >
> > R1
> > CIR=512000 (port speed of local)
> > Be=1544000 (port speed of remote)
> > Bc=193000 (1/8th port speed of remote)
> > MinCIR=384000 (carrier enforced CIR)
> >
> > R2
> > CIR=1544000 (port speed of local)
> > Be=512000 (port speed of remote)
> > Bc=64000 (1/8th port speed of remote)
> > MinCIR=768000 (carrier enforced CIR)
> >
> >
> >
> >
> > Tony Schaffran
> > Network Analyst
> > CCNP, CCNA, CCDA,
> > NNCSS, NNCDS, CNE, MCSE
> >
> > www.cconlinelabs.com
> > "Your #1 choice for Cisco rack rentals."
> >
> >
> > ----- Original Message -----
> > From: "Joe Chang" <changjoe@earthlink.net>
> > To: <ccielab@groupstudy.com>
> > Sent: Friday, January 03, 2003 6:32 AM
> > Subject: Re: FRTS Question
> >
> >
> > > I think the CIR , minCIR, Bc and Be values that are determined by the FR
> > > service provider. The customer-end would have to follow these values
> when
> > > configuring FRTS. My reasoning is that the purpose of FRTS is to avoid
> > frame
> > > relay discards within the provider's network, and only the provider can
> > tell
> > > what FRTS parameters will avoid congestion.
> > >
> > > However I'm not dismissing your question; it is incredibly relevant in
> the
> > > real world. My personal experience with union-entrenched FR suppliers is
> > > that you would be lucky to get them tell you what CIR has been
> provisioned
> > > for you.
> > >
> > > In your calculations remember that Bc = CIR* Tc. When you scale up the
> > Bc,
> > > the Tc will decrease, you will have to consider more slots in your
> second
> >
> > > example.
> > >
> > > I have a question myself: is it possible to implement congestion
> > management
> > > as CBWFQ on the same interface where FRTS is configured? How about RSVP?
> > >
> > > ----- Original Message -----
> > > From: "Joe" <groupstudy@comcast.net>
> > > To: <ccielab@groupstudy.com>
> > > Sent: Thursday, January 02, 2003 11:26 PM
> > > Subject: FRTS Question
> > >
> > >
> > > > This is a lengthy question, but I would really appreciate the time you
> > > > might take to help me with this.
> > > >
> > > > When configuring FRTS, the value chosen for Bc is typically CIR/8,
> > > > assuming that an interval Tc of 125 ms is acceptable. Assume I have
> no
> > > > real-time traffic such as voice or video.
> > > >
> > > > For the sake of example, suppose I have a circuit that is 4 timeslots,
> > > > or 256000 bps and the carrier CIR is 192000 bps. At the other end of
> > > > the link I have a T1 with a carrier CIR of 768000 bps and this end
> also
> > > > supports other PVCs. I am going to want to configure FRTS on the T1
> > > > side of the link for two reasons: 1) so it can throttle down to the
> > > > lower capacity link and 2) so I can reserve bandwidth for the other
> PVCs
> > > > that are being services.
> > > >
> > > > The first question is this: When deciding on Bc, is the value for CIR
> > > > taken from the CIR you specify in the FRTS config or is it 1/8 the CIR
> > > > from the carrier?
> > > > The second question is this: What if any are the benefits of shaping
> on
> > > > the lower speed link as well? Would this use the same parameters for
> > > > shaping?
> > > >
> > >
> > ------------------------------------------------------------------------
> > > > ----------------------------------------------
> > > >
> > > > This is what I believe to be true about FRTS as it applies to this
> > > > example:
> > > >
> > > > First of all, I would configure CIR = 256000 and MINCIR = 192000.
> > > > Anyone disagree with that?
> > > >
> > > > If I configure Bc to be 192000/8 or 24000, then I will be sending out
> > > > 24000 bits every time interval. This allows me to specify a Be of
> > > > 64000, which would then be transmitted during the first time interval
> if
> > > > no congestion is detected. The data transmitted is:
> > > >
> > > > Data transmitted = (Bc+Be) + Bc + Bc + Bc + Bc + Bc + Bc + Bc =
> > > > (24000+64000) + 24000 + 24000 + 24000 + 24000 + 24000 + 24000 + 24000
> =
> > > > 256000
> > > >
> > > > As long as I don't experience congestion, this seems like a desirable
> > > > flow of traffic, even though some traffic can be marked DE.
> > > >
> > > > On the other hand, if I configure Bc to be 256000/8 or 32000, then I
> > > > will be sending out 32000 bits every time interval. If I configure a
> Be
> > > > of anything other than 0, I will attempt to transmit this during the
> > > > first time interval. Suppose I set Be to 64000 again in this case.
> The
> > > > data transmitted is:
> > > >
> > > > Data transmitted = (Bc+Be) + Bc + Bc + Bc + Bc + Bc + Bc + Bc =
> > > > (32000+64000) + 32000 + 32000 + 32000 + 32000 + 32000 + 32000 + 32000
> =
> > > > 320000
> > > >
> > > > In this case I am attempting to transmit beyond the physical capacity
> of
> > > > the 256000 bps link, so 64000 bits of traffic will be FIFO queued
> > > > (unless I specify otherwise.) If I queue and carry over 64000 bits
> into
> > > > the next time interval then I can no longer burst, so I am down to a
> > > > rate of 256000 bits again. But this is STILL over the carrier CIR, so
> > > > this traffic is marked DE. This seems like it would create the
> > > > potential for packet drop/loss.
> > > >
> > > > So which is the better configuration?
> > > >
> > > > Thanks!
> > > >
> > > > Joe
> > > >
> > > >
> > > > As a follow on to this:
> > > >
> > > > Please take a look at the link below. I can't quite grasp why the
> > > > author omits Be on the remote side but includes it on the hub side.
> > > >
> > > > I am also not in agreement with the math used to calculate the byte
> > > > increment at the bottom of the link.
> > > >
> > > > Any comments would be appreciated.
> > > >
> > > > Joe
> > > >
> > > > <http://www.cisco.com/warp/public/125/traffic_shaping_6151.html>
> > > > http://www.cisco.com/warp/public/125/traffic_shaping_6151.html
> > > > .
> > > .
> > .
> .
This archive was generated by hypermail 2.1.4 : Sat Feb 01 2003 - 07:33:41 GMT-3