A Two-Rate Three-Color Marker (RFC 2698)

The Single-Rate Three-Color Marker/Policer presented a significant improvement for policers, in that it made an allowance for temporary traffic bursts (if the overall average transmitted rate was equal to or below the CIR). However, the variation in the amount of accumulated excess burst credits could cause a degree of unpredictability in traffic flows. To improve on this, a Two-Rate Three-Color Marker/Policer was defined in RFC 2698. This policer addresses the Peak Information Rate (PIR), which is unpredictable in the RFC 2697 model. Furthermore, the Two-Rate Three-Color Marker/Policer allows for a sustainable excess burst (negating the need to accumulate credits to accommodate temporary bursts).

The Two-Rate Three-Color Marker/Policer uses the following parameters to meter the traffic stream:

• PIR: Peak Information Rate; the maximum rate traffic ever allowed
• PBS: Peak Burst Size; the maximum size of the first token bucket (referred to as Be within Cisco IOS syntax)
• CIR: Committed Information Rate; the policed rate
• CBS: Committed Burst Size; the maximum size of the second token bucket (referred to as Bc within Cisco IOS syntax)
• Tp: Token count of CBS; the instantaneous number of tokens left in the PBS bucket
• Tc: Token count of EBS; the instantaneous number of tokens left in the CBS bucket
• B: Byte Size of Offered Packet

The Two-Rate Three-Color Policer also uses a two-token bucket algorithm, but the logic varies slightly. Rather than transferring unused tokens from one bucket to another, this policer has two separate buckets that are filled each second with two separate token rates. The first bucket is filled with the PIR amount of tokens, and the second bucket is filled with the CIR amount of tokens. Any unused tokens are discarded (from both buckets) at the end of each second. In this model, the Be works the same as the Bc, except for the PBS bucket (not the CBS bucket). This means that Be represents the peak limit of traffic that can be sent during a subsecond Interval. The logic varies further in that the initial check is to see if the traffic is within the PIR, and only then is the traffic compared against the CIR. (That is, a violate condition is checked for first, then an exceed condition, and finally a conform condition, which is the reverse of the logic of the previous model.) Figure 1 illustrates this logic.

 
Figure 1: RFC 2698 Two-Rate Three-Color Policer logic

The Two-Rate Three-Color Marker allows for sustainable excess bursts (and is not dependent on accumulating credits) and has a hard-top peak limit, as shown in Figure 2.

 
Figure 2: RFC 2698 Two-Rate Three-Color policer effect on traffic flow

Example 1 shows the configuration to police traffic on class-default to a CIR of 256 kbps with a Bc of 1500 bytes and a PIR of 512 kbps with a Be of 3000 bytes. Note that for this policer, CIR and PIR are defined in bps, but Bc and Be are defined in bytes. As before, the policer is configured to function as a marker that complies with the Assured Forwarding PHB, but this time for AF class 4.

Example 1: RFC2698 Two-Rate Three-Color Policer Example

---

Router(config)# policy-map RFC2698-POLICER
Router(config-pmap)# class class-default
Router(config-pmap-c)# police cir 256000 bc 1500 pir 512000 be 3000
Router(config-pmap-c-police)# conform-action set-dscp-transmit af41
Router(config-pmap-c-police)# exceed-action set-dscp-transmit af42
Router(config-pmap-c-police)# violate-action set-dscp-transmit af42

A Single-Rate Three-Color Marker (RFC 2697)

With the Single-Rate Policer, the token bucket is emptied at the end of the second, and any unused tokens are wasted. An improvement to this algorithm is defined in RFC 2697, which details the logic of a Single-Rate Three-Color Marker.

The Single-Rate Three-Color Marker/Policer uses a two token bucket algorithm. Any unused tokens are not discarded at the end of a second, but rather are placed in a second token bucket to be used as credits later for temporary bursts that might exceed the CIR. The initial allowance of tokens placed in this second bucket is called the Excess Burst (Be). This is the maximum number of bits that can exceed the burst size.

This model allows three possible traffic conditions to be identified (hence the term “Three-Color”): conform, exceed, or violate. And, in turn, specific actions can be defined for each of these three states, including transmit, re-mark, or drop.

The Single-Rate Three-Color Marker uses the following definitions within the RFC:

• CIR: Committed Information Rate; the policed rate
• CBS: Committed Burst Size (CBS); maximum size of the first token bucket (referred to as Bc within Cisco IOS syntax)
• EBS: Excess Burst Size (EBS); maximum size of the second token bucket (referred to as Be within Cisco IOS syntax)
• Tc: Token count of CBS; the instantaneous number of tokens left in the CBS bucket
• Te: Token count of EBS; the instantaneous number of tokens left in the EBS bucket
• B: Byte size of offered packet

Figure 1 illustrates the logical flow of the Single-Rate Three-Color Marker/Policer.

 
Figure 1: RFC 2697 Single-Rate Three-Color Policer logic

The Single-Rate Three-Color Policer’s tolerance of temporary bursts, shown in Figure 2, results in fewer TCP retransmissions and thus more efficient bandwidth utilization. Furthermore, it is a highly suitable tool for marking according to RFC 2597 AF classes, which have three “colors” (or drop preferences) defined per class (AFx1, AFx2, or AFx3).

 
Figure 2: RFC 2697 Single-Rate Three-Color Policer effect on traffic flow

Example 1 shows the configuration to police traffic in class-default to a CIR of 256 kbps with a Bc of 1500 bytes and a Be of 3000 bytes. Note that for this policer, the CIR is defined in bps, but Bc and Be are defined in bytes. Additionally, the policer is configured to function as a marker that complies with the Assured Forwarding PHB for AF class 3.

Example 1: RFC 2697 Single-Rate Three-Color Policer Example

---

Router(config)# policy-map RFC2697-POLICER
Router(config-pmap)# class class-default
Router(config-pmap-c)# police cir 256000 bc 1500 be 3000
Router(config-pmap-c-police)# conform-action set-dscp-transmit af31
Router(config-pmap-c-police)# exceed-action set-dscp-transmit af32
Router(config-pmap-c-police)# violate-action set-dscp-transmit af33

Single-Rate Policers & Dual-Rate Policers

Single-Rate Policers

The earliest policers use a Single-Rate Two-Color Marker/Policer model with a single token bucket algorithm. In this model, traffic is identified as one of two states (colors):conforming (to the CIR) or exceeding (the CIR). Marking and dropping actions are performed on each of these two states of traffic. Any unused tokens left in the bucket at the end of the second/cycle are discarded. In other words, one CIR worth of tokens is granted at the beginning of a second, and at the end of the second, the bucket is emptied. This type of marker/policer is fairly crude and, when defined to drop, rather than re-mark packets, can result in the traffic policing pattern

Note

Although a policer can be deployed at ingress or egress interfaces, they are generally deployed at the network edge on traffic ingress. After all, there is little point in spending valuable CPU cycles routing and processing packets that are only going to be dropped.

Dual-Rate Policers

Random traffic patterns, whether network traffic or otherwise, generally do not respond well to crude single-rate policers. As an analogy, consider automobile traffic that is “policed” by traffic lights at intersections that have only two states/colors: green (for go) and red (to stop). Additionally, these lights could fluctuate from one state to the other without any warning or allowance. Some drivers would be arbitrarily penalized when the lights changed from one moment to the next, and the overall traffic flow would be inefficient.

However, as with traffic lights, if a third state (the yellow light) is introduced, traffic flows much better. The yellow light indicates to drivers that they are approaching the limit and allows them to react accordingly. Similarly with network traffic, a moderate allowance for burst, allows for the possibility of feeding back to the application that the transmission limits are being reached (that is, by re-marking some exceeding traffic) and allows for the applications to react accordingly (whether they do is a different matter, but at least the possibility is presented).

Therefore, with dual rate policers, there are three traffic states. Continuing the traffic light analogy, these follow:

• Conform (green light): Traffic is within the defined rate and is transmitted without any penalty.
• Exceed (yellow light): Traffic is surpassing the defined rate, yet an allowance for burst allows for a moderate penalty (typically re-marking) to be applied.
• Violate (red light): Traffic is surpassing both the defined rate and any burst allowances and should, thus, have the maximum penalty applied (which might be a second-degree of re-marking or dropping).

There are two standards-defined Dual-Rate policers (as defined in RFC 2697 and 2698, respectively). The sections that follow take a closer look at each of these.

Policing Tools | Network Quality of Service Technologies

Policers monitor traffic flows and identify and respond to traffic violations. For example, policers can monitor TelePresence flows at the campus access edge. Because TelePresence flows are bounded (to typically 5 Mbps per screen at 1080p), flows in excess of such bounds would be indicative of network abuse and can be immediately identified and responded to by policers.

Policers achieve these objectives by performing ongoing checks for traffic violations and taking immediate prescribed actions when such violations occur. For example, a policer can determine if the offered load is in excess of the defined traffic rate and then drop the out-of-contract traffic, as illustrated in Figure 1.

 
Figure 1: A generic policer

Additionally, policers can re-mark excess traffic to identify (but not necessarily drop) traffic that exceeds a given traffic contract, which might be valuable for reporting, billing, or capacity planning purposes. In such a role, the policer is called a marker. Figure 2 illustrates a policer functioning as a marker.

 
Figure 2: A policer as a marker

Cisco IOS policers are modeled after token bucket algorithms. Essentially, these algorithms are metering engines that keep track of how much traffic might be sent to conform to the specified traffic rates.

A token, in everyday use, is an item given to an individual that represents the right to use a given service, such as to ride on the subway or to play a video game, and so on. In QoS terminology, a token permits the policing algorithm to send a single bit (or in some cases, a byte) of traffic. Typically, these tokens are granted at the beginning of a second, according to the defined policing rate, referred to as the Committed Information Rate (CIR).

Tokens granted at the beginning of each second of operation are placed in a logical cache, referred to as the bucket. A key difference in policing algorithms is how unused tokens are dealt with at the end of each second: Some policers allow unused tokens to accumulate in the bucket, whereas others force unused tokens to be discarded. These differences, and the effects on traffic policing, is discussed in more detail shortly.

For example, if the CIR is set to 8000 bps, then 8000 tokens are placed in the bucket at the beginning of each second. Each time a bit of traffic is offered to the policer, the bucket is checked for tokens. If there are tokens in the bucket, the traffic is passed. One token is removed from the bucket for each bit of traffic that is passed, and such traffic is viewed to conform the rate, and the specified action for conforming traffic is taken. (The conforming traffic is typically transmitted unaltered.) When the bucket runs out of tokens, any additional offered traffic is viewed to exceed the rate, and the exceed action is taken. (The exceeding traffic is either re-marked or dropped.)

In addition to defining the CIR, policers require that a committed burst (Bc) also be defined. The committed burst, also known as the normal burst, refers to the bytes allowed in a subsecond traffic burst before packets will be considered to exceed the rate limit.