From: John Underhill (stepnwlf@magma.ca)
Date: Tue Jun 15 2004 - 17:05:15 GMT-3
MINCIR is the throttle down value. When the router receives BECNs and is
configured for adaptive shaping, the router throttles down to this limit to
avoid congestion, which in turn is relying on an end stations windowing
mechanism to slow traffic flow. (default is half of CIR). There are designs
where you do not want to lose any traffic, but would rather rely on a qos
mechanism to gaurantee bandwidth, such as in voice/video. In a case like
this, you set mincir to cir rate and increase the number of TC intervals by
manipulating BC to be a smaller fraction of CIR.
For Voice: TC should be 10ms, set TC time with BC as 1/100th of CIR.
So CIR / 100 = BC
Ex. CIR = 64k | 64000 /100 = 640 | BC = 640
For converting serialization delay to 10ms:
Serial_delay = frame_size Bps /link_speed bps
Or bandwidth /8 * .01 =10ms serialization
Ex. 64000 /8 = 8000 | 8000 * .01 = 80 or 80k
For Data:
BC - CIR/8 =125ms
AR Access Rate - Interface speed.
CIR Committed Information Rate - Provider guaranteed sustainable data
transfer rate.
BC Committed Burst rate - Bits transferred per TC interval.
BE Burst Excess rate - Number of uncommitted bits to transfer on 1st TC
interval.
TC Committed time interval - (BC + BE) per interval (10 - 125 ms).
BECN Backwards Explict Congestion Notification. Notifier of congestion
frame.
----- Original Message -----
From: "Geert Nijs" <geert.nijs@simac.be>
To: "Brian McGahan" <bmcgahan@internetworkexpert.com>; "studygroup"
<ccielab@groupstudy.com>
Sent: Tuesday, June 15, 2004 1:52 PM
Subject: MINCIR vs CIR
> I am also confused about the deliniation between CIR and MINCIR. Can
> someone give some examples on how the lab
> would formulate these parameters ?
>
> If the lab specifies:
> "Your ISP provider will mark every packet above 48kbps
> with the DE-bit"
>
> Then CIR = 48 kbps ? Right ?
>
>
> If the lab specifies:
> "Your ISP provider will mark every packet above 48kpbs
> with the BECN-bit"
> (in the opposite direction is implicitely
> assumed here ??)
>
> Then MINCIR = 48 kbps ? Right ?
>
> Regards,
> Geert
>
> -----Oorspronkelijk bericht-----
> Van: nobody@groupstudy.com [mailto:nobody@groupstudy.com] Namens Brian
> McGahan
> Verzonden: dinsdag 15 juni 2004 19:27
> Aan: studygroup
> Onderwerp: RE: Bandwidth Vs MinCIR for CBWFQ
>
>
> The MINCIR value in the frame-relay map-class is simply used to
> define a worst case rate you will shape down to when the BECN bit is set
> in frames you receive from the frame-relay network.
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > samccie2004@yahoo.co.uk
> > Sent: Monday, June 14, 2004 12:29 PM
> > To: studygroup
> > Subject: Bandwidth Vs MinCIR for CBWFQ
> >
> > Hi Group
> >
> > When asked to guarantee BW foe QOS using CBWFQ on interfaces
> encapsulated
> > with frame-relay. What is the correct way to do so.
> >
> > Do I apply Bandwidth statement as I would for a HDLC interafce or even
>
> > ethernet, or do I rely on shapping DLCI with a MIncir equal the BW
> > required.
> >
> > TIA
> >
> > Sam
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
############################################################################
#########
> This e-mail and any attached files are confidential and may be legally
privileged.
> If you are not the addressee, any disclosure, reproduction, copying,
distribution,
> or other dissemination or use of this communication is strictly
prohibited.
> If you have received this transmission in error please notify Simac
immediately
> and then delete this e-mail.
>
> Simac has taken all reasonable precautions to avoid virusses in this
email.
> Simac does not accept liability for damage by virusses, for the correct
and complete
> transmission of the information, nor for any delay or interruption of the
transmission,
> nor for damages arising from the use of or reliance on the information.
>
> All e-mail messages addressed to, received or sent by Simac or Simac
employees
> are deemed to be professional in nature. Accordingly, the sender or
recipient of
> these messages agrees that they may be read by other Simac employees than
the official
> recipient or sender in order to ensure the continuity of work-related
activities
> and allow supervision thereof.
>
############################################################################
#########
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:41 GMT-3