While at a first glance, Frame Relay Traffic Shaping (or FRTS) seems daunting..it’s really not bad. For those of you unfamiliar with FRTS, I’ll present a couple of scenarios where you may need to configure it.

1. High speed interface –> Low speed interface:  Picture you have one node connecting to the frame relay cloud at 1.544 Mbps, and the router at the far end connecting to the cloud at only 54Kbps. You are essentially creating a bottleneck in this scenario, and will surely experience congestion due to the downstream router having a lower access rate. Shaping the traffic ensures you are sending the data at a speed the other end can handle.
2. Oversubscription: Let’s say your access rate (the max rate that you can send to the provider) is 128Kbps, but your CIR is only 32Kbps. You can burst above the CIR, but if congestion occurs drop back to your CIR. This ensures that bandwidth is not sitting idle and going unused..the idea is that not all users will require 100% of their bandwidth all of the time.

The information I’m going to present is mostly aimed at the first scenario. Let’s say we have a topology as such:

In such a scenario, the Access rate- or the maximum rate that the user can send data, is found on the serial links above. R1 can access the FR cloud at 256K, however R2 can only access it at 128K. Because of this mismatch, it would experience congestion at the interface leaving the FR cloud onto R2′s serial link. Let’s get some terminology out of the way that we must take care of.

AR- Access-rate- The maximum rate the user can inject data into the FR network

CIR- Committed Information Rate- The rate you would like to send under regular conditions to the service provider

Mincir- The actual guaranteed rate by the service provider. Sending less then this means you are not getting the bandwidth you have paid for. We can use mincir to “fall back” in times of congestion, and when things clear up bring our rate back to the CIR.

Tc- Time interval- By default, the service provider will divide one second into 8 parts, of 125ms in each “section”.

Bc- Committed Burst- CIR/Tc. What’s this mean? Say we have a CIR of 56000, then we divide that by the number of Tc intervals..by default 8. That means our Bc is 56000/8 = 7000 bits per timing interval. This means that every timing interval will send 7000 bits, 8 times to make up our CIR of 56000. Of course, we don’t have to send at that rate..if we don’t, the unused bandwidth can go to your token bucket filter..which allows you to burst above your Bc…this burst above Bc is called Be, or Excess burst.

Be- Excess Burst- Data sent above the Bc (Committed burst) per Tc (Timing interval).

Be (Excess Burst) Breakdown: If you are sending below your CIR, you can accrue “tokens” in your token bucket, to use at a time you need to burst above your Bc. It is important to note that you should only configure a Be value (the amount you want to burst above Bc..provided you have the credit available in your token bucket) if your CIR is LESS then your AR. This makes sense, if your AR (access rate) is 56k, and your CIR is 56k..you don’t want to try to burst above that. It will not work!

Case study: Without going into the configuration yet, the above example uses the adaptive shaping becn command. This causes the router to react to becn’s and adjust it’s throughput on the fly. Using the diagram above, let’s review what exactly is going on. In the first interval (0-125ms), we use our token bucket credit, and send our Bc plus our Be, with our total throughput for that interval being 24k..for that ONE interval. After the first time interval, we start sending at our CIR, which is 128k divided by the amount of time intervals- by default this is 8. That means we are sending 16000 bits per interval. The best way to think about this is that CIR is your regular throughput- over the period of 1 second. Your Bc is simply your CIR but broken up into time intervals.

Now, you’ll see at 500ms that we receive a BECN. FRTS throttles the transmit rate 25% once per interval, upon each BECN received until it reaches the Min CIR value, which in our case is 56k, or 7000 bits per interval. After throttling down to Min CIR, the router must allow 16 time intervals (2 seconds by default) to pass with no BECN’s being received, before ramping the transmit rate back up to the normal CIR. The amount it will increase by is called the byte limit, and can be seen with a show frame pvc X.

Interesting notes regarding FRTS:

• If you configure “frame-relay traffic-shaping” under the interface but with no map-class configured/specified, the default CIR value will be 56000 bps.
• By default, Min CIR is 1/2 of CIR (although in the above example we did it a little bit different)
• You cannot configure the interval (Tc). The router calculates Tc based on CIR/Bc values..so although you can’t explicitly configure Tc, you can influence it by CIR/Bc values..although this also has other implications.
• Bc = CIR/8 (by default), ie: 56000/8 = 7000 (Bc)
• After fully configuring FRTS, if you do a “show frame pvc x“, it will show “traffic shaping inactive”. It will not show active until traffic passes that fall within the scope of the shaping.
• Shaping activates upon the following events: BECN’s received and the DLCI is configured for adaptive shaping (BECN), FRF.12 fragmentation is configured with packets waiting to be fragmented, the number of bytes waiting to leave the interface is more then the byte limit (available credit)
• FRTS allows you to control per-VC shaping/traffic
• Can use WFQ/CQ/PQ or FIFO (FIFO by default)
• In addition to configuring adaptive shaping on BECN receipt, you can configure the interface to react to interface congestion

That’s all I really have for now. There’s a lot of little details for FRTS that can be kind of tricky, but as a whole it’s fairly straightforward. I hope to post several configuration examples in the next post, although I personally feel the difficulty in FRTS lies in the terminology/concepts. Once you get those the rest is cake. Take care!