330 Chapter 5: Traffic Policing and Shaping

Table 5-2 Policing and Shaping: When to Use Them, and Where (Continued)

How Shaping Works

Shaping only makes sense when the physical clock rate of a transmission medium exceeds a traffic contract. The most typical case for shaping involves a router connected to a Frame Relay or ATM network. More often today, however, connections to ISPs use a point-to-point serial link or an Ethernet link between an enterprise and the ISP, with a traffic contract defining lower traffic volumes than the physical link. Starting with a physical installation using a higher-speed link allows for simple growth by just increasing the traffic contract.

Routers can only send bits out an interface at the physical clock rate. To have the average bit rate, over time, be lower than the clock rate, the router just has to send some packets for some specified time period, and then not send any packets for another time period. To average sending at a packet rate of half the physical link speed, the router should send packets half of the time, and not send the other half of the time. To make the average rate equal to 1/4 of the physical link speed, the router should send 1/4 of the time, and not send packets 3/4 of the time. Over time, it looks like a staccato series of sending, and silence.

You can understand traffic-shaping logic by reviewing just a few simple examples. Of course, you need to know a few more details for the exams! However, the basics follow these simple examples: If R1 has a 128-kbps access rate, and a 64-kbps CIR, and the engineer wants to shape the traffic to match CIR (64 kbps), R1 just has to send traffic on the link half of the time. If, over time, R1 sends traffic half of the time, at 128 kbps (because that’s the only rate it can actually send traffic), the average over that time is 64 kbps. The concept is that simple!

A few more simple examples here emphasize the point. Referring to Figure 5-4, assume R1 wants to shape at 96 kbps, because the Frame Relay switch is policing at 96 kbps. With a 128-kbps access rate, to shape to 96 kbps, R1 should send 3/4 of the time, because 96/128 = 3/4.

Again from Figure 5-4, if the Main router wants to shape the VC connecting it to R24 at 128 kbps, to avoid the egress-blocking problem, the Main router needs to send packets 128/1536

Traffic-Policing and Traffic-Shaping Concepts 331

(actual available bit rate for T/1 is 1.536 Mbps), or 1/12 of the time. If the Main router wants to shape that same VC to 64 kbps, to match the CIR, the Main router should send packets over that VC at 64/1536, or 1/24, of the time.

Traffic shaping implements this basic logic by defining a measurement interval, and a number of bits that can be sent in that interval, so that the overall shaped rate is not exceeded. Examples help, but first, Table 5-3 lists some definitions.

Table 5-3 Shaping Terminology

The actual processes used by traffic shaping, and the terms in Table 5-3, will make much more sense to you with a few examples. The first example, as outlined in Figure 5-5, shows the familiar case where R1 shapes to 64 kbps, with a 128-kbps access link.

Figure 5-5 Mechanics of Traffic Shaping—128-kbps AR, 64-kbps Shaped Rate

Send packets for 62.5 ms per Interval (1/2 the time) in Order to Average 64 kbps

So Bc = 8000 bits (1000 bytes)

SendingRate

128 kbps

0 kbps

0 125 250 375 500 625 750 875 1000 Time

(Ms)

Traffic-Policing and Traffic-Shaping Concepts 333

Again, the formula referring to CIR assumes that you shape to the CIR value, whereas the second formula refers to the shaping rate, because you can configure shaping to shape at a rate different from CIR.

Additional examples should bring the concepts together. Previously you read the example of the PB Tents company shaping at 96 kbps over a link using a 128-kbps clock rate, because the Frame Relay provider policed at 96 kbps. If the shaping function is configured with a shaping rate of 96 kbps, with no Bc value, the formulas specify the following:

Bc = .125 sec * 96,000 bits/sec = 12,000 bits

Figure 5-6 shows what happens in this example.

Figure 5-6 Mechanics of Traffic Shaping—128-kbps Access Rate, 96-kbps Shaped Rate

Bc = Tc * Rate

Bc = .125 sec * 96,000 bit/sec = 12,000 bits

At 128 kbps, Need 91.25 ms to Send 12,000 Bits

SendingRate

0 kbps

0 125 250 375 500 625 750 875 1000 Time

(Ms)

For each interval, shaping can release 12,000 bits, which takes 91.25 ms. 91.25/125 = 3/4, implying that the router will average sending bits at 3/4 of the clock rate, or 96 kbps.

Traffic shaping uses the idea of a number of bits per interval for implementation because it’s much more efficient than calculating rates all the time. The shaper just grabs the next packet, decrements the Bc values by the number of bits in the packet, and keeps doing that until the Bc value is consumed. At that point, shaping waits until the Tc has expired, when shaping gets to send another Bc worth of bits.

The length of Tc may have some impact on the delay and jitter characteristics of the packets being shaped. Consider another example, with the Main router sending packets to R24, shaping at 128 kbps, but with a T/1 access link. Figure 5-7 shows the shaping details.

334 Chapter 5: Traffic Policing and Shaping

Figure 5-7 Mechanics of Traffic Shaping—Main Router with 1.536 Access Rate, 128-kbps Shaped Rate

Bc = Tc * Rate

Bc = .125 sec * 128,000 bit/sec = 16,000 bits

At 1.536 Mbps, Need 16,000/1,536,000 = 10 ms to send 16,000 bits

SendingRate

1.536M

0 kbps

0 125 250 375 500 625 750 875 1000 Time

(Ms)

Simply put, at T/1 speeds, it does not take long to send the Bc worth of bits per interval. However, The Tc value may be a poor choice for delay-sensitive traffic. Suppose that a VoIP packet arrives at Main, and it needs to be sent to R24. Main uses LLQ, and classifies VoIP into the lowlatency queue, so the new VoIP packet will be sent next. That’s true—unfortunately, the packet sent just prior to the new VoIP packet’s arrival consumed all of Bc for this Tc. How long does the VoIP packet have to wait before the current Tc will end and a new one will begin? Well, it only took 10 ms to send the Bc worth of bits, so another 115 ms must pass before the current Tc ends, and the VoIP packet can be sent! With one-way delay budgets of 150 to 200 ms, a single shaping delay of 115 ms just will not work. Therefore, Cisco recommends that when you have delay-sensitive traffic, configure Bc such that Tc is 10 ms or less. In this same example, if the Bc were configured to 1280 bits, Tc = 1280/128,000 = .010 seconds, or 10 ms.

NOTE Many of you might be concerned about the relatively small Bc of 1280 bits, or only 160 bytes! Most packets exceed that length. Well, as it turns out, you will also typically use fragmentation in the exact same cases. To accommodate the same delay-sensitive traffic, the fragments will be of similar size—in fact, as you will read in Chapter 7, “Link Efficiency,” the fragmentation size will likely be 160 bytes in this particular example. Therefore, with delay-sensitive traffic, you will drive Tc down to about 10 ms by lowering Bc, and the Bc value will essentially allow a single fragment per Tc. By doing so, you reduce the shaping delay waiting on the next Tc to occur, and you reduce the serialization delay by fragmenting packets to smaller sizes.

The next several sections continue the discussion of how traffic shaping works, covering excess burst, queuing, adaption, and some concepts about enabling shaping.

Traffic-Policing and Traffic-Shaping Concepts 335

Traffic Shaping, Excess Burst, and Token Buckets

Traffic shaping includes the capability to send more than Bc in some intervals. The idea is simple: Data traffic is bursty, so after a period of inactivity, it would be nice if you could send more than Bc in the first interval after traffic occurs again. This extra number of bits is called the burst excess, or Be. Traffic-shaping tools allow Be as an option.

The underlying operation of traffic shaping to allow for Be requires a little more insight into how traffic shaping works, and it also requires us to understand the concept of token buckets. Token buckets can be used to describe how shaping and policing are implemented.

Ignoring Be for a moment, imagine a bucket filled with tokens, like subway tokens. In the token-bucket scenario, each token lets you buy the right to send 1 bit. One token bucket is used for formal operation of traffic shaping as discussed earlier; this bucket has a size of Bc. The bucket is filled to the brim, but no more, at the beginning of each Tc. Every time a packet is sent, traffic shaping spends tokens from the token bucket to buy the right to send the packet. If the packet is 1000 bits long, 1000 tokens are removed from the bucket. When traffic shaping tries to send a packet, and the bucket does not have enough tokens in it to buy the right to send the packet, traffic shaping must wait until the next interval, when the token bucket is refilled.

An analogy of token bucket is a child and the allowance the child receives every Saturday morning. For the sake of argument, assume the weekly allowance is $10. The child may spend the money every week; if the child doesn’t spend it, he may save up to buy something more expensive. Imagine that the child’s parents are looking at the child’s piggybank every Saturday morning, however, and if they find some leftover money, they just add a little more money so that the child always starts Saturday morning with $10! After a few weeks of this practice, the child would likely try to spend all the money each week, knowing that he would never be able to save any more than $10. Similarly, the Bc of bits, or the tokens in the bucket if you prefer, are only usable in that individual Tc interval, and the next Tc (interval) always starts with Bc tokens in the bucket, but never any more.

Traffic shaping implements Be by using a second bucket that can be used to accumulate any unused tokens from the first bucket. If in interval one, traffic shaping did not need all Bc worth of tokens in the first bucket, traffic shaping would move these tokens into the second bucket. So long as each successive interval does not use all Bc of the tokens in the first bucket, the second bucket would continue filling. Of course, the second bucket has a finite size as well, set at Be bits or tokens. If traffic shaping doesn’t need Bc bits (tokens) in each interval, the second bucket will fill, with any additional extra tokens wasted—in other words, you can only save up Be worth of “extra” tokens, because your second bucket is a set size.

So, the dual token bucket is similar to having two piggybanks—any saved money from each week is dumped from the first piggybank into the second piggybank, and the first piggybank is refilled with $10 each week. Continuing the analogy, the Mom and Dad in our scenario would also monitor the second piggybank so that it does not get too full.

Traffic shaping uses the Be so that more than Bc can be sent after a period of low activity. Traffic shaping can spend the tokens in the first bucket, and try to take the next packet, finding it does

Traffic-Policing and Traffic-Shaping Concepts 337

Traffic-Shaping Adaption

The rate at which the shaping function shapes traffic can vary over time. The adaption or adaptation process causes the shaper to recognize congestion and reduce the shaping rate temporarily, to help reduce congestion. Similarly, adaption notices when the congestion abates and returns the shaping rate to the original rate.

Two features define how adaption works. First, the shaper must somehow notice when congestion occurs, and when it does not occur. Second, the shaper must adjust its rate downward and upward as the congestion occurs and abates.

Figure 5-9 represents three different ways in which the main router can notice congestion. Three separate lines represent three separate frames sent to the main router, signifying congestion. Two of the frames are data frames with the Frame Relay backward explicit congestion notification (BECN) bit set. This bit can be set inside any Frame Relay frame header, signifying whether congestion has occurred in the direction opposite to the direction of the frame with the bit set. The third (bottom) message is a Foresight message. Stratacom, and later Cisco after they acquired Stratacom, defined Foresight as a signaling protocol in Frame Relay and ATM networks, used to signal information about the network, such as congestion information. If the Frame Relay network consists of Cisco/Stratacom WAN switches, the switch can send Foresight messages, and Cisco routers can react to those messages. Following the figure, each of the three variations for the Main router to recognize that congestion is occurring is explained in detail.

Figure 5-9 FECN, BECN, and Foresight Feedback

All VCs 64 kbps CIR

R1

Frame with BECN Set

Main

R24

First consider the BECN frame. Backward means that the congestion exists in the opposite, or backward, direction, as compared with the direction of the frame. Therefore, if FRS1 notices congestion trying to send frames to R1 (right to left in the figure), on the next frame sent by R1 (left to right in the figure), FRS1 can mark the BECN bit. In fact, any device can set the forward