RE: MINCIR vs CIR

From: Rohan Grover (rohang@cisco.com)
Date: Wed Jun 16 2004 - 13:06:22 GMT-3


Hi,

Just to continue on this thread...if a scenario asks for the following
1)FR service provider guarantees 64Kbps
2)FR link capacity provided by SP is 256 Kbps.

I would set it as follows

MinCIR = 64 Kbps
CIR = 256 Kbps
Bc = 32 Kb
Be = 0 (not asked for)

Would this be right?

Thanks
Rohan

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Geert Nijs
Sent: Wednesday, June 16, 2004 1:46 PM
To: Tom Rogers; Brian McGahan; studygroup
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