[nsp] Frame-relay help please and article review...

[ringwyrm27]

I have some Frame-Relay questions for Lucent AND Cisco people:

Lucent People:
What is the difference between "Simple" and "Jump" Rate Enforcement Schemes?
What do they do?
What is a "bad pvc"?  Why does "simple" rate enforcement disable "bad pvc"
detection?

Cisco People:
When BECNs cease, at what rate does transmission increase per interval?

When you do a "show frame-relay traffic-shape" on an interface, it shows the
byte-limit.  The byte-limit is per interval.  It is Bc + Be.
My question is, doesn't a cisco router transmit all of the excess for the
whole second "in the first interval"?

If that's true, wouldn't the first interval be longer than the other
intervals?  I'm a little confused on the mechanics of this concept, although
the concept of Bc and Be is easy enough.


And lastly...  I was asked to write on an article based on my experience
trouble-shooting frame-relay issues at my company.  It is below.  If you
feel like doing so, please read it.  Suggestions and insults are welcome.

<<snipped some introductory stuff that doesn't matter>>

SERVICE PROVIDER TRAFFIC PARAMETERS AND FRAME "SPEAK".

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
this:

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
768kbps.

**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.

CISCO ROUTER FRAME-RELAY MAP-CLASSES

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
768kbps!!!  Wow, just like your service-provider provisioned you!

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.








Ringwyrm