From: Tony Schaffran (tschaffran@cconlinelabs.com)
Date: Sat Jan 04 2003 - 11:46:42 GMT-3
I just used the numbers that were given for an example. I did not do any
calculations.
If you calculate Tc, then the actual Bc would be 64000
Does that clear it up?
Tony Schaffran
Network Analyst
CCNP, CCNA, CCDA,
NNCDS, NNCSS, CNE, MCSE
CCOnlineLabs.com
http://www.cconlinelabs.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
stefan vogt
Sent: Saturday, January 04, 2003 6:07 AM
To: ccielab@groupstudy.com
Subject: Re: FRTS Question
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_note09186a
00800d6788.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