The Differentiated Services QoS Model 125

Table 2-16 Comparing Choices: Making Up DSCP Values, or Using Suggested Values from the RFCs

The next two sections cover the DiffServ RFCs’ main suggestions for DSCP values to be assigned.

The Assured Forwarding PHB and DSCP Values

RFC 2597 defines something called “the assured forwarding per-hop behaviors.” This RFC suggests that one good DiffServ design choice would be to allow for four different classes for queuing purposes. Within each queue, three levels of drop probability could be implied. The RFC title rightfully suggests that the focus is on the QoS behavior—the PHB—at each node. Most engineers also think of the RFC as defining the 12 DSCPs that are used in conjunction with the AF PHBs.

An individual PHB describes what happen in a single hop, most typically a router. In the case of AF, each PHB contains two separate QoS function, typically performed by two different QoS tools. The first function is queuing. Each router classifies the packets into four different classes, and packets from each class are placed in a separate queue. AF does also specify that the queuing method support the ability to reserve a minimum configured bandwidth for each class.

The AF PHB defines congestion avoidance as the second behavior that comprises the AF PHB. Routers drop packets when a queue is full and the router needs to place the packet in the queue; this action is called tail drop. Congestion-avoidance tools discard packets before tail drop is required, hoping that fewer packets are dropped, as described earlier in this chapter. In Cisco routers, this part of the AF PHB is implemented using some form of RED.

The AF PHB does not define that it wants a guarantee that each packet will be delivered, nor does it imply any form of error recovery. The name assured forwarding sometimes evokes visions that the bandwidth throughout the network is guaranteed, but it is not. The real objective can be seen with a short read of RFC 2597, which reveals a view of an enterprise and an ISP. The ISP wants to assure the customer that his traffic will get through the network, so long as the customer does not send more data than is contracted. For instance, maybe the enterprise has three classes (BAs) of traffic, for which they contract 300K for the first, 200K for the second,

126 Chapter 2: QoS Tools and Architectures

and 100K for the third. The ISP would like to assure that these levels are met. Because many queuing tools effectively guarantee bandwidth over time, the ISP can give these BAs the appropriate amount of bandwidth. Because packet arrival times and rates vary, however, the queues inside the ISP’s network will grow and shrink. Congestion will occur; the ISP knows it, and the enterprise customer knows it. So, when temporary congestion occurs in the ISP network, it would be nice to know which type of packets to throw away under limited congestion, and which type to throw away under moderate congestion, and which ones to throw away under heavy congestion. Letting the customer define which traffic is discarded most aggressively also lets the customer achieve some control of how its traffic is treated by the ISP. Therefore, assured forwarding does not mean that an individual packet is assured of making it across the network; it does mean that attempts will be made to assure that queuing tools provide enough bandwidth, and when congestion does occur, less important traffic will be discarded first.

RFC 2597, and the AF PHB concepts, can be summarized as follows:

•Use up to four different queues, one for each BA.

•Use three different congestion thresholds inside each queue to determine when to begin discarding different types of packets.

•To mark these packets, 12 DSCP values are needed; the names of these values as start with “AF” (assured forwarding).

NOTE RFC 2360 clarifies some of the meaning and terminology used with DiffServ. Technically, the AF PHB, according to RFC 3260, is actually four different PHBs—one for each class. Frankly, for purposes of passing the Cisco QoS exams, I do not think that will ever matter; I only mention it here to be fully correct.

Table 2-17 lists the names of the DSCP values, the queuing classes, and the implied drop likelihood.

Table 2-17 Assured Forwarding DSCP Values and Meaning

The Differentiated Services QoS Model 127

Pay particular attention to the explanation of Table 2-17 inside this paragraph, because the values in the chart can be counterintuitive. Unlike the CS PHB, AF does not follow the “bigger-is- better” logic for the AF DSCPs. First, AF11, AF12, and so on are names for DSCP values, not the binary of decimal equivalent. (Those values are listed momentarily.) Given the names, at least you can think of the first “digit” after the AF to be the queuing classification—for example, all AF4x code points are in the same class for queuing. No specific queuing parameters are implied for any of these classes, so there is no inherent advantage to being in class 4 versus class 1.

Similarly, the second numeric digit in the AF DSCP names imply the drop preference—with 3 meaning highest likelihood of being dropped, and 1 meaning the least likelihood. In other words, inside a single class, an AFx3 DSCP would mean that these packets would be dropped more quickly (more aggressively) than AFx2, which would be dropped more aggressively than AFx1 packets. In the actual DSCP names, a bigger number for the second numeric digit actually implies a less-desirable QoS behavior. (This convention is also true of the actual binary values.)

You can read about DiffServ AF PHBs, configure DiffServ-compliant IOS tools, and never really have to know the underlying binary values and their decimal equivalents. For reference, however, Table 2-18 includes them. As noted earlier, the numeric parts of the AF code points did not follow the same bigger-is-better scheme that IP precedence did in the past. Likewise, the actual underlying binary values do not follow a bigger-is-better scheme, either.

Table 2-18 Assured Forwarding DSCP Values—Names, Binary, and Decimal

The binary DSCP values imply the queuing class with the first 3 bits (bits 0 through 2), and the drop preference in the next two bits (bits 3 and 4). Queuing tools that operate only on IP precedence can still react to the AF DSCP values, essentially making the AF DSCPs backward compatible with non-DiffServ nodes for queuing, at least. Note that the “bigger-is-not-always- better” attitude continues with the actual binary values—the smaller the value of bits 3 and 4, the lower the probability of being discarded.

128 Chapter 2: QoS Tools and Architectures

In summary, DiffServ AF PHB provides the following:

•An overriding goal to provide PHBs that provide enough bandwidth for each class, with the ability to drop less important traffic, hoping to avoid dropping more important traffic, if congestion does occur.

•A convention that provides 4 classes for queuing.

•The convention includes three drop preferences inside each class.

•Twelve code point names and values to use to create the four classes with three drop levels each.

The Expedited Forwarding PHB and DSCP Values

RFC 2598 defines the expedited forwarding per-hop behaviors. This RFC defines a very simple PHB (low latency, with a cap on bandwidth), and a single DSCP (EF) to represent it. Expedited forwarding simply states that a packet with the EF DSCP should minimize delay, jitter, and loss, up to a guaranteed bandwidth level for the class.

Like AF, the EF RFC suggests two QoS actions be performed to achieve the PHB. First, queuing must be used to minimize the time that EF packets spend in a queue. A queuing scheme that sends packets from this queue whenever a packet is waiting reduces delay. Anything that reduces delay reduces jitter. Always servicing the EF queue first greatly reduces the queue length, which in turn greatly reduces the chance of tail drop due to the queue being full. Therefore, EF’s goal of reducing delay, jitter, and loss can be achieved with a queuing method such as Priority Queuing, with EF traffic in the most important queue.

The second component of the EF PHB is policing. If the input load of EF packets exceeds a configured rate, the excess packets are discarded. If 100 kbps is reserved for the EF BA, and 200 kbps enters the network, for example, supporting the extra traffic may be unreasonable.

Why not just accept the extra traffic? The queuing method used to achieve low delay, low jitter, and low loss, would prevent other types of traffic from getting any bandwidth, because the queuing method always gives preference to EF traffic. Thus, EF protects the other traffic by capping the amount of bandwidth for the class. In other words, EF suggests a great level of service, but just up to the contracted amount of bandwidth.

The expedited forwarding PHB uses a DSCP name of EF, whose binary value is 101110, with a decimal value of 46.

Table 2-19 summarizes many of the key points about the various DiffServ PHBs.

The Differentiated Services QoS Model 129

Table 2-19 Comparison of DiffServ PHBs

DiffServ Classifiers and Traffic Conditioners

DiffServ focuses on “scalable service differentiation in the Internet” according to RFC 2475. In times past, the Internet provided a “best-effort” service—networks generated and sent traffic, and the Internet forwarded it—and everyone hoped that market forces helped the Internet grow to accommodate the loads. With the advent of premium offerings from ISPs, new QoS tools and models were needed, with DiffServ being just one component.

Because DiffServ focuses on Internet services, the RFCs focus on QoS tools that are most useful when connecting multiple networks. Consider Figure 2-18, for example, which shows a network with three classes of service defined for the McCoy Ordinance Co. by ISP1.

Figure 2-18 Three Premium Classes for McCoy Ordinance by ISP1

Marked as Follows Inside McCoy:

AF2x: Web Traffic from E-Commerce Servers

AF3x: VoIP Signaling

AF4x: VoIP Payload

130 Chapter 2: QoS Tools and Architectures

ISP1 contracted with McCoy to provide three premium service levels. First assume that McCoy conforms to the defined bandwidth levels, and marks the DSCP fields appropriately with AF DSCP values as shown in the figure. Because the QoS issues involve two different networks, however, additional care must be taken with QoS functions at the edge of these networks. The rest of this brief section focuses on these DiffServ boundary node functions.

DiffServ defines two particularly important features that should be implemented on the boundary DS node: classification and conditioning. Classification has been covered in some depth already. Two general categories of classifiers exist—a BA classifier and an MF classifier (multifield classifier). The BA classifier only looks at the DSCP field—in other words, it assumes a DiffServ BA has already been identified using classification and marking. The MF classifier is called “multifield” because it can look at lots of fields in the packet header to classify the traffic. In the example of Figure 2-18, because McCoy already correctly marked the DSCP field, ISP1’s DS ingress boundary node just needed to use a BA classifier.

DiffServ defines traffic conditioning as the second important function at the boundary node. Traffic conditioning defines what to do to prevent traffic from exceeding contracts, but if it does, what to do with traffic that exceeds the contract. If McCoy always only sends what the contract defines, great! If McCoy breaks that trust and sends more traffic, and ISP1 does not monitor the traffic and possibly deletes the extra traffic, however, bad things can happen to all of ISP1’s customers. It’s like making a reservation on a plane. You know some people will change their flights, and some will miss their flights, but the airline will generally not give you a reservation unless there is a seat on the plane. What if someone were to show up at the airport with 100 of their closest friends and tell the gate agent, “Oh, I want my 100 friends to have a seat on the plane as well!”—and they let all 100 people on the plane? Well, the airline would have a lot of other unhappy customers, to be sure. Likewise, although ISP1 may want to accommodate the extra traffic, the ISP might need to protect their network from the congestion created by the extra traffic.

The terms relating to the traffic-conditioning functions of DiffServ, summarized in Table 2-20, should be mostly familiar by now.

Table 2-20 Traffic Conditioners

RFC 2475 contains a block diagram listing the classifier and traffic conditioners. This same figure, or a similar version, is interspersed through many QoS documents and QOS classes. Figure 2-19 does not intend to show a flowchart of what happens to every packet as it passes through a DS boundary node, but rather to show some of the possible paths a packet can take.

Figure 2-19 RFC2475—Equivalent Diagram of Classifier and Traffic-Conditioner Functions

Meter

Classifier Marker Shaper/Dropper

Remember, the figure does not necessarily show a flowchart of how a packet is processed on a boundary node. For instance, the packet can go through a classifier and marker function only, or it can go through the meter and dropper, but not the marker or shaper. So, what is normal? Figure 2-20 shows an example with the more typical usage of the tools shown.

The various classification and traffic-conditioning tools can be used at various points in the network as shown. Egress boundary nodes tend to shape traffic, to prevent sending more traffic than the traffic contract allows; in fact, all Cisco shaping tools shape on egress only. Ingress boundary nodes tend to use the dropper or policer conditioning functions, metering (measuring) ingress traffic, with either a drop or re-mark action as a result of excess traffic. The reason why engineers implement shaping and dropping/policing on egress and ingress, respectively, has to do with who is providing service, and who is receiving a service. For instance, McCoy is sending the traffic, with an expectation that ISP1 will forward the traffic, as long as McCoy conforms to the service contract. By shaping, McCoy makes sure to conform. By policing, ISP1 protects its network and all its customers from McCoy sending too much data into the network.