QoS Into the Network: Part 2

Gilbert Held

This article is a continuation of a series focused upon various methods and standards associated with Quality of Service (QoS). The first article provided an overview of QoS. The second article examined how the IEEE 802.1p standard provides a mechanism for traffic differentiation in a LAN switching environment. In the third article, I examined QoS through the WAN, covering egress from the LAN into the WAN and some of the methods that could be used to prioritize traffic. That article also represents the first of a two-part series (within a series) concerning the entry of data into a layer 3 network. In it, I examined four types of router queuing methods, as well as the use of the IPv4 Type of Service (ToS) byte. I mentioned in that article that the limited use of the ToS byte resulted in the IETF redefining its composition as a mechanism to differentiate service, resulting in the names “DiffServ byte” and “differentiated services” used to reference the revised composition of the byte and the use of the byte's contents. This article will cover DiffServ in more detail.

One of the difficulties associated with writing an article covering QoS techniques is the fact that some techniques are applicable both at the edge and through a network. In particular, as I will note in this article, Differentiated Services are not only applicable to the edge of the WAN but also governs the way packets with different DiffServ bit settings are handled within a network. Thus, a more precise title for this article could be “Into and Through the Network”. Rather than select a title that would resemble a fairy tale, this author decided to leave well enough alone.

Overview

Differentiated Services can be considered as a set of technologies that permits network service providers to offer different categories of QoS to different customer traffic streams. The use of Differentiated Services requires the establishment of a Service Level Agreement (SLA). The SLA is established between the service provider and the customer prior to the use of Differentiated Services. The SLA can specify the manner by which packets are handled based upon one or more metrics. Those metrics can include the expected throughput obtained, the probability of a packet being dropped, the delay or latency resulting from packets flowing through a network, and the variation in the flow of packets received when a stream is presented to the network. That last metric is commonly referred to as jitter.

The SLA is used by the network operator to define the manner by which packets will be handled based upon the composition of the DiffServ byte. Here “handling” is a loose term that refers to the forwarding service customers will receive for a particular packet class or set of classes. Once the SLA is established, the customer submits packets with applicable DiffServ bit settings to indicate the service desired. The service provider then becomes responsible for assuring that their routers are configured with applicable forwarding policies to provide the QoS specified in the SLA for each packet class.

Instead of taking the traditional approach to QoS, in which routers along the path from source to destination reserve bandwidth for a traffic stream, DiffServ simply assigns a value to a byte in the IP header that allows all routers on a path to forward traffic according to the byte setting. This action eliminates the necessity of conveying separate signaling information between routers. By eliminating the need for separate signaling information, DiffServ avoids the high overhead associated with RSVP, which made it impractical for use on the Internet. Another advantage associated with DiffServ is the fact that many traffic streams can be aggregated to one of a small number of behavior aggregates (BAs). That is, all traffic with the same DiffServ byte settings are treated in the same manner by each DiffServ compatible router, regardless of source, destination, or composition of a packet. Thus, it is possible for a voice conversation and a near-real-time application between pairs of dissimilar addresses to be treated in the same manner as their packets flow through a network. The BA traffic streams are forwarded by each DiffServ-compatible router based upon one of a limited number of per hop behaviors (PHBs) further simplifying data flow and minimizing the processing effort of routers.

Operation

Differentiated Services are provided by network service providers to customers. This service requires negotiation ahead of time so that customer traffic can be processed through the network based upon the manner by which the DiffServ byte is marked or classified in each packet at the edge of the network.

The DiffServ byte is based upon the use of the ToS field in the IPv4 header and the Traffic Class field in the IPv6 header; however, it maintains backward compatibility with the RFC 791 IPv4 specification that defined the original use of the bit positions in the ToS field. To obtain backward compatibility, the DiffServ byte uses bit positions 0, 1, and 2 for priority settings that provide a general mapping to the Precedence field in the ToS byte. Thus, routers that use the Precedence field in the ToS byte will not choke on the DiffServ byte. Instead, such routers will provide a priority flow similar to that provided to a packet where the IPv4 header uses a ToS byte.

The DiffServ byte both reorganized and renamed the first three bit positions of the IPv4 ToS byte. Table 1 lists the eight precedence levels now defined under DiffServ.

In examining Table 1, note that precedence levels 6 and 7 remain the same as they are still assigned to network operations, such as routing protocols and keep alive signals. Collectively, Classes 1 through 4 are referred to as Assured Forwarding (AF) and are used in conjunction with bit positions 3 and 4, of the DiffServ byte. By setting bits 3 and 4 it becomes possible to specify the forward percentage of packets for each class of traffic. Collectively, bits 3 and 4 of the DiffServ byte are referred to as the DiffServ Code Point (DSCP). Table 2 illustrates the use of DSCP codes that enable traffic to be differentiated within a class. The reason six bit positions are shown for each drop percentage for each class is because bit 6 is always assigned a value of zero.

Although bits 3 and 4 represent the DSCP bits, in some literature the first six bits in the DiffServ byte are referred to as the DS codepoint. That codepoint takes the following form to indicate a drop percentage for each of the four traffic classes:

xxxyy0

Two other codepoint bit compositions included in RFC 2474 that define the DiffServ byte are xxxx11 and xxxx01 (with x again representing either a binary 0 or 1). The first format is currently reserved for experimentation. The second format is also reserved for experimentation; however, it can be allocated for future use by a subsequent DiffServ specification. Last but not least, a DSCP value of all zeros (000000) represents a default packet class best effort forwarding request. This means that packets marked with this value are forwarded in the order they are received whenever bandwidth is available.

Also note that, under this router forwarding mechanism, the forwarding action that occurs based upon the setting of bits 3 and 4 is not standardized. That is, there is no precise definition of “low”, “medium”, and “high” drop percentages. Because not every router initially will be DiffServ compliant and recognize bit positions 3 and 4, its previously mentioned backward compatibility with the precedence field in the ToS byte permits routers to forward packets based upon a lower level of granularity by only considering a packet precedence value. Also note that instead of including a granular capability for a precedence value of 5, the use of expedited forwarding provides a higher level of service that enables service providers to guarantee a minimum service level. To do so, a service provider could use a queuing method that results in packets with a DiffServ precedence of 5 receiving a minimum amount of bandwidth. This would compensate for the situation where a severely congested circuit could result in poor performance for classes 1 through 4.

DSCP Processing

Once a packet's DSCP bits are set at the entry to a network, they are examined by all routers within the network. Because the Internet represents a network of interconnected networks, the term “domain” is used to reference an administrative entity, such as an Internet Service Provider (ISP). Within a domain, packets receive a consistent level of service based upon the setting of the DSCPs, which enables the service provider to negotiate SLAs with their customers. A customer can be a user, organization, or another domain. When the customer is another domain, the home domain will attempt to forward packets to the foreign domain requesting appropriate service to match the original requested level of service. Unfortunately, there is no standard billing mechanism or available metering software that examines DiffServ traffic classes, which means that the practicality of interdomain DiffServ communications may take some time to occur.

Routers within a domain can be classified as either boundary nodes or interior nodes. Interior node routers perform forwarding based upon the composition of the bits in the DiffServ byte. This forwarding treatment is referred to as per hop behavior (PHB). In comparison, boundary routers are responsible for the classification of packets. With this in mind, I will focus on the functions performed at the edge of the network, which provide the information used by the interior nodes within a domain.

Ingress Functions

As data from a host enters a DiffServ compatible router at the edge of a network, a traffic-conditioning process will occur. That process is based upon four QoS control functions: classifying, metering, action, and queuing. First, each message is classified based upon a set of rules, resulting in the name “classifier” associated with this function. A second function involves measuring submitted traffic to determine whether it conforms to the negotiated SLA. This function is referred to as metering. A third function involves performing one or more actions applicable to the classification of the packet. One action could be applying a policy or set of policies to traffic by changing the assignment of codepoints, a technique referred to as marking. Another action can result in traffic being delayed to ensure it does not exceed the traffic rate specified for a particular class. Because this action alters the flow rate, it is referred to as traffic shaping. A third action results in the discard of packets when their rate exceeds that of the rate specified for their class and the flow cannot be delayed by traffic shaping. This action is referred to as dropping. Finally, the fourth QoS control function involves the queuing of traffic for output in an appropriate queue based upon its DSCP bit settings.

The relationship of the four previously described DiffServ control functions are illustrated in Figure 1. In examining Figure 1, note that all packets are first classified. Once classified, the resource utilization of flow packets must be measured. The metering function measures the volume of packets in the flow over a predefined time interval. This measurement permits the compliance of the flow with the SLA to be determined and permits an applicable action to occur. As previously noted, available actions include marking, traffic shaping and dropping. However, there is a fourth action that is not shown in Figure 1. That action (or perhaps inaction) is to do nothing and simply pass the classified packet to the queuing control function.

Classifier Operation

A classifier is a logical 1:N fan-out device. Although it forwards packets in a serial stream to the marker, it generates N logically separate traffic streams as output. The simplest type of classifier is a behavior aggregate (BA) classifier. The BA classifier uses only the DSCP in the IP packet header to determine an appropriate output stream to which the packet should be directed. A more complex classifier would be a multi-field classifier. This type of classifier is based on the use of one or more fields plus the DSCP field. One common multi-field classifier is represented by the use of the destination address, source address, and IP Protocol Type fields in the IP header, and the source and destination ports in the UDP or TCP header. Because the preceding field values are used in conjunction with the DSCP, this multi-field classifier is also referred to as a sextuple classifier.

Metering

Metering also represents a logical 1:N fan-out operation, in which the rate of traffic flow is compared to SLA thresholds to determine the flow's conformance to a particular SLA. There are three levels of conformance: green, yellow, and red. A green level of conformance indicates that a flow conforms to its associated SLA. Yellow indicates particular conformance, while red indicates non-conformance. These three levels of conformance can trigger an applicable action, such as marking or dropping, or can be used to trigger a particular type of queuing.

Action

Figure 1 showed three action elements, and I previously described a fourth, which is to do nothing. This is a so-called null action. Service providers charge different fees or surcharges for the flow of packets within different traffic classes. Because of this, another potential action is counting. Counting represents a passive action with respect to traffic, and can be used for billing. Additionally, this action can provide a mechanism for service verification and give the service provider qualitative information that could be useful for network engineering purposes. Because DiffServ was only recently standardized via a series of RFCs, a large amount of effort needs to occur to both implement the technology as well as make it effective. Concerning the latter, suppose your organization entered into an SLA with a service provider and wanted to verify the level of service obtained. Although you might trust your service provider to furnish a counting of packets in different classes, the ability to use SNMP to directly query counters might be a more suitable method. However, it may be quite some time until customers obtain this capability, since it's not a vendor implementation priority.

Routing

As briefly mentioned earlier, the routing or forwarding of packets within a domain is referred to as per hop behavior (PHB). Because an edge router is responsible for classifying, metering, and for several action elements, interior routers are typically relieved of those functions. Thus, an interior router will normally have its DiffServ operations focused upon examining the DSCP bit settings in inbound packets and transferring the packet to an appropriate queue based on that information. PHB is expected to be supported over various underlying technologies, such as the mapping of the DSCP byte to a Multi Protocol Label Switch (MPLS) label value, or via ATM. In fact, the ATM Forum is working to define a new VC call setup information element to transport PHB ID codes between ATM switches.

Another area being considered by various committees is the development of an optional QoS agent that could provide either active or passive support for the Resource ReSerVation Protocol (RSVP). Here possible support would result in the agent's snooping through RSVP messages to learn how to classify traffic without participating as an RSVP protocol peer. In comparison, under active support, the QoS agent could participate in a per-flow-aggregate signaling of QoS requirements. A DiffServ-compliant router could then accept or reject RSVP admission requests to provide a mechanism of admission control to DiffServ-based services.

Although Differentiated Services is an emerging QoS mechanism, it appears to have a higher probability of implementation than RSVP. This is because signaling information is conveyed within the DiffServ byte, thereby avoiding the signaling overhead associated with RSVP. Another reason for optimism is that DiffServ can be mapped to MPLS labels, providing a mechanism to expedite the flow of traffic through the interior of a network. In next month's article of this series covering QoS, I will focus on RSVP and MPLS, as well as put together the pieces of the QoS puzzle by describing and discussing application techniques that facilitate the flow of packets through a WAN.

About the Author

Gilbert Held is an award-winning author and lecturer. Gil is the author of over 40 books and 250 technical articles and has represented the United States at technical conferences in Moscow and Jerusalem. Some of Gil's recent titles include Voice and Data Internetworking and Cisco Router Performance, both published by McGraw Hill. Gil can be reached via email at gil_held@yahoo.com.