Traffic-Policing and Traffic-Shaping Concepts 343

Finally, in this particular example, congestion can occur at the physical interface. The total of the two shaping rates listed in Figure 5-13 is 160 kbps, which exceeds the access rate. Because interface output queues can fill, it helps to apply a queuing tool to the interface output queues in this case.

How Policing Works

The internal processing logic used by IOS when implementing CAR differs slightly from the logic used when implementing class-based (CB) policing. Regardless of the internal processes, each policing tool wants to classify a packet relative to whether it is within the traffic contract. Based on that classification, the packet can be allowed to pass, be dropped, or be re-marked with a different IP precedence or IP DSCP (differentiated services code point) value.

Single and dual token-bucket models are used so that you fully appreciate the internal processing of the policers. Remember, the token-bucket mechanism is used to describe the concepts, but not necessarily to describe how the software is actually written. When no Be is configured, a single bucket is used, which represents Bc, and when Be is used, a second bucket is used, representing Be.

CAR internals are covered in the following sections, followed by CB policing concepts.

CAR Internals

Details aside, what CAR does is decide whether the packet conforms to or exceeds a traffic contract. CAR then takes action on the packet based on the configuration, which tells CAR whether to pass, discard, or re-mark conforming packets and exceeding packets. The actions themselves are simple and obvious; the hard part about CAR is understanding how CAR decides whether a packet conforms to the contract, or exceeds the contract.

CAR uses one or two token buckets to determine whether each packet conforms to or exceeds a traffic contract. CAR fills the buckets with tokens, with each token representing the right to send or receive 1 byte. When a packet is policed, CAR checks the buckets to decide whether enough tokens are in the right bucket to consider the packet as conforming. (The details of how CAR makes that decision are covered in the next few pages.) To understand CAR, you need to understand how CAR fills the buckets with tokens, and how CAR decides, based on the packet and the tokens in the buckets, whether the packet conforms or exceeds the traffic contract.

CAR and CB policing work slightly differently with and without a Be specified. The following sections explain how CAR works without Be, and how it works with Be.

CAR Without Be

Just like most descriptions of policing logic, this book uses token buckets to describe CAR logic. In this discussion, one bucket is called Bucket1, and the other is ingeniously called

344 Chapter 5: Traffic Policing and Shaping

Bucket2. Bucket1 begins with Bc worth of tokens in it, and Bucket2 begins with Be worth of tokens in it. Of course, only Bucket1 is used when Be = 0, but both Bucket1 and Bucket2 are used when Be is greater than 0. In some explanations found in other documents, you might hear Bucket1 referred to as the Bc bucket, or just as Bc. Because Bc is a static, configured value, and the number of tokens in the buckets change, however, I refer to the buckets as Bucket1 and Bucket2.

First, CAR fills Bucket1 with Bc tokens. Remember, each token represents a single byte, and Bc is configured in bytes. As time passes, CAR replenishes Bucket1 at regular intervals, using a Tc value calculated with the same formula used by shaping. The configuration sets the policing rate and the Bc value, with CAR calculating the Tc value based on the following familiar formula:

Bc

Tc = ---------------------------

Policed rate

CAR replenishes Bucket1 every Tc by adding Bc tokens to the bucket. Because Bucket1 has a maximum capacity of Bc tokens, and CAR replenishes Bc tokens every Tc, CAR effectively completely refills Bucket1 every Tc.

CAR categorizes each packet as “conforming” or “exceeding” the traffic contract as it arrives at the policer. CAR compares the number of bytes in the packet to the number of tokens in Bucket1. (Remember, Be = 0 for now, so the policer does not even think about Bucket2 in this case.) CAR’s decision is simple:

•If the number of bytes in the packet is less than or equal to (<=) the number of tokens in Bucket1, the packet conforms. CAR removes tokens from Bucket1 equal to the number of bytes in the packet, and performs the action for packets that conform to the contract.

•If the number of bytes in the packet is greater than (>) the number of tokens in Bucket1, the packet exceeds. CAR does not remove tokens from Bucket1, and performs the action for packets that exceed the contract.

So, without a Be configured, CAR logic is pretty easy. All the packets policed in a single Tc interval conform, so long as the packets cumulative number of bytes does not exceed Bc. If more than Bc bytes need to be sent, CAR decides those packets exceed the contract.

Car with Be

The previous discussion revolved around the simpler case, in which there was no Be. With a Be configured, CAR uses a slightly more complex algorithm to decide whether a packet conforms to or exceeds the traffic contract. This more complex algorithm has a simple goal—to soften the blow when the policer must discard packets. CAR’s algorithm recognizes when the extra bytes defined by Be are being consumed, and classifies some packets as “exceed,” and some packets

346 Chapter 5: Traffic Policing and Shaping

With Bc and Be configured, CAR uses dual token buckets, and the CAR algorithm gets more complicated. The algorithm is easy and familiar:

1If the number of bytes in the packet is less than or equal to (<=) the number of tokens in Bucket1, the packet conforms. CAR also removes tokens from Bucket1 equal to the number of bytes in the packet and performs the action for packets that conform to the contract.

2If the number of bytes in the packet is greater than (>) the number of tokens in Bucket1, CAR uses the debt calculations to determine whether the packet conforms or exceeds. CAR removes tokens from Bucket2 equal to the number of bytes in the packet if the packet conforms based on this rule.

As noted in part two of the algorithm, CAR uses the concept of debt. This means that if the packet size of a new packet is more than the number of tokens in Bucket1, CAR can borrow from Bucket2. CAR needs to replenish, or repay, those tokens after an interval when Bc is not completely used, as was described earlier.

The term “actual debt” (Da) defines the most obvious concept related to debt calculations. Imagine that Bucket1 has been depleted down to 0 tokens, and Bucket2 has 10,000 tokens in it. A new 1000-byte packet arrives that needs to be policed. CAR compares the packet length to Bucket1, and decides that Bucket1 does not have enough tokens. CAR then looks at Bucket2, which does have more tokens (10,000) than the packet size (1000). Therefore, CAR considers the packet as conforming, and it decrements Bucket2 to 9000. CAR also now considers Da to be 1000—the number of actual tokens “borrowed” from Be or Bucket2. Imagine 2 more 1000byte packets arrive before CAR replenishes tokens into Bucket1. These packets also conform, and CAR decrements Bucket2 down to 8000 tokens after the second packet, and then to 7000 tokens after the third packet. Similarly, Da is incremented to 2000, and then 3000.

Dc is the other key component of the CAR algorithm. The compounded debt (Dc) variable is also calculated by CAR as Be is being consumed. Each time Da is incremented, Dc is also incremented. Dc grows more quickly than Da, however, because the formula used to calculate Dc is Dc = old_Dc + new_Da. Table 5-6 lists the same three packets described in the explanation of Da, plus 2 more 1000-byte packets, with the computed Da and Dc values. In this case, Be is set to 8000 bytes. Keep in mind that the Dc calculation does not begin until Bc (Bucket1) has been consumed during a particular interval.

Table 5-6 Example Comparing Growth in Da and Dc with Five Consecutive 1000-Byte Packets

*Dc would have been 10,000, but because Be is 8000 in this example, the Dc value is reset to 0.