From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Wed Jun 16 2004 - 14:31:46 GMT-3
John,
It's not listed in the standards because it's a Cisco specific
implementation. minCIR is a value used in conjunction with adaptive
frame-relay traffic-shaping to define the lowest possible value you will
shape down to in the case of a congestion notification. Congestion
notification can occur due to receipt of a BECN notification, a
foresight notification, or due to the exceeding of a defined output
queue length.
The logic of averaging a rate higher than what you are
provisioned is that you are betting that the provider cloud is not
congested 100% of the time. By configuring an average shaping rate
(Cisco CIR) to higher than what is provisioned (provider CIR, Cisco
minCIR), you are betting on the fact that the cloud will notify you of
congestion with a BECN or foresight notification, at which time you will
slow down.
The biggest confusion with Cisco's FRTS is their usage of the
term CIR. Cisco's CIR value in the frame-relay map-class configuration
simply defines the rate at which traffic is moved from the
traffic-shaping queue to the transmit ring of the interface. This value
does not relate to the provisioned rate for the circuit. For this
reason they added the additional value of minCIR to have a field that
may relate to the provisioned rate of the circuit.
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
> John Underhill
> Sent: Wednesday, June 16, 2004 11:19 AM
> To: Geert Nijs; Tom Rogers; Brian McGahan; studygroup
> Subject: Re: MINCIR vs CIR
>
> For one thing, it is unlikely that you will see mincir as part of your
> SLA,
> the switch does not know what you have set mincir to, or how your
router
> will react to becns, but only drops traffic when it exceeds a certain
> rate,
> (and not many providers are using cisco lmi, because they have to
maintain
> vendor neutral standards..). Mincir is not part of the lmi exchange
> standard, because it is a local, discretionary value. If you have
> purchased
> 128k, and they start dropping traffic at 64k, it's time to put your
> yelling
> hat on and call the provider.
> CIR = the bandwidth you have purchased.
> FRF NNI agreement standard:
> http://www.mplsforum.org/frame/Approved/FRF.2/FRF_2_2-final.pdf
>
> <Cisco Quote:>
> When the congestion level exceeds a configured value called queue
depth,
> the
> sending rate of all PVCs is reduced to the minimum committed
information
> rate (minCIR). As soon as interface congestion drops below the queue
> depth,
> the traffic-shaping mechanism changes the sending rate of the PVCs
back to
> the committed information rate (CIR). This process guarantees the
minCIR
> for
> PVCs when there is interface congestion.</Quote>
> Seems pretty plain to me.. Mincir is a congestion control mechanism.
>
http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_
gu
> ide09186a0080087b91.html
>
> Here is a good explaination of how frame is working, including all the
> standards, note in an illustration of an lmi frame, there is no
'mincir'
> field.
> http://www.protocols.com/pbook/frame.htm
>
>
>
> ----- Original Message -----
> From: "Geert Nijs" <geert.nijs@simac.be>
> To: "Tom Rogers" <cccie71@yahoo.com>; "Brian McGahan"
> <bmcgahan@internetworkexpert.com>; "studygroup"
<ccielab@groupstudy.com>
> Sent: Wednesday, June 16, 2004 4:15 AM
> Subject: RE: MINCIR vs CIR
>
>
> > Higher average bandwidth maybe ??
> >
> > I know many people think that CIR is "the guaranteed rate". And, in
real
> > life, many times, MINCIR is equal to CIR.
> > But, as you can read in the white paper on the internetworkingexpert
> > site, MINCIR is the rate at which your service provider will start
> > marking packets as DE.
> >
> > So, the question now is: why not try to sent at a higher rate and
> > falling back to MINCIR when we receive BECNs ??
> > Suppose there is no congestion in the Frame Relay cloud of the ISP,
the
> > ISP marks packets with DE but they don't get dropped
> > since there is no congestion. So we could sent at a higher
rate.......
> >
> > So, when the lab says "Your ISP will mark every packet above 48kbps
with
> > the DE-bit",
> > then, i must correct myself, and say that 48kbps is the MINCIR.
> > I can try to send at a higher rate, and fall back to the MINCIR when
> > congestion occurs.
> > In this case, my CIR and the frame-relay providers CIR are
> > different.....
> > Right ?
> >
> > Geert
> >
> > -----Oorspronkelijk bericht-----
> > Van: Tom Rogers [mailto:cccie71@yahoo.com]
> > Verzonden: woensdag 16 juni 2004 5:08
> > Aan: Geert Nijs; Brian McGahan; studygroup
> > Onderwerp: Re: MINCIR vs CIR
> >
> >
> > Geert,
> > If DE is going to set above minCIR, then what the point of
> > having cir?
> >
> > Tom
> >
> > Geert Nijs <geert.nijs@simac.be> wrote:
> >
> > 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
> >
> >
> >
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:41 GMT-3