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 Table 2-19 Comparison of DiffServ PHBs
PHB Key Components Names of DSCPs
Best effort (BE) PHB for getting no specific QoS treatment DSCP BE (default) Class selector
(CS)
Uses 8 DSCPs, all with binary 0s for the last 3 bits.
Used for backward compatibility with IP precedence.
Uses “bigger-is-better” logic—the bigger the DSCP, the better the QoS treatment.
CS1, CS2, CS3, CS4, CS5, CS6, CS7
Assured forwarding (AF)
PHB consists of 2 components: queuing to provide a minimum bandwidth to each for 4 different queues, and 3 drop thresholds inside each queue. DSCPs do not always follow the “bigger-is-better” logic.
AF11, AF12, AF13, AF21, AF22, AF23, AF31, AF32, AF33, AF41, AF42, AF43 Expedited
forwarding (EF)
PHB also has 2 components: queuing to provide low delay/jitter/loss plus a guaranteed amount of band-width, and policing to prevent EF from preventing other types of traffic from getting enough bandwidth.
EF
McCoy
Ordinance, Inc. ISP1 ISP2
Marked as Follows Inside McCoy:
AF2x: Web Traffic from E-Commerce Servers AF3x: VoIP Signaling
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 bound-ary 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 (mul-tifield 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
Traffic Conditioner Explanation
Metering The metering function measures the traffic rate to determine whether the traffic conforms to the stated contract, or exceeds the traffic contract.
Metering typically occurs per class.
Dropping (policing) If the traffic exceeds the contract, one option is to drop some packets, so that the packets that are allowed through meet the contract. Most implementations for this feature are called policing.
Shaping If the traffic exceeds the contract, one option is to shape the traffic.
Shaping just means to buffer or queue the traffic, slowing it down, so that the resulting sending rate is within the contract.
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
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.
Marking A third option for traffic that exceeds the contract is to re-mark the DSCP with a different value. For instance, Platinum AF41 (low drop probability) traffic that exceeds the contract might get re-marked to AF43. In such a case, if congestion were to occur, this packet would more likely be dropped than if not re-marked.
Do nothing Not actually written down in the RFCs; one option is to allow the traffic to keep moving right along.
Table 2-20 Traffic Conditioners (Continued)
Traffic Conditioner Explanation
Meter
Classifier Marker Shaper/Dropper
Figure 2-20 Examples of When to Use Each Traffic-Conditioning Tool
DiffServ provides a formalized but sensible approach to QoS over the Internet. By using classes that aggregate the packets of many flows, DiffServ can scale well in the Internet. The next section covers the other specification for an Internet QoS model: IntServ.
McCoy
- Platinum - 400 kbps - Gold - 300 kbps
- Platinum - 400 kbps - Gold - 300 kbps - Silver - 200 kbps