From: Narvaez, Pablo (Pablo.Narvaez@xxxxxxxxxxxxx)
Date: Mon Mar 04 2002 - 21:30:29 GMT-3
I was double checking the explanation that Peter gave below... I wonder how he
came to "be" value? ..... is there a formula I can use to calculate the "be"? F
rom my understanding, if I'm given these values:
>>> > - at 48Kbps, discard eligible
>>> > at 64kbps, frame discard
then I would assume that the access-rate is 64k since I can't transmit anything
above that value and the packets will be dropped.... so, cir=48k and be=16k (b
e= access_rate - cir) ..... Is that ok? ...
Thanks!!
-hockito-
-----Original Message-----
From: Williams, Glenn [mailto:WILLIAMSG@PANASONIC.COM]
Sent: Martes, 19 de Febrero de 2002 08:46 a.m.
To: 'Peter Whittle'; kym blair
Cc: ccamarda@bellsouth.net; rwheat@ami.com.au; avantus1@hotmail.com; ccielab@gr
oupstudy.com
Subject: RE: FRTS
Peter,
Excellent explanation, and very timely for myself. Thanks for sharing this.
Have one question. Never heard of the Maximum Line Rate. So I understand
its calculation is = CIR + mincir/TC correct?
Is this a rough guideline on what the port speed ought to be?
TIA
GW
-----Original Message-----
From: Peter Whittle [mailto:peter@whittle-systems.demon.co.uk]
Sent: Friday, February 15, 2002 6:26 PM
To: kym blair
Cc: ccamarda@bellsouth.net; rwheat@ami.com.au; avantus1@hotmail.com;
ccielab@groupstudy.com
Subject: Re: FRTS
as a config then:
frame-relay cir 48000
frame-relay bc 6000
frame-relay be 2000
frame-relay mincir 16000
Peter
In message <F42fJ8VrRQvXlaoY99E00026258@hotmail.com>, kym blair
<kymblair@hotmail.com> writes
>So what was the answer? Here are BS's original parameters and solution.
>Please frame your corrected solution is a config like his (rather than
>text):
>
>> >> Kang BS wrote:
>>> > On below question, Which is a correct configuration?
>>> >
>>> > - at 48Kbps, discard eligible
>>> > at 64kbps, frame discard
>>> > when recieving BECN, 16kbps should be guaranteed.
>>> > basic time interval 125ms
>>> >
>>> > - My solution is
>>> > frame-relay cir 48000
>>> > frame-relay bc 6000
>>> > frame-relay be 16000
>>> > frame-relay mincir 16000
>>> >
>
>Thanks. Kym
>
>----------------------------------------------------------------------
>
>>From: Peter Whittle <peter@whittle-systems.demon.co.uk>
>>Reply-To: Peter Whittle <peter@whittle-systems.demon.co.uk>
>>To: Carolyn Camarda <ccamarda@bellsouth.net>
>>CC: Richard Wheat <rwheat@ami.com.au>, Kang BS <avantus1@hotmail.com>,
>> ccielab@groupstudy.com
>>Subject: Re: FRTS
>>Date: Fri, 15 Feb 2002 22:53:01 +0000
>>
>>Carolyn
>>
>>In Frame Relay
>>
>>CIR is the average rate that you can transmit at measured over a time
>>period Tc without having the ingress port on the Frame network flag your
>>frames as over contract by setting the DE bit.
>>
>>EIR is the rate that you can exceed CIR before the ingress port will
>>discard your frames.
>>
>>Bc is the total number of bits that you can send in period Tc and not
>>have the frames marked with DE.
>>
>>Be is the total number of bits in addition to Bc that you can send in
>>period Tc that the switch will allow before discarding any excess
>>traffic at the ingress port to the Frame network.
>>
>>These parameter are inter-related.
>>
>>CIR = Bc/Tc
>>
>>EIR = Be/Tc
>>
>>
>>So you only need to specify 2 of the parameters. On a Carrier grade
>>switch it is customary to specify CIR, Bc, and Be. Tc is normally fixed
>>for the entire network. Incidentally over here in Europe Tc in use on
>>most public networks is 1 Second.
>>
>>The shorter Tc the more responsive things are but you get less of a
>>bandwidth free ride. If you are implementing FRTS, it is quite likely
>>that you want to have the traffic shaper responsive so Tc as defined on
>>the router may very well be << Tc set by the Telco on the Frame Network.
>>
>>So looking at the traffic from a Frame Relay Network perspective if you
>>start CPE A end sending 0 traffic into the network and gradually
>>increase the traffic that you attempt to send the following will happen:
>>
>>1) traffic rate 0 up to CIR - Will be delivered to the B end.
>>
>>2) traffic rate exceeds CIR but is less than CIR + EIR - frames will
>>normally be delivered (depends how congested the network is, true in
>>Europe) but frames where the total number of bits sent in period Tc
>>exceed Bc will be marked with DE. Any DE marked frames may be discarded
>>by any of the switching nodes in the Frame network if a node is
>>congested.
>>
>>3) An attempt is made for the traffic rate to exceed CIR + EIR - All
>>frames will be discarded immediately at the port of ingress to the
>>network until the rate drops down below CIR + EIR.
>>
>>----
>>At the B end you will see:
>>
>>1) All frames delivered DE = 0 (or what ever was set by CPE at A)
>>
>>2) The first frames up to a total Bc bits sent will be received with DE
>>=0. The remaining frames up to an additional total of Be bits sent will
>>be received with DE=1
>>
>>3) The number of frames received will not increase. The total rate of
>>arrival = CIR + EIR.
>>
>>----
>>
>>In the real world (not as marketing tell it!)
>>
>>1) as described above - most of the time (If not time to seek a new
>>carrier)
>>
>>2) First frames up to a total of Bc bits sent will be received with DE =
>>0. Some of the remaining frames will be received <= an additional total
>>of Be bits sent will be received with DE = 1. The number less than
>>those sent is a measure of how congested your carrier's network is on
>>the path A to B.
>>
>>3) Will rate limit somewhere between CIR and CIR + EIR.
>>
>>When one of the nodes is congested it will set FECN = 1 on frames
>>forwarded towards the destination B. CPE B will then totally ignore the
>>FECN as customers are want to do. Some traffic will be going back the
>>other way. Ah ha! The congested node now has a frame returning to the
>>sender A so it sets BECN = 1 and forwards it to A.
>>
>>In the normal way the customer still ignores any notification of
>>Congestion and continues to send. The network becomes even more
>>congested. Time for some serious action! The congested node is nolonger
>>mildly congested (traffic exceeded a software configurable threshold
>>either on an interface - ok, or on the whole switch - BAD news!
>>Typically 50% of buffers in use / queues 50% full) but is seriously
>>congested (again determined in software on the switch, perhaps 75% of
>>buffers are in use / queues 75% full) so it starts to drop frames with
>>DE=1 but forwards those with DE=0.
>>
>>Now users being users send even more traffic so now the poor old switch
>>is in serious trouble! - "No room at the Inn!" There are ZERO free
>>buffers! So no option just drop all frames coming in to the switch.
>>
>>RESULT no frames delivered!
>>
>>"The moral of the story is, behave!"
>>
>>-----
>>
>>The real world amended for FRTS.
>>
>>CPE A attempts to send an average amount of traffic defined by CIR as
>>set on the router (This is probably higher than CIR defined by the Telco
>>on the switch) and to control the bursts by queuing the traffic on
>>egress from the router to delay some frames so as to reduce the average
>>rate of transmission. Result a happy network with minimum frames lost,
>>most of them arriving with DE = 0 and some of them arriving with DE = 1.
>>
>>If on some rare occasion the Telco network gets congested ('never
>>happens, honestly'). Then when a frame is received at CPE A with BECN =
>>1 (or more typically > 50% of the frames received have BECN = 1), FRTS
>>will slow down the average frame transmission rate to match the MINCIR
>>setting on the router. (In this case MINCIR is normally set to or below
>>the actual CIR on the Telco Switch.) So now as well behaved, good
>>router citizens, our traffic now obeys the recommendations and reduces
>>to comply with the Telcos CIR, all our frames get through and have DE =
>>0.
>>
>>When the congestion reduces and we receive less than 50% of our frames
>>with BECN = 1 we can step up slowly back towards our peak rate.
>>
>>The reason that we want to behave well, besides being good router
>>citizens, is that lost frames = lost TCP segments which causes TCP time-
>>outs and then re-transmissions. (Remember the slow start algorithm,
>>after every time-out we start with 1 segment wait for the successful
>>acknowledgement then on to 2 segments, then 3 ... until we are using the
>>full window size again or until another frame (segment) goes AWOL and
>>our throughput collapses again!)
>>
>>=================
>>
>>So back to the problem.
>>
>> >> > - at 48Kbps, discard eligible
>>
>> Set CIR = 48000 bits/S
>> =====
>>
>> >> > when receiving BECN, 16kbps should be guaranteed.
>>
>> Set MINCIR = 16000 bits/S
>> =====
>>
>> >> > basic time interval 125ms
>>
>> Tc = 125 mS = 0.125 S
>>
>>=> Bc = CIR x Tc = 48000 x 0.125 = 6000 bits
>> ====
>>
>> >> > at 64kbps, frame discard
>>
>> Need EIR = 64000 - 48000 = 16000 bits/S
>>
>> but Tc = 0.125 S
>>
>>=> Be = EIR x Tc = 16000 X 0.125 = 2000 bits
>> ====
>>
>>Port speed is independent of the above.However, see design guidance 3
>>below.
>>
>>So if CIR = 48 k, Tc = 0.125 S and Bc = 16000
>>then port speed must exceed 48000 + 16000/0.125
>> = 48000 + 128000
>> = 176000. (see design guidance 3 below)
>>
>>However, good design from a Frame Relay network perspective with out
>>oversubscription would lead to:
>>
>> 1) no individual CIR > 75 % port speed
>>
>> 2) sum of all CIRs on port < 75 % port speed
>>
>> 3) for each dlc in turn CIR + EIR < = port speed.
>>
>>
>>If oversubsciption then (2) is amended to:
>>
>>2') sum of all CIRs on port < 200 % port speed.
>>
>>Oversubscription is only available with the customers consent and CIR
>>guarantees are nolonger valid. It would normally only be used when the
>>customer knows that certain dlcs are not used simultaneously e.g some
>>are only used for over night back, time of day variations, or some of
>>the dlcs are only fro customer selected resilience to be used when the
>>main dlci goes down.
>>
>>
>>Remember all frames are transmitted bit synchronously onto the wire at
>>port speed, say 128k. If the CIR = 48k then you can send continuously at
>>48 K and frames will be delivered, DE = 0. You may burst above the CIR
>>up to CIR + EIR for a short period of time Tc and your frames will
>>normally get through, though some will have DE = 1. Say EIR = 16k, then
>>you can burst up to 64 k. You will never receive an average of more than
>>64 k no matter how much traffic you put into the network. If the network
>>is congested then you will receive between 48 and 64 k of traffic.
>>
>>
>>I hope that this helps.
>>
>>Peter
>>
>>
>> In message <01b401c1b663$8934c900$0301010a@oemcomputer>, Carolyn
>>Camarda <ccamarda@bellsouth.net> writes
>> >How do you figure the BE value of 16k makes the line rate 176k? It
would
>> >seem that with 8 time intervals at 6k, that would be 48k and then 16k BE
>> >which goes in the first time slot would
>> >equal a total of 64k.
>> >
>> >
>> >
>> >----- Original Message -----
>> >From: "Richard Wheat" <rwheat@ami.com.au>
>> >To: "Kang BS" <avantus1@hotmail.com>
>> >Cc: <ccielab@groupstudy.com>
>> >Sent: Friday, February 15, 2002 9:21 x
>> >Subject: Re: FRTS
>> >
>> >
>> >> Good day,
>> >>
>> >> I think your BE should be 2000 not 16000. BC + BE = maximum line
rate.
>> >> Your BE value means the maximum line rate is 176kbps.
>> >> Otherwise it looks ok.
>> >>
>> >> HTH,
>> >> Richard.
>> >>
>> >> Kang BS wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > I have already read lot of stuff about FRTS including all of mail in
>>the
>> >> > archives
>> >> > and cisco documents
>> >> > (http://www.cisco.com/warp/public/125/21.shtml
>> >> > http://www.cisco.com/warp/public/125/traffic_shaping_6151.html)
>> >> >
>> >> > But I am still confusing.
>> >> >
>> >> > On below question, Which is a correct configuration?
>> >> >
>> >> > - at 48Kbps, discard eligible
>> >> > at 64kbps, frame discard
>> >> > when recieving BECN, 16kbps should be guaranteed.
>> >> > basic time interval 125ms
>> >> >
>> >> > - My solution is
>> >> > frame-relay cir 48000
>> >> > frame-relay bc 6000
>> >> > frame-relay be 16000
>> >> > frame-relay mincir 16000
>> >> >
>> >> > is mine right or else?
>> >> >
>> >> > please help me.
>> >> >
>> >> > thanks in advance.
>> >> >
>> >> > BS Kang.
>> >> >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:56:52 GMT-3