Foundation Summary

The "Foundation Summary" is a collection of tables and figures that provide a convenient review of many key concepts in this chapter. For those of you already comfortable with the topics in this chapter, this summary could help you recall a few details. For those of you who just read this chapter, this review should help solidify some key facts. For any of you doing your final prep before the exam, these tables and figures are a convenient way to review the day before the exam.

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

• Do not police. To support the traffic, build the network to support the traffic as if all customers will send and receive data at the clock rate of the access link. From a sales perspective, close deals by claiming that no policing will be done, but encourage customers who exceed their contracts to pay for more bandwidth.

• Police at the contracted rate. To support these traffic levels, the network only needs to be built to support the collective contracted rates, although the core would be overbuilt to support new customers. From a sales perspective, encourage customers that are beginning to exceed their contracts to upgrade, and give incentives.

• Police somewhere in between the contracted rate and the access-link clock rate. For instance, ISP1 might police PB Tents at 5 Mbps, when the contract reads 2 Mbps. The network can be built to support the collective policed rates. The sales team can encourage customers to buy a larger contracted rate when they consistently exceed the contracted rate, but keep customer satisfaction higher by pointing out their generosity by only policing at rates much higher than the contracted rates.

Figure 6-21 points out two cases of egress blocking, using a Frame Relay network as an example.

Table 6-14 summarizes some of the key points about when and where you should consider using policing and shaping.

Table 6-14. Policing and Shaping: When to Use Them, and Where

Topic	Rationale
Why police?	If a neighboring network can send more traffic than the traffic contract specifies, policing can be used to enforce the contract, protecting the network from being overrun with too much traffic.
Where to police?	Typically, policing is performed as packets enter the first device in a network. Egress policing is also supported, although it is less typical.
Why shape?	The first of two reasons for shaping is when the neighboring network is policing. Instead of waiting for the neighboring policer to discard traffic, a shaper can instead delay traffic so that it will not be dropped. The second reason has to do with the effects of egress blocking. By shaping, egress blocking can be avoided, or minimized, essentially moving the queues from inside the service provider cloud, and back into the enterprise routers. By doing so, the router queuing tools can selectively give better QoS performance to particular types of traffic.
Where to shape?	Shaping is always an egress function. Typically, shaping is performed on packets exiting a router, going into another network. This may be the edge between a router and a multiaccess WAN, or possibly just a link to an ISP.

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. Table 6-15 lists some related definitions.

Table 6-15. Shaping Terminology

Term	Definition
Tc	Time interval, measured in milliseconds, over which the committed burst (Bc) can be sent. With many shaping tools, Tc = Bc/CIR.
Bc	Committed burst size, measured in bits. This is the amount of traffic that can be sent over the interval Tc. Typically also defined in the traffic contract.
CIR	Committed information rate, in bits per second, defines the rate defined in the traffic contract.
Shaped Rate	The rate, in bits per second, to which a particular configuration wants to shape the traffic. In some cases, the shaped rate is set to the same value as CIR; in others, the shaped rate is set to a larger value, with the hope of sending more traffic through the network.
Be	Excess burst size, in bits. This is the number of bits beyond Bc that can be sent after a period of inactivity.

Traffic Shaping uses a token bucket to control the mechanics of deciding which packets conform to the shaping rate, and which exceed the rate. Two main actions revolve around the token bucket and the tokens:

• The re-filling of the bucket with new tokens

• The consumption of tokens by the Shaper to gain the right to forward packets.

For filling the token bucket, the bucket is filled to the brim, 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 intervalbut if there's not enough room in the bucket, because not all the tokens were used during the previous time interval, some tokens spill outand 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-22 shows the basic idea:

With Be configured, the size of the single token bucket used by shaping is Bc + Be, but the tokens are still only refilled with Bc every time interval. This effectively lets the shaper save extra tokens after a period of inactivity in order to burst longer. Figure 6-23 lists the overall process used by shaping, with both a Bc and Be value configured.

The formulas IOS uses to calculate Tc when you configure both the shaping rate and the Bc are as follows:

Or

CB Shaping calculates a value for Bc and Be if the shape command does not include a value. From that, it calculates the Tc. At lower shaping rate (less than 320Kbs), CB Shaping assumes a Bc of 8000 bits, and calculates Tc based on the formula Tc = Bc/CIR, with some rounding as necessary. Note that at 320 kbps, the calculated Tc would be 25 ms, or .025 seconds.

For speeds higher than 320 kbps, CB Shaping instead uses a default Tc of .025 seconds (250 ms), and calculates Bc based on the same formula, which with a little easy algebra translates to Bc = Tc * CIR. For instance, at 640 kbps, Bc = .025 * 640 kbps = 16,000 bits.

CB Shaping defaults Be to be equal to Bc.

CB Shaping can adapt its shaping rate based on the receipt of BECNs or Foresight messages. When the shaper receives a BECN or Foresight message, it slows down by 25 percent of the maximum rate, repeating the process for each received BECN or Foresight message, 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. This process results in an increase in the shaping rate based on the following formula: (Bc + Be)/16.

When a shaper uses a queuing tool, instead of having a single shaping queue, multiple shaping queues exist. If FRTS were configured to use PQ, for example, up to four queues could be created for shaping. Figure 6-24 shows the basic idea, with shaping enabled on the physical interface, FIFO Queuing on the physical interface, and PQ configured for the shaping queue.

Many QoS designs call for shaping per VC. For the same router, with two 64-kbps CIR VCs (each configured on a separate point-to-point subinterface) shaping queues are created for each subinterface, with the familiar output queues as well. Figure 6-25 depicts the overall idea.

The CB Shaping shape command has an option for peak-rate shaping. For instance, 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, the actual shaping rate would be 128 kbps, assuming the default value 8000 for both Bc and Be:

Table 6-16 summarizes the key points for comparison between the CB Shaping and FRTS, with a few words of explanation following.

Table 6-16. Comparison of CB Shaping and FRTS Features

Feature	CB Shaping	FRTS
Supports ATM, FR, HDLC, PPP, LAN interfaces	Yes	No
Can be enabled on interfaces and subinterfaces	Yes	Yes
Can be enabled per Frame Relay DLCI to support per-VC shaping on multipoint interfaces	No	Yes
Supports adaptive shaping	Yes	Yes
Supports concurrent FRF.12 Frame Relay fragmentation	No	Yes
Supports MLP over Frame and ATM Fragmentation	Yes	Yes
Queuing methods in shaping queue	FIFO, WFQ, CBWFQ, LLQ	FIFO, WFQ, CBWFQ, LLQ, PQ, CQ
Concurrent queuing methods on Physical interface	All	FIFO, FRF[*]
Can be configured using MQC commands	Yes	No
Can classify traffic to shape a subset of the traffic on an interface/VC	Yes	No
Default Tc	Variable	125 ms

^[*] The Cisco QoS course claims WFQ is supported on the physical interface. In addition, FRF is not technically a queuing tool, although its feature of using two queues does achieve the same effect.

CB Policing includes a lot of small details about how it chooses which packets conform to, exceed, or violate a traffic contract. To help with exam prep, Table 6-17 lists the key points about how CB Policing uses token buckets.

Table 6-17. Summary of CB Policing Mechanics

Feature	Behavior of Single-Rate, Two-Color	Behavior of Single-Rate, Three-Color	Behavior of Dual-Rate, Three-Color
Size of "first" bucket	Bc (bytes)	Bc (bytes)	Bc (bytes)
Size of "second" bucket	N/A	Be (bytes)	Be (bytes)
Refill of first bucket	Prorated portion of Bc based on packet arrival time	Prorated portion of Bc based on packet arrival time	Prorated portion of Bc based on packet arrival time
Refill of second bucket	N/A	Filled by spilled Tokens from refill of first bucket	Prorated portion of Be based on packet arrival time
Logic for "conform" action	1st bucket => packet size decrement 1st bucket by packet size	1st bucket => packet size; decrement 1st bucket by packet size	1st bucket => packet size; decrement 1st bucket by packet size
Logic to choose "exceed" action	All packets that do not conform	Doesn't conform, but 2nd bucket => packet size decrement 2nd bucket by packet size	Doesn't conform, but 2nd bucket => packet size; decrement BOTH buckets by packet size
Logic to choose "violate" action	N/A	All other packets	All other packets

Figure 6-26 shows how a single-rate, three-color policer replenishes the tokens in the dual token buckets.

Figure 6-27 depicts the mechanics of how a dual-rate, three-color policer works in regards to refilling tokens into the dual token buckets:

Table 6-18 summarizes the small details about the defaults for Bc and Be. The table lists all three cases, plus a reminder of how to know which style of configuration is being used.

Table 6-18. Summary of Default Calculations for Bc and Be with CB Policer

Type of Policing Configuration	Telltale signs in the police command	Defaults
Single Rate, Single Bucket/Two color	No violate-action or Be configured, no PIR configured	Bc = CIR/32 Be = 0
Single Rate, Dual Bucket/Three color	violate-action and/or Be is configured, no PIR configured	Bc = CIR/32 Be = Bc
Dual Rate, Dual Bucket/Three color	PIR is configured	Bc = CIR/32 Be = CIR/32

Table 6-19 lists the various actions associated with CB policing.

Table 6-19. Policing Actions Used by CAR and CB Policing

Command	Mode and Function
drop	Drops the packet
set-dscp-transmit	Sets the DSCP and transmits the packet
set-prec-transmit	Sets the IP precedence (0 to 7) and sends the packet
set-qos-transmit	Sets the QoS group ID (1 to 99) and sends the packet
set-clp-transmit	Sets the ATM CLP bit (ATM interfaces only) and sends the packet
transmit	Sends the packet

The list that follows summarizes the core features of how Cisco implements CB Policing.

• Supports Single-rate, two-color policing, which uses a single token bucket, and two action categories (conform and exceed)

• Single-rate, three-color policing, which uses two token buckets, and three action categories (conform, exceed, and violate)

• Dual-rate, three-color policing, using two buckets, supporting both CIR and PIR rates

• "Two Color" and "Three color" terminology refers to the actions categories that can be determined by the policer namely conform, exceed, and violate

• Supports policing of a subset of traffic by using MQC classes, with the police command enabled in the traffic classes that include the packets that need to be policed

• Support for multiactions policing by repeating the conform-action, exceed-action, and/or violate-action keywords.

• For single-rate policing, if Bc and Be are not configured, IOS calculates the values as Be = 0 and Bc as the larger of either 1500 or CIR/32.

• For dual-rate policing, if Bc and Be are not configured, IOS calculates the values as follows: Bc as the larger of either 1500 or CIR/32, and Be as the larger of either 1500 or PIR/32.

• The police command allows configuration of the rates as percentages of link bandwidth, with Bc and Be being set as a number of milliseconds.