From: John Underhill (stepnwlf@magma.ca)
Date: Wed Jun 16 2004 - 13:19:00 GMT-3
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_guide09186a0080087b91.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
>
>
> _______________________________________________________________________
> 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
>
>
>
> ________________________________
>
> Do you Yahoo!?
> Yahoo! Mail
> <http://us.rd.yahoo.com/mail/taglines/*http://promotions.yahoo.com/new_m
> ail/static/protection.html> - You care about security. So do we.
>
> _______________________________________________________________________
> 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