Traffic Policing and Shaping Overview

When implementing Quality of Service (QoS) on a network, one of the main features to consider is the ability to regulate traffic flow. There are two methods that can be implemented independently or together to achieve this. These methods include traffic policing and traffic shaping. For in-depth configuration information, see subsequent article on Traffic Policing and Shaping Configuration.

Traffic Policing and Shaping

Following are the main differences between traffic policing and traffic shaping. Generally speaking, traffic policing takes a harder view of traffic that violates the configured allowable amount of traffic; what this means is that traffic that exceeds a traffic policing limit is typically dropped. Traffic shaping, on the other hand, takes the softer approach by attempting to “smooth” out traffic that violates the configured limit by buffering it and attempting to send it when available bandwidth exists.

Both traffic policing and shaping are implemented using a token bucket mechanism. It is important to have a general idea of how the token bucket mechanism works in order to understand how traffic decisions are made by these two features.

A token bucket has three components: a mean rate, a burst size, and a time interval (Tc). The mean rate (also referred to as the Committed Information Rate (CIR)) specifies how much data that can be transmitted per unit of time on average and is typically represented in bits per second. The burst size (also referred to as Bc) is used to specify the amount of traffic that is allowed to “burst” over the configured mean rate, and is typically represented in bits (shaping) or bytes (policing) per burst. The time interval, also called the measurement interval, is used to specify the time quantum in seconds per burst.

The tokens that are added to the token bucket represent the traffic that is allowed to be transmitted by the device. The policer or shaper adds a specific amount of tokens to the bucket based on the configured settings; when traffic is ready to be processed, the token bucket is checked to ensure that enough tokens exist to pass that amount of traffic. If there are enough tokens to pass the traffic, traffic is allowed; if not, a secondary action is taken. The action that is taken depends on whether policing (traffic is typically dropped) and/or shaping (traffic is typically buffered) is configured. Traffic policing and shaping also differ in how they implement “filling” this token bucket.

With traffic policing, the bucket is initially filled with tokens equal to the normal (committed) burst value configured in bytes; as this is the total capacity of the token bucket, no additional tokens are allowed until the bucket is initially used when the first packet processed. Upon the receipt of the second packet, the token bucket is filled based on the following formula:

(Time between packets * policer rate)/8 bits per byte = Number of tokens to add

With traffic shaping, instead of the bucket being filled based on when each packet is received, it is constantly filled at each timed interval based on the configured rate in bits per second. To calculate the timed interval, the following formula is used:

Tc = Bc/CIR (in seconds)

Cisco Traffic Policing and Shaping Implementations

Cisco has a number of different methods of implementing both traffic policing and traffic shaping.

The traffic policing feature can be implemented using the Committed Access Rate (CAR) feature (rate limiting) or using the traffic policing feature that enables class based policing (preferred).

The traffic shaping feature can be implemented using a number of different mechanisms including Generic Traffic Shaping (GTS), Class-Based Traffic Shaping (Preferred) and Frame Relay Traffic Shaping (FRTS).

The traffic policing and Class-Based Traffic shaping feature configuration will be covered in a separate configuration article.

Summary

The implementation of traffic shaping and/or policing is integral to an effective QoS policy. While the concepts that are utilized by these features can seem complex, understanding them becomes easier once a couple of scenarios have been completed. Hopefully the information from this article enables the reader the ability to have a starting place when performing these scenarios.