Re: CIR in FRTS

From: Joe Astorino <jastorino_at_ipexpert.com>
Date: Wed, 15 Jul 2009 11:16:39 -0400

48k would be the rate you pay for, or the CIR from the perspective of the
SP. From your perspective it is the minCIR because it is what you are
guaranteed. 128k I would assume is the max rate you can possibly send
physically on the line (you have clock rate 128000 on one end of the link).
So in this case, you can "burst to port speed." That also explains why
anything OVER 48k is set to DE during congestion. You can burst to 128k all
day long if there is no congestion. The minute there is congestion, you are
limited down to 48k.

On Wed, Jul 15, 2009 at 9:05 AM, William McCall <william.mccall_at_gmail.com>wrote:

> While I think you have a point about looking at the access rate, there
> is another key to remember in the scenario presented.
>
> As people who configure this daily and implement it per the SP's
> guidelines, we would tend to think of DE marking as indicating traffic
> not under contract, HOWEVER there is a key phrase in this scenario
> which lends itself to determining that the CIR is 128k and that minCIR
> is 48k:
>
> " *during congestion* your provider will mark any traffic in excess of
> 48 kbps as discard eligible."
>
> Generally speaking, traffic outside of CIR is marked DE. If the
> scenario is stating that it is marked DE only during periods of
> congestion, then it seems to be that CIR would be the 128k even though
> we would probably never ever purchase it in this manner (that is, a
> rate that is committed and not DE until congestion occurs)
>
> The difference is that if we call it excess traffic, we are saying
> that the traffic is truly out of contract. Furthermore, the scenario
> limits the use of variables to cir, mincir, and Tc (translates into
> Bc, blahblah)
>
> Under normal conditions, we want to be able to send 128K. Under normal
> conditions, this is fine. During congestion we will receive BECN and
> turn on the adaptive shape. We are absolutely, positively, without a
> doubt guaranteed 48kbps.
>
> --William McCall
>
> On Wed, Jul 15, 2009 at 7:27 AM, Santiago
> Enciso<santiago.enciso_at_gmail.com> wrote:
> > From my point of view this should be the confiruration
> >
> > 128 Kbps = Access rate (physical limit of the interface)
> > 48 Kbps = CIR
> > 48 Kbps = MINCIR
> > Bc = 6.000 bps
> > Be = 10.000 bps (AR - CIR)/tc
> > Tc = 125 msec
> > frame-relay adaptive-shaping becn
> >
> > The requirements allow to burst above the CIR (until 128kbps) but if
> > congestion is notified by the service provider with BECN bit set the
> > interface should send again at mincir wich in this case is the CIR.
> >
> > HTH
> >
> > Santiago E
> >
> >
> > -----Mensaje original-----
> > De: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] En nombre de
> andrew
> > Enviado el: Miircoles, 15 de Julio de 2009 07:17
> > Para: 'Vinu'; 'kaniyath minha'
> > CC: 'Cisco certification'
> > Asunto: RE: CIR in FRTS
> >
> > You mincir could just as easily be 48k given that the service provider
> has
> > given you a CIR of 48K, you will always have that amount of bandwidth, if
> > adaptive shaping is on you transmission rate can be dropped to mincir not
> > cir.
> >
> > So I would use mincir because in an adaptive shaping scenario if you used
> > CIR you could end up only transmitting at 24k a sec
> >
> > -----Original Message-----
> > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> Vinu
> > Sent: Wednesday, July 15, 2009 7:20 PM
> > To: kaniyath minha
> > Cc: Cisco certification
> > Subject: Re: CIR in FRTS
> >
> > Hi Minha,
> >
> > If your contract with SP states "during congestion your provider will
> mark
> > any traffic in excess of 48 kbps as discard eligible ", your CIR is
> 48Kbps
> > and your Peak information rate would be 128kbps. and Tc is 125 ms
> >
> > On Wed, Jul 15, 2009 at 12:52 PM, kaniyath minha
> > <minha.kaniyath_at_gmail.com>wrote:
> >
> >> Dear
> >>
> >> I have one doubt in following question.
> >>
> >> Question
> >>
> >> Configure the R3 frame relay interface for rate limiting by configuring
> > the
> >> parameters CIR,
> >> TC and MINCIR,
> >>
> >> considering the following :
> >>
> >> Your maximum throughput is 128 kbps, during congestion your provider
> will
> >> mark any
> >> traffic in excess of 48 kbps as discard eligible. Make sure your
> > throughput
> >> changes
> >> accordingly, based upon BECN received only, your token bucket interval
> in
> >> 125 ms.
> >>
> >>
> >> In this question What is CIR 128 or 48?
> >>
> >> Please help me.
> >>
> >> Thanks and Regards
> >>
> >>
> >> Blogs and organic groups at http://www.ccie.net
> >>
> >> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Regards,
> >
> > Vinu
> > CCIE# 16439
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Regards,
Joe Astorino - CCIE #24347 R&S
Technical Instructor - IPexpert, Inc.
Cell: +1.586.212.6107
Fax: +1.810.454.0130
Mailto:  jastorino_at_ipexpert.com
Blogs and organic groups at http://www.ccie.net
Received on Wed Jul 15 2009 - 11:16:39 ART

This archive was generated by hypermail 2.2.0 : Sat Aug 01 2009 - 13:10:22 ART