Whenever the physical clock rate exceeds the traffic contract, policing may be needed. Suppose, for instance, that ISP1 has 1000 customers, just like PB Tents, each with a 100-Mbps connection, and a contract for support of 2 Mbps. What happens over time? Well, without something to prevent it, each customer will send and receive more and more traffic. For a while, all the customers are happy, because their packets make it through the overbuilt ISP1 core. Even if ISP1 has enough capacity to support 10 Mbps of traffic from every customer, eventually, ISP1’s network will become overrun, because their customers keep sending more and more traffic, so eventually all traffic will suffer. Queues become congested frequently, causing dropped packets. Multimedia traffic suffers through the poor performance as a result of high delay and jitter. TCP sessions continually decrease their window sizes because of the lost packets, causing synchronization effects inside ISP1. ISP1 can add capacity, but that probably means that ISP1 should start charging more to their customers, who may not be willing to upgrade to a higher-traffic contract.

In actual ISP networks, the network engineers design the core of the network expecting some degree of oversubscription. The term “oversubscription” means that the customer has sent and received more traffic than was contracted, or subscribed. As in the example of ISP1 in the preceding paragraph, ISPs and Frame Relay providers build their network expecting some oversubscription. However, they may not build the core expecting every customer to send traffic at full access rate, all the time.

Policing protects a network from being overrun by traffic. If ISP1 just policed traffic from each customer, discarding packets that exceed the traffic contract, it would protect itself from being overrun. However, the decision to add policing to a network can be politically difficult. Suppose that ISP1 has these 1000 customers, each of whom contracted for 2 Mbps of traffic. Each customer sends and receives more, averaging 10 Mbps, so that ISP1’s network is becoming too congested. ISP1 chooses to implement policing, using the contracted rate, discarding packets that exceed 2 Mbps of traffic. Of course, most of their customers will be very unhappy! Such a move may be a career-ending, if not business-ending, choice.

Policers can also just mark down the traffic, instead of discarding it. To do so, the policer marks the packet with a different IP precedence or DSCP value when the traffic rate is exceeded, but it still lets the packet through. Later QoS functions, including policers and packet-drop tools such as Weighted Random Early Detection (WRED), can more aggressively discard marked-down packets as compared with those that have not been marked down. Essentially, the policer can increase the chance that a packet will get discarded somewhere else in the network if that packet causes the traffic rate to be exceeded. Generally speaking, when policers mark down packets, if the network is not currently congested, the packet can get through the network; if congested, the packet is much more likely to be discarded.

ISPs make the business choice of whether to police, and how aggressively to police. The options reduce to the following three basic options:

Policing can be useful in multiaccess WANs (Frame Relay and ATM networks) for the same reason that it was useful for the ISP connection described earlier. Whenever data can be sent faster than the contracted rate, the danger exists that a network will be overrun when many sites exceed their contract at the same time. An example will help you understand a few of the issues. Figure 6-2, the network diagram for PB Tents network, has been expanded to show 12 branches, with a single central site.

Figure 6-2 PB Tents Network, 12 Frame Relay Branches, 1 Central Site

Each branch can send traffic at 128 kbps, but each branch only has a contracted 64-kbps CIR on their respective VCs to the main site. If all 12 sites conform to their CIRs, the Frame Relay network should be able to handle the load. If all 12 sites offer 128 kbps of traffic for long periods, however, the provider may still go ahead and try to forward all the traffic, because most Frame Relay providers overbuild their core networks. They also like to imply in their sales pitch that the customer gets to send excess packets for free.

Of course, at some point, if every customer of this provider sent traffic at full line rates for a period of time, the network would probably congest. The same options exist for the Frame Relay network as for an ISP — not to police but build more capacity; police to CIR, and deal with the sales and customer satisfaction issues; or police at something over CIR, and deal with the sales and customer satisfaction issues in slightly different ways.

To police the network in Figure 6-2, the Frame Relay switches can be configured to perform the policing, or the routers can be used. Traditionally, policing is performed as packets enter a network, which would suggest policing as packets enter the Frame Relay switches from the customer. If the service provider actually controls the edge routers in the enterprise network, however, the policing feature can be performed as packets exit the routers, going toward the Frame Relay cloud. If the customer controls the routers at the edge of the cloud, policing in these routers may be risky for the service provider, just because of the possibility that some customers might turn off policing to get more capacity for free.

The Cisco QoS exam covers policing in IOS routers using CB Policing. The exam does not cover policing in Frame Relay switches, or in LAN switches, although the basic concepts are the same.

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.

Two main actions revolve around the token bucket and the tokens:

For filling the token bucket, the bucket is filled to its maximum capacity, but no more, at the beginning of each Tc (assuming that Be = 0 for the time being). Another way you can think of it as if the Shaper dumps Bc worth of tokens into the bucket at the beginning of every interval; however, if there’s not enough room in the bucket, because not all the tokens were used during the previous time interval, some tokens spill out. Those spilled tokens can’t be used. The net result, either way you look at it, is that the interval starts with a full token bucket of size Bc. Figure 6-8 shows the basic idea:

Figure 6-8 Mechanics of Filling the Shaping Token Bucket

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 making the bucket bigger. In fact, to support an excess burst, the bucket now contains Bc plus Be worth of tokens. The filling of tokens into the bucket at the beginning of each interval, and the draining of tokens to gain the right to send packets, remains the same. For instance, at the beginning of each interval, the Shaper still tries to fill the bucket with Bc tokens. If some spill out, because there’s no more room for more tokens in the bucket, those tokens are wasted.

The key advantage gained by having Be—in other words, having a token bucket of size Bc plus Be—is that the token bucket is larger. As a result, after some time during which the actual bit rate is lower than the shaping rate, the token bucket fills with tokens. If in the next interval more than Bc bits needed to be sent, the Shaper could send them—up to the number of tokens in the bucket, namely Bc + Be. Basically, the Shaper allows the amount of data passed by the shaper to burst.

Figure 6-9 shows a graph of how shaping works when using Be. The shaper represented by the graph shapes to a CIR of 64 kbps, over a 128-kbps link. The Bc has been set to 8000 bits, with an additional 8000 bits for Be.

Figure 6-9 Bc and Be, After a Period of Inactivity

The example in Figure 6-9 assumes that enough inactive or slow periods have occurred, just prior to this example, so that the token bucket is full. In other words, the token bucket holds Bc + Be tokens, which is 16,000 tokens in this example. A large amount of traffic shows up, so traffic shaping sends as fast as it can until it runs out of tokens.

In the first interval, traffic shaping can send a total of 16,000 bits. On a 128-kbps link, assuming a 125-ms Tc, all 125 ms are required to send 16,000 bits! Effectively, in this particular case, after a period of inactivity, R1 sends continuously for the entire first interval.

To begin the second interval, Shaping adds Bc (8000) tokens to the bucket. Those tokens do not fill the bucket, but it does allow the shaper to pass 8000 bits, which requires half the time interval. So, in this example, the shaper will send for 187.5 ms (the entirety of the first 125 ms interval, plus half of the second interval) until traffic shaping artificially slows down the traffic. Thus, the goal of allowing a burst of data traffic to get started quickly is accomplished with Be.

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 6-10 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 6-10 FECN, BECN, and Foresight Feedback

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 explicit congestion notification (FECN) and BECN bits—however, in some networks, the Frame Relay switches do set the bits, and in some, they do not.

If the BECN bit is set, the Main router, if using adaptive shaping, reduces its shaping rate on the VC to R1. Because the congestion occurs right to left, as signaled by a BECN flowing left to right, router Main knows it can slow down and help reduce the congestion. If Main receives another frame with BECN set, Main slows down more. Eventually, Main slows down the shaping rate until it reaches a minimum rate, sometimes called the minimum information rate (MIR), and other times called the mincir.

Similarly, if Main receives a Frame from R12 with FECN set, the congestion is occurring left to right. It does not help for Main to slow down, but it does help for R12 to slow down. Therefore, the Main router can “reflect” the FECN, by marking the BECN bit in the next frame it sends on the VC to R12. R12, receiving a BECN, can reduce the shaping rate.

Finally, Foresight messages are separate, nondata signaling frames. Therefore, when the congestion occurs, Foresight does not need to wait on a data frame to signal congestion. In addition, Foresight sends messages toward the device that needs to slow down. For instance, a switch notices congestion right to left on the VC between Main and R24. The switch generates and sends a Foresight message to Main, using that same VC, so Main knows it needs to slow down its shaping rate on that VC temporarily. When configuring adaptive shaping, you configure the minimum and maximum shaping rate. With no congestion, CB Shaping uses the maximum rate. When the Shaper receives a BECN or Foresight message, it slows down by 25 percent of the maximum rate. In order to slow down, CB Shaping actually simply decreases Bc and Be by 25%, keeping the Tc value the same. In other words, CB Shaping allows fewer bits to pass in each time interval. If the Shaper continues to receive BECNs, the Shaper continues to slow down by 25 percent of the maximum rate per Tc , until the minimum rate is reached.

The rate grows again after 16 consecutive intervals occur without a BECN or Foresight congestion message. The shaping rate grows by 1/16 of the maximum rate during each Tc, until the maximum rate is reached again. To do that, the formerly-reduced Bc and Be values are increased by 1/16 oftheir configured values each Tc. Because of that, the formula for calculating how much CB Shaping increases the rate per time interval as actually showing the increase in BC and Be values. The formula for the amount of increase per interval is:

Shaping can be applied to the physical interface, a subinterface, or in some cases, to an individual VC. Depending on the choice, the configuration causes traffic shaping to occur separately for each VC, or it shapes several VCs together. In most cases, engineers want to shape each VC individually.

When shaping is applied to an interface for which VCs do not exist, shaping is applied to the main interface, because there are no subinterfaces or VCs on those interfaces. On Frame Relay and ATM interfaces, however, some sites have multiple VCs terminating in them, which means that subinterfaces will most likely be used. In some cases, more than one VC is associated with a single multipoint subinterface; in other cases, point-to-point subinterfaces are used, with a single VC associated with the subinterface. The question becomes this: To shape per VC, where do you enable traffic shaping?

First, consider a typical branch office, such as R24 in Figure 6-11. R24 has a single VC to the Main site at PB Tents. Because R24 only has the single VC, the configuration on R24 may not even use subinterfaces at all. If the configuration does not use subinterfaces on R24’s serial link, traffic shaping can be configured on the physical interface. If the configuration includes a subinterface, you can enable traffic shaping on the physical interface, or on the subinterface. Because there is only one VC, it does not really matter whether shaping is enabled on the physical interface, or the subinterface—the behavior is the same.

Figure 6-11 PB Tents Network: Shaping on Subinterfaces and VCs

Now consider the Main router. It has a VC to each remote site. (Also notice that a VC has been added between R1 and R2, just to make things interesting.) So, on the main router, point-to-point subinterfaces are used for the VCs to branches 3 through 24, and a multipoint subinterface is used for the two VCs to R1 and R2. To shape each VC to branches 3 through 24 separately, shaping can be configured on the subinterface. However, shaping applied to a multipoint subinterface shapes all the traffic on all VCs associated with the subinterface. To perform shaping on each VC, you need to enable shaping on each individual data-link connection identifier (DLCI).

As it turns out, CB Shaping can be applied per subinterface, but not per-VC on multipoint subinterfaces. In the example in Figure 6-11, CB Shaping could shape all traffic from router Main to both R1 and R2, but it could not shape traffic to R1 separately from the traffic going to R2.

In summary, most QoS policies call for shaping on each VC. The configuration commands used to enable shaping differ slightly based on the number of VCs, and how they are configured. Table 6-4 summarizes the options.

Table 6-4 Options of How to Enable Shaping for per-VC Shaping

Shaping tools support a variety of queuing tools that can be applied to the packets waiting in the shaping queue(s). At the same time, IOS supports queuing tools for the interface software queue(s) associated with the physical interface. Deciding when to use queuing tools on shaping queues, when to use them on the interface software queues, and how the configurations differ in each case, can be a little confusing. This section attempts to clear up some of that confusion.

To begin, Table 6-5 lists the traffic-shaping tools, and the queuing tools supported by each for the shaping queues.

Table 6-5 Options for Queuing in Traffic-Shaping Tools

When a Shaper uses a queuing tool, instead of creating a single FIFO shaping queue, it creates multiple shaping queues based on the Queuing tool. For instance, if FRTS were configured to use Priority Queuing (PQ) for the shaping queues, it would create four queues for shaping, named High, Medium, Normal, and Low. Figure 6-12 shows the basic idea, with shaping enabled on the physical interface, FIFO Queuing on the physical interface, and PQ configured for shaping the only VC.

Figure 6-12 FRTS, with FIFO Queuing for the Physical Interface, Plus PQ for the Shaping Queue

The shaping queues exist separately from the interface software queues, as seen in Figure 6-12. With PQ applied to the Shaper, four shaping queues exist for this VC. When the Shaper decides to allow another packet to be sent, it takes the next packet from the PQ shaping queues, according to PQ scheduler logic. Those packets are placed into software queues associated with the physical interface and then forwarded out the interface—in this case shown as a single FIFO queue.

In some cases, the shaping queues are bypassed, and in other cases, the interface software queues are bypassed. To understand why, consider Figure 6-13, which demonstrates part of the logic behind the decision for determining when each queue should be used.

Figure 6-13 Decision Logic for Queuing with Shaping Enabled

Packets are held in a shaping queue or interface output queue only if there is some reason why the packet must wait to take the next step. For instance, you already know that if the Hardware Queue is not full, packets are immediately placed into the Hardware Queue, bypassing the interface Software Queue. Likewise, if shaping decides that a packet does not need to be delayed, because the shaping rate has not been exceeded, it can go directly to the interface output queue, or even to the Hardware Queue.

Many QoS designs call for shaping per VC, as mentioned in the preceding section. Suppose that a router has two 64-kbps CIR VCs sharing an access link, each configured on a separate point-to-point subinterface. Shaping queues will be created for each VC. A single set of interface output queues will be created, too. Figure 6-14 depicts the overall idea.

Figure 6-14 Fancy Queuing for the Physical Interface and for Two Sets of Shaping Queues

The shaping tool creates a set of queues for each subinterface or VC, based on the queuing tool configured for use by the shaper. IOS creates only one set of interface software queues for the physical interface, based on the queuing configuration on the physical interface, as covered in Chapter 5, “Congestion Management.” In Figure 6-14, two sets of shaping queues have been created, one per VC. Both VCs feed the single set of interface output queues.

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

When using token buckets for policing, two important things happen. First, tokens are replenished into the bucket. Later, when the policer wants to decide if a packet conforms to the contract or not, the policer will look into the bucket, and try to get enough tokens to allow the packet through. If there’s enough, the policer will “spend” the tokens, removing them from the bucket, in order to have the right to allow the packet past the policer.

With Policing, think of each token as the right to send a single byte; with Shaping, each token represented a bit. First, consider how CB Policing fills the single token bucket. Unlike CB Shaping, CB policing replenishes tokens in the bucket in response to a packet arriving at the policing function, as opposed to using a regular time interval (Tc). Every time a packet is policed, CB policing puts some tokens back into the Bucket. The number of tokens placed into the Bucket is calculated as follows:

Note that the arrival times’ units are in seconds, and the police rate is in bits per second, with the result being a number of tokens. Each token represents the right to send 1 byte, so the formula includes the division by 8 in order to convert the units to bytes instead of bits.

The idea behind the formula is simple — essentially, a small number of tokens are replenished before each packet is policed, with an end result of having tokens replenished at the policing rate. Suppose, for instance, that the police rate is 128,000 bps (which happens to equal 16,000 bytes per second.) If 1 second has elapsed since the previous packet arrived, CB Policing would replenish the bucket with 16,000 tokens. If 0.1 seconds had passed since the previous packet had arrived, CB Policing would replenish the bucket with 0.1 seconds worth of tokens, or 1600 tokens. If .01 seconds had passed, CB Policing would replenish 160 tokens at that time. Essentially, the Bucket is replenished with a prorated number of tokens based on how long ago it was last replenished.

The second part of using a bucket relates to the policer’s choice as to whether a packet conforms to the contract or not. CB Policing compares the number of bytes in the packet to the number of tokens the token bucket. CB policing’s decision is simple, as noted here:

Therefore, the logic used by a single-rate, two-color policer is simple. The bucket gets replenished with tokens based on packet arrival time. If the packet conforms, CB Policing either forwards, discards, or re-marks the packet, and some tokens are then removed from the bucket. If the packet exceeds, CB Policing either forwards, discards, or re-marks the packet, but no tokens are removed from the bucket. (Note that discarding packets that conform is a valid configuration option, but it is not particularly useful.)

When you want the policer to support both a committed burst (Bc) and an excess burst (Be), the policer uses two token buckets. By using two token Buckets, CB Policing can categorize packets into three groups:

The intent of these three categories is to allow the policer to decide if packets totally conform, whether they are using the excess burst capability (exceed), or whether the packet puts the data beyond even the excess burst (violate).

Just like with a single token bucket, to understand how CB Policing works with two buckets is to understand how the buckets are filled and drained. CB Policing continues to replenish the Bc bucket when a packet arrives. However, any spilled tokens when filling the Bc bucket are not simply wasted. If the Bc bucket is full, the extra, or spilled tokens, replenish the Be bucket. If the Be bucket fills, the excess tokens spill out and are wasted. Figure 6-15 shows the basic process:

Figure 6-15 Refilling Dual Token Buckets with CB Policing

With Bc and Be configured, CB policing uses dual token buckets, and the algorithm is simple:

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

2.   If the packet does not conform, and the number of bytes in the packet is less than or equal to (<=) the number of tokens in the Be Bucket, the packet exceeds. CB policing removes tokens from the Be Bucket equal to the number of bytes in the packet, and performs the action for packets that exceed the contract.

3.   If the packet neither conforms nor exceeds, it violates the traffic contract. CB policing does not remove tokens from either bucket, and performs the action for packets that violate the contract.

Essentially, packets that fit within Bc conform, those that require the extra bytes allowed by Be exceed, and those that go beyond even Be are considered to violate the traffic contract.

Dual Token Bucket CB Policing with a single rate provides a very useful function. After a period of low activity, a larger burst of data can be considered to either conform to or exceed the traffic contract, without violating the traffic contract. Because data tends to be bursty, the idea of a policer with bursting capability makes a lot of sense.

Dual Token Bucket with Dual-rate policing also provides a bursting feature, but with dual-rate, the CB Policer allows you to essentially set two different sustained rates. Packets that fall under the lower rate—the Committed Information Rate (CIR)—conform to the traffic contract. A second sustained rate—the Peak Information Rate (PIR)—defines a traffic rate above CIR. Packets that happen to exceed the CIR, but fall below PIR, are considered to exceed the contract, but not to violate it. Finally, packets beyond even the PIR are considered to violate the contract.

As usual, the mechanics of how it all works behind the scenes relates to how the policer replenishes tokens into the buckets, and how the policer then takes tokens from the buckets during the process of deciding if a packet conforms, exceeds, or violates the traffic contract. First, consider Figure 6-16, which shows the refill process works for the two buckets. In this case, the buckets are referred to as the CIR bucket and the PIR bucket, respectively.

Figure 6-16 Refilling CIR and PIR Dual Token Buckets with CB Policing

A couple of differences exist between the token refilling process of the single rate, three-color policing of the previous section. First, note that both buckets are filled upon the arrival of a packet that needs to be policed. However, the PIR bucket is refilled with tokens directly, instead of having to rely on spillage from the refilling of the CIR bucket. Essentially, this means that the PIR bucket does not have to rely on a period of low or no activity in order to get more tokens. Also note that when refilling, any tokens that spill from either bucket are wasted.

The refilling of the two buckets based on two different rates is very important. For example, imagine you set a CIR of 128 kbps (16 kilobytes/second), and a PIR of 256 kbps (32 kilobytes/second). If .1 seconds passed before the next packet arrived, then the CIR bucket would be replenished with 1.6 kilobytes of tokens (1/10 of 1 seconds worth of tokens, in bytes), while the PIR bucket would be replenished with 3.2 kilobytes of tokens. So, there are more tokens to use in the PIR bucket, as compared to the CIR bucket.

As usual, the second part of the process involves how the policer thinks about the tokens in the buckets in order to decide if the packet conforms, exceeds, or violates the traffic contract. The logic is similar to the single rate, two bucket policing described earlier, but with a twist for what happens for conforming packets:

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

2.   If the packet does not conform, and the number of bytes in the packet is less than or equal to (<=) the number of tokens in the PIR bucket, the packet exceeds. CB Policing removes tokens from the PIR bucket equal to the number of bytes in the packet, and performs the action for packets that exceed the contract.

3.   If the packet neither conforms nor exceeds, it violates the traffic contract. CB Policing does not remove tokens from either bucket, and performs the action for packets that violate the contract.

Even before you read this list, you probably guessed the base logic. If there are enough tokens in the CIR bucket, the packet conforms; if not, and there’s enough in the PIR bucket, it exceeds; if not, the packet violates the contract. The new part revolves around the fact that even if the packet conforms, the policer takes tokens from the PIR bucket.

An example can help. Imagine that CB Policing has been configured for the following:

Effectively, PIR and Be are double the values of CIR and Bc. Now imagine that both buckets are full of tokens, and a bunch of packets arrive at the same instant. Because they arrive at the same instant, the replenishment of tokens into the buckets is either 0, or negligible—so for the sake of discussion, assume no new tokens are added to either bucket during this example.

The first 8000 bytes worth of packets pass through the policer, with the packets considered to conform. The CIR bucket is decremented to 0. At the same time, the PIR bucket is also decremented, from 16,000 to 8,000 tokens.

For the next 8000 bytes of packets, the policer decides that the packets exceed the contract, and the policer removes tokens from the PIR bucket. Finally, after the rest of the packets are considered to violate the traffic contract, at least until some time passes, allowing more tokens to be added to the two buckets.

Shapers queue excess packets, and policers discard excess packets. However, policers allow a sort of compromise, where the packets are not discarded, but they are marked so that if congestion occurs later, this particular packet is more likely to be discarded. Consider Figure 6-17, for instance, and the policing function on R1.

Figure 6-17 Marking Down Packets with Policing

In the figure, two packets travel over a route marked with dotted lines. Each is marked with DSCP AF11 as they enter R1. R1’s policer decides that Packet1 conforms, but that Packet2 exceeds the policing rate. R1’s policer re-marks Packet2 as AF13. DiffServ suggests that AF13 should be in the same queuing class as AF11, but with a higher drop preference than AF11. If no congestion occurs, both packets get through the network. If some congestion occurs, however, Packet2 has a higher chance of being discarded, because it has a DSCP that implies a higher preference to be dropped than does Packet1.

Policing by marking down the packet provides a compromise option. The ISP can protect the network from being overrun by aggressively discarding marked-down packets at the onset of congestion. Customer satisfaction can be improved by letting the customers take advantage of the capacity when it is available.

The same concept, on a limited basis, can be applied in Frame Relay and ATM networks. Frame Relay headers include the discard eligibility (DE) bit, and ATM headers include the cell loss priority (CLP) bit. Each of these single bits can be used to imply that the frame or cell is a better frame or cell to discard when congestion occurs.

Finally, when choosing to re-mark a packet, you might actually want to mark multiple fields. For instance, you might want to mark down a packet from AF11 to AF13, inside the DSCP field of the IP header. You might also want to mark ATM CLP, or 802.1p CoS as well. When a policer is configured to mark multiple fields for packets that fall into a single policing category, the policer is said to be a multi-action policer.

In all the examples of CB Shaping so far, the command that enabled shaping always began with the words shape average. However, there is another option instead of “average”, as seen in the generic form of the following command:

When you use the peak option, CB Shaping changes how it decides if a packet conforms to or exceeds the traffic contract. As a reminder, using the Shaping logic covered so far in this chapter, Bc bits are sent each Tc. If there’s been a period of low or no activity, and the Shaper has been configured with a Be value, then for a short time, more than Bc can be sent—specifically, Be more. With shape peak, the shaper allows Bc and Be bits to be sent in each interval, even if there has not been a period of little or no activity. In effect, shape peak means that the shaper actually shapes assuming you can send the configured burst during every time period.

Frankly, most people find how it works a little odd, so an example comparing shape average with shape peak, using the same settings, can help. First, consider shaping configured with the following command:

As covered earlier in this section, CB Shaping assumes a Bc of 8000, a Be of the same value, and then calculates Tc of .125 seconds. (Those numbers can be seen in Example 6-3.) The token bucket will be size Bc + Be, or 16,000 bits. After a period of inactivity, 16,000 bits can be sent. Under consistently high offered load, 8,000 bits can be sent each Tc, because the token bucket is filled at Bc bits (8000 bits) per interval.

Compare that to the following command to the shape average command:

Just as with shape average, CB Shaping assumes a Bc of 8000, a Be of the same value, and then calculates Tc of .125 seconds. And just as with shape average, the token bucket will be size Bc + Be, or 16,000 bits. However, instead of replenishing the token bucket with Bc bits each Tc, shape peak tells CB Shaping to replenish Bc + Be tokens per Tc. Translated, that means that the shaper gets the right to send the committed burst, and the excess burst, every time period.

Interestingly, the shape peak 64000 command actually shapes packets at a rate higher than 64 kbps. To calculate the actual rate, you would use the following formula:

For instance, in this example, the actual shaping rate would be 128 kbps:

Example 6-4 lists an example configuration using shape peak, along with a few comments confirming the math behind the use of this command.

Example 6-4 CB Shaping on R3, 96-kbps Shape Rate, with LLQ for Shaping Queues

To interpret the example, first remember that Bc defaults to 8000 bits at speeds lower than 320 kbps, and that Be = Bc by default. The show policy-map interface s0/0 command lists the target rate as 128,000 bits/second, as confirmed with the math that precedes the example. Also, the column labeled Increment (bytes) refers to the number of bytes worth of tokens added back to the token bucket in each interval. To support the peak rate, instead of just adding Bc worth of tokens (1000 bytes), Bc + Be (2000 bytes) worth of tokens are added.

This chapter covered the concepts behind adaptive shaping a little earlier. To configure adaptive shaping with CB Shaping, you need to use the shape command twice inside a single policy-map. Example 6-5 shows an example:

As you can see in the example, the shape average command is configured, along with the shape adaptive command, inside the same policy map class (class-default). The shape average command enables shaping; with that command alone, CB Shaping shapes at 96 kbps all the time. With shape adaptive 32000 configured in the same class, CB Shaping will reduce the shaping rate in reaction to received BECNs, all the way down to 32 kbps. The rate is reduced by 25 percent of the previous actual shaping rate for each BECN received. But the shaping rate will never fall below 32 kbps—so you can think of that rate as the minimum rate, and the 96-kbps rate as the maximum rate.

As a reminder, after 16 consecutive intervals with no received BECNs, this router would start increasing the Shaping rate by 1/16 of the original 96-kbps shaping rate each Tc. To do so, CB Shaping actually starts replenishing the token bucket with a little more each Tc, specifically by (Bc + Be)/16 each Tc. As a result, the rate will likely increase a little more slowly than it decreased in the presence of BECNs.

The shape command also allows you to configure the shaping rate based on a percentage of link bandwidth, if you prefer. That’s true whether or not you are configuring CB shaping with the shape average or shape peak commands. For instance, if you had a Frame Relay interface whose access rate (the physical clock rate) was 128 kbps, but you wanted to configure shaping for 64 kbps, you could use the shape average percent 50 command.

Be aware that the calculation of the actual shaping rate, when enabled on a physical interface, is based on the interface’s configured bandwidth. For instance, in this same example, the default setting of the interface’s bandwidth command is 1544, meaning T/1 speed. The shaping rate would then be calculated as 50 percent of that, or 772 kbps.

Note also that with the percent option, Bc and Be are configured with units of milliseconds. Interestingly, configuring Bc with the percent option actually sets Tc, with CB Shaping calculating Bc based on the Bc = Tc * CIR formula. Example 6-6 shows an example configuration, along with the calculated Bc and Be values.

Example 6-6 Shaping Based on Percent