November 1998

BY TONY RYBCZYNSKI

Demand for IP class of service (CoS) capabilities has several drivers, including 1) the growing excitement over multimedia IP applications; 2) the increasing importance of IP data applications, which are assuming mission-critical status; and 3) the emergence of data-driven virtual private network (VPN) services. All of these drivers encourage the development of more sophisticated - and more effective - CoS initiatives. Furthermore, these initiatives, which are being guided by standards bodies such as the Internet Engineering Task Force (IETF), bring IP closer to the vision of integrated IP and application optimized networking.

CoS DRIVERS
That drivers for CoS should emerge in the enterprise space should come as no surprise. Enterprise users, who tend to deploy more sophisticated applications, are often the first to encounter, and articulate, new demands, which then serve as drivers for something better.

Multimedia IP Applications
Anticipation is building for various forms of multimedia IP applications, including audio and video streaming and multicast, Internet telephony, desktop video conferencing, and collaborative applications. Indeed, this anticipation is already evident. For example, coding and compression of voice and video are already being built into business PC motherboards and operating systems. In addition, application programming interfaces are being defined to support CoS capabilities for all forms of applications. Two good examples are Winsock2 (for the Windows environment) and XTI (for the UNIX environment).

Mission-Critical IP Data Applications
As IP data traffic becomes mission critical, enterprise users are demanding that this traffic be given some form of priority over less-than-critical data traffic. Also, enterprise users are demanding that prioritization methods work under normal operating conditions as well as under congested and failure conditions (Table 1).

VPN Services
With the emergence of data-driven VPN services, enterprise users are demanding application differentiation as well as Service Level Agreements (SLAs) which deliver reliability, availability, and bandwidth guarantees comparable to what they can attain on private networks. On the flip side, service providers see the introduction of service classes as a means of offering differentiated services and generating some additional revenues and needed margins.

CoS INITIATIVES
The IETF, the international standards body for IP networking, has embarked on two initiatives to take IP beyond the best effort modus operandi. The first initiative, Integrated Services (Int-Serv), relies on signaling mechanisms such as RSVP. The second initiative, Differentiated Services (Diff-Serv), takes advantage of the previously unused Type of Service byte in the IP header.

Int-Serv
While it was the first CoS initiative for IP, Int-Serv was, and is, an ambitious undertaking. It defines three classes of services: 1) Best-effort class; 2) Guaranteed service class with bandwidth, bounded delay, and guarantees of lossless operation; and 3) Controlled load service, which approximates the best-effort class in a lightly loaded network.

The Int-Serv architecture also includes the specification of the Resource reSerVation Protocol (RSVP), both as a way for an application to specify what it needed, and as a way for routers to allocate network resources to the application flow to meet requested performance requirements.

Int-Serv, however, suffers from several drawbacks.

• Limited scalability. (Each router along the path has to maintain and manage state information for each application flow crossing the network.)
• RSVP's limitations. (Because IP is connectionless in nature, RSVP requests have to be re-issued periodically to reconfirm or re-establish network resource allocation - a very processor intensive activity. Also, RSVP is not well suited to short-lived flows, and these constitute a significant portion of IP traffic. RSVP by itself does not specify which path across the network should be used for a particular flow.)
• Possibility of resorting to denial of service. (Denial of service does not fit today's IP paradigm.)

The result of these drawbacks is that Int-Serv is more of a solution for small networks. Nonetheless, RSVP will likely remain as one way for applications to signal their needs to the network, particularly for demanding applications such as high-quality video transmissions.

Diff-Serv
Currently under development, Diff-Serv offers a simpler framework for IP CoS. A major distinction is that no per-flow state signaling is specified, significantly enhancing the scalability of this approach. Furthermore, not only does this avoid the need for per-flow state information per router, but traffic aggregation of traffic belonging to a particular class is also supported.

An important advantage of the Diff-Serv architecture is that incremental deployment is possible since not all network devices along the path need to be upgraded for the users to achieve some of the IP CoS benefits. Rather than relying on signaling mechanisms such as RSVP, Diff-Serv relies on the previously unused Type of Service byte in the IP header (relabeled under Diff-Serv as the Differentiated Service or DS field). Initially, two service classes are being defined: best effort and expedited forwarding.

Queue Management: IP packets with similar DS requirements are handled at each network node by a series of queues. Queue management, which includes scheduling, governs how the various queues are serviced across the available bandwidth.

There are several scheduling options:

• Priority queuing. (Results in totally emptying higher priority queues before serving lower priority queues.)
• Weighted fair queuing. (Serves all queues such that each queue is given a weight that determines the share that a given queue gets of the available bandwidth. For this scheme to be effective, the length of the packets must be taken into account.)
• Hierarchical class-based queuing. (Defines traffic sub-classes that share a portion of the available bandwidth.)

In these queue management techniques, packets are handled as they exit each node in an uncongested network. Accordingly, we can say these techniques are emission priority handling techniques. While each technique in the list is progressively more sophisticated, all of the techniques are sufficiently demanding; that is, each one (even the simplest) must be implemented in hardware to operate at the required speeds.

Buffering: In real-world networks, congestion is a given, whether it occurs because of unplanned demands or network failures. One solution is to add buffering. However, adding buffering is both expensive and leads to potentially large delays and unacceptable delay variation (also called jitter).

Once buffers overflow, packet loss results, leaving packet retransmissions to end-to-end protocols such as TCP. However, while waiting for buffers to overflow may eliminate the congestion, it also has a dramatic effect on TCP traffic. This has been solved by randomly discarding packets when queues start building up but prior to buffer overflow. Weighted random early discard (WRED) applies the same strategy but enhances it by recognizing that the discard priorities for the different classes of traffic are not the same.

Layer 2 Architectures: The refinements don't stop with all the scheduling and buffering schemes. Granted, these schemes do represent improvements. That is, they allow us to define a small number of classes, permitting operation on a hop-by-hop basis - which is better than what is available today. However, these refinements only partially meet the needs of applications and of VPN SLAs.

There are, in addition to scheduling and buffering schemes, solutions that take advantage of Layer 2 connection-oriented operation, solutions designed to deliver even higher levels of service. The advantage of connection-oriented operation is that it establishes an end-to-end path across the network on either a flow- or topology-driven basis.

Three Layer 2 architectures are being used in this way: 1) Frame relay (attractive because of its efficient bandwidth utilization) operating under the Next Hop Resolution Protocol model; 2) ATM with its QoS-based routing and its rigorously defined virtual circuit class of service structure (operating, for example, under Multi-Protocol Over ATM, or MPOA); and 3) Multi-Protocol Label Switching (MPLS, being standardized by the IETF), with its IP-optimized signaling and label switching capabilities.

Of course, IP has been riding on ATM and frame relay for years (by using Layer 2 as a network link without taking advantage of any of the inherent CoS capabilities of these network links). The difference here is that these schemes allow the inherent attributes of the Layer 2 to be leveraged in the end-to-end service characteristics. An added value of these schemes is that it provides the service provider with enhanced traffic management capabilities, which are transparent to the user except inasmuch as reliability is enhanced.

SOME FINAL WORDS
All this is to say that the IP world is getting class. Initially, CoS will be accomplished by instituting a simple class structure and per-hop handling mechanisms. In the longer term, these initiatives will be enhanced by Layer 2 connection techniques to meet SLAs for backbone VPN services and certain performance-critical applications. These long-term solutions are necessary if IP is to meet the vision of integrated IP and application optimized networking.

Tony Rybczynski is director of strategic marketing and technologies for Nortel's Bay Network Division. This business unit offers a full range of enterprise workgroup, campus, and wide area unified networks, through direct and indirect channels. For more information, visit the company's web site at www.nortel.com. E-mail questions or comments to the author at [email protected].

Table 1. Signaling Of Application CoS Requirements: Selected Methods

The best-effort networking model is clearly inadequate to meet enterprise demands. So, vendors and service providers are looking to add CoS (Class of Service) and QoS (Quality of Service) to the IP and LAN world. The terms are used interchangeably, but I prefer the following general definition (by analogy): CoS is akin to first- and second-class mail, while QoS is more akin to services with specified performance attributes (for example, guaranteed overnight delivery, registered mail).

More technically, CoS is a classification scheme whereby types of traffic with similar performance requirements are grouped together for handling by the network. QoS, on the other hand, covers attributes such as latency, jitter, throughput, and loss - that is, attributes that can be mapped to a particular class of traffic. In the world of SLAs, QoS attributes (for example, minimum aggregate throughput guarantees) may be specified across several classes of service.

A lot of the terminology has come from ATM networking, which was designed from the very beginning to support multiple classes of service (for example, unspecified, constant, and variable bitrate services), with a range of QoS attributes (for example, latency, delay variation, cell loss, peak and sustained cell rate, and so on).