From: John Underhill (stepnwlf@magma.ca)
Date: Wed Jun 16 2004 - 14:08:33 GMT-3
Disregard- I don't read my own emails :o)
BTB: The provider is likely going to tell you to hardcode the lmi, I am
guessing that most telcos are using Nortel switches.
> correction.. (and not many providers are NOT using cisco lmi, because they
> have to maintain
> vendor neutral standards..).
> ----- Original Message -----
> From: "John Underhill" <stepnwlf@magma.ca>
> To: "Geert Nijs" <geert.nijs@simac.be>; "Tom Rogers" <cccie71@yahoo.com>;
> "Brian McGahan" <bmcgahan@internetworkexpert.com>; "studygroup"
> <ccielab@groupstudy.com>
> Sent: Wednesday, June 16, 2004 12:19 PM
> 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_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
> > >
> > >
> > >
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:41 GMT-3