Discussion in 'Cisco' started by bleed-22, Jun 8, 2004.

  1. bleed-22

    bleed-22 Guest


    The vast majority of service-providers provision traffic parameters such
    that Bc=CIR. This means that the service-provider's Tc interval = 1 second.
    Remember, Tc=Bc/CIR. (This will not be the Tc interval you see on your
    Cisco router, however. More on this later.)

    For example, a service provider might tell you your parameters are 384kbps
    CIR, 384kb Bc (per Tc), and 384k Be (per Tc). What does this mean?

    First, let me explain what the difference is between green, amber and red
    frames. "Green Frames" constitute traffic that is less than or equal to Bc.
    "Amber Frames" constitute traffic exceeding Bc but less than Bc + Be. "Red
    Frames" are traffic exceeding "Bc + Be." In the example above, that means

    Green Frames 0 - 384kb (DE = 0)
    Amber Frames 384kb - 768kb (DE = 1)
    Red Frames 768kb or more (Discarded/Dropped) **

    In this example, you could say that the service-provider is policing at

    **It used to be more common for service-provider switches to pass a certain
    amount of Red Frames through the network (DE =1, just like Amber Frames).
    In the face of congestion, service-providers would drop Red Frames first,
    and then Amber frames. At this time, of the 100+ customer networks we
    monitor and the thousands of PVCs they have, virtually all of them drop all
    red frames at the service-provider's edge (that is, the frame never makes
    into the provider's network). We work with five major frame-relay
    service-providers, and this seems to be the norm. For some PVCs, however,
    they do allow red frames. For the sake of elegance, I don't try to
    compensate for the allowance of red frames.


    We're going to assume for this article that you have configured a single PVC
    under a subinterface.

    Well, given the example above, the first thing you must know is that you can
    not put in a CIR and Bc combination that would result in a Tc of 1 second.
    Consider the following map-class:

    map-class frame-relay 384k
    frame-relay adaptive becn
    frame-relay cir 384000
    frame-relay bc 384000
    frame-relay be 384000
    frame-relay mincir 384000

    If you were to apply this to a sub-interface and then do a "show frame-relay
    traffic-shape" on that sub-interface, you would see an interval of 125ms.
    This is because a Cisco router will only allow an interval in the range of
    10ms - 125ms. It just so happens, Cisco recommends an interval of 125ms for
    data-only PVCs.

    Careful now: When you enter cir and mincir values, you are entering them in
    *kbps.* When you specify Bc and Be in your map-class, you are specifying Bc
    and Be for *one Tc interval.*

    So, if 1 interval is 125ms (or 1/8 of a second), and the service-provider's
    interval is 1 second, then you must divide the service-providers Bc and Be
    by 1/8.

    384000 / 8 = 48000.

    So your map-class will look like this:

    map-class frame-relay 384k
    frame-relay adaptive becn
    frame-relay cir 384000
    frame-relay bc 48000
    frame-relay be 48000
    frame-relay mincir 384000


    I would apply this configuration to both ends of this PVC.

    The proof is in the pudding:

    Now, do a "show frame-relay traffic-shape" on that subinterface.

    The "byte increment" is 6000 bytes. This means the router can sustain
    transmitting 6000 bytes per Tc, or 48000 bits every 125ms. That would mean
    your sustained rate is 384000bps, which is your guaranteed rate from your
    provider. This is your Bc value at work.

    The "byte limit" is 12000 bytes. Here you are combining your Bc and Be
    values. This means the router can burst up to 12000 bytes per Tc, or 96000
    bits every 125ms. This means what? (Remember, frames exceeding 384kbps, but
    remaing below 768kbps are Amber frames (DE =1)). This means that in the
    absence of congestion along the PVC path, your router can transmit up to

    With this frame map, your traffic should not exceed 768kbps, so you will
    remain within the restrictions placed on you by your service-provider while
    maxmizing the bandwidth available to you.

    So what happens when there is congestion and the full 768kbps is not
    available to you? A frame switch in the PVC path will send a BECN frame to
    the busy transmitter on one end of the of the PVC. If your router receives
    a BECN, it will back off 1/8 of it's current rate. If the congestion is
    persistant your router will continue to do this until it reaches mincir
    (configured in the map-class), which is your guaranteed rate from the
    service-provider. When the BECNs cease, your router will increase your
    transmit rate each interval until it reaches 768kbps per second again, or
    until it receives another BECN.
    bleed-22, Jun 8, 2004
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jose E. Calderon
    Jose E. Calderon
    Oct 23, 2003
  2. wr
  3. Replies:
    Nov 18, 2003
  4. harry

    ip over frame relay

    harry, Nov 27, 2003, in forum: Cisco
  5. Vimokh
    Sep 6, 2006

Share This Page