From: kym blair (kymblair@xxxxxxxxxxx)
Date: Fri Feb 15 2002 - 20:23:17 GMT-3
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 20 2002 - 13:46:24 GMT-3