Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
DQOS Exam Certification Guide - Cisco press.pdf
Скачиваний:
68
Добавлен:
24.05.2014
Размер:
12.7 Mб
Скачать

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

Traffic-Policing and Traffic-Shaping Concepts 345

as “conform,” before all of Be has been consumed! The strategy behind discarding a few packets, but not all, when consuming the tokens in Bucket2 follows the same concept as WRED. By discarding a few packets before all the Be capacity has been consumed, maybe the senders of the traffic may reduce the rate of sending packets, reducing congestion, and avoiding the day when all packets exceed the policed rate.

NOTE For the remaining discussion of how policing works with Be, assume that the action for conforming packets is to forward the packet, and the action for nonconforming packets is to discard the packet. Other options, such as re-marking the packets, are available; however, continually referring to those options during this discussion just confuses the discussion.)

To understand how CAR works is to understand how the buckets are filled and drained. Initially, CAR fills Bucket1 with Bc tokens, and Bucket2 with Be tokens. Remember, each token represents a single byte, and Bc and Be are configured in bytes.

CAR replenishes Bucket1 every Tc by adding Bc tokens to the bucket, but CAR does not directly replenish Bucket2. When CAR adds Bc tokens to Bucket1, if any tokens are spilled, those tokens fill Bucket2. If Bc = 10,000, and Bucket1 has 2000 tokens in it when CAR refills Bucket1, for example, 2000 tokens spill into Bucket2. Bucket1 has a maximum capacity of Bc tokens, which effectively means that Bucket1 gets refilled to its maximum every Tc. Bucket2 has a maximum capacity of Be tokens, but it may not get filled to capacity each Tc—that depends on how many tokens “spill” out of Bucket1 when it is refilled. Figure 5-14 outlines the process.

Figure 5-14 Refilling Dual Token Buckets with CAR

Token Generator:

Policer Creates New Tokens,

Refills with Bc Tokens Every Tc

$.25 Token

Spillage Falls

$.25 $.25 into Bucket2

Token Token

$.25 $.25 Bucket1 Token Token

Size:Bc

$.25

Token

$.25 Token

Spillage

$.25 $.25 Wasted

Token Token

Bucket2

$.25

$.25

Size:Be

Token

Token

 

 

$.25 Token

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

 

Da = Old Da +

Dc = Old_Dc +

 

Packet

New_Packet_Length

New_Da

Dc

 

 

 

 

1st 1000-byte packet

1000

0 + 1000

1000

 

 

 

 

2nd 1000-byte packet

2000

1000 + 2000

3000

 

 

 

 

3rd 1000-byte packet

3000

3000 + 3000

6000

 

 

 

 

4th 1000-byte packet

4000

4000 + 6000

0*

 

 

 

 

5th 1000-byte packet

5000

0 + 5000

5000

 

 

 

 

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

Traffic-Policing and Traffic-Shaping Concepts 347

Dc grows until it passes Be. When Dc is calculated and happens to be above Be, CAR considers the packet to exceed the traffic contract. At that point, CAR resets Dc to 0, as shown in Table 5-6. Note that the fourth 1000-byte packet causes the Dc value to exceed Be, so the packet is considered to exceed the contract, and the Dc value is reduced to 0.

Now that Da and Dc have been defined, the full logic of deciding whether each packet conforms or exceeds can be outlined, as shown here:

1If 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.

2If the number of bytes in the packet is greater than (>) the number of tokens in Bucket1, but the number of bytes in the packet is less than or equal to (<=) the number of tokens in Bucket2, use the following debt computations:

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

b.If Dc is greater than (>) Be, the packet exceeds the contract. CAR removes no tokens from either bucket, and performs the action for packets that exceed the contract. CAR also resets Dc to 0.

3If the number of bytes in the packet is greater than (>) the number of tokens in Bucket1 or Bucket2, the packet exceeds the contract. CAR removes no tokens from either bucket, and performs the action for packets that exceed the contract.

During a particular interval, as long as there are plenty of tokens in Bucket1, the packets conform (Step 1). If there are not enough tokens in Bucket1 or Bucket2, the packet exceeds (Step 3). At Step 2, however, while consuming Bucket2’s tokens, a few packets can actually exceed the contract, and others will actually conform to the contract. Figure 5-15 depicts the idea behind how Da and Dc grow with CAR.

Figure 5-15 Actual Debt and Compounded Debt with CAR

Point at Which Dc Caused Single

Packet Drop When Dc > Be Point at Which Be Has Been

Consumed; All Packets Dropped

Be

Dc

Da

 

0

Dc

Da