![]() |
|
|
|
#1 |
|
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!! 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 |
|
|