Americas

  • United States
by Peter Pawlita, special to Network World

Diff-Serv provides quality of service

How-To
Nov 04, 20023 mins
Networking

The three primary benefits of converged networks are cost-effectiveness, scalable support for voice and datastreams on a single infrastructure, and reduced management costs.

However, a converged network requires a quality-of-service (QoS) capability that ensures each application running on the network is allocated the bandwidth it needs to meet service-level agreements.

Standards-setting bodies, such as the Internet Engineering Task Force, have struggled with the best way to achieve QoS. One standard is Resource Reservation Protocol (RSVP), but it does not scale well and hasn’t been accepted widely. The Differentiated Services (Diff-Serv) standard, published in December 1998 (RFC 2474 and 2475) for Layer 3 of the International Standards Organization model, has become much more successful.

Unlike RSVP, Diff-Serv requires no individual per-flow specifications and no signaling. Diff-Serv works by segmenting IP packets into a small number of forwarding “classes.” It uses the upper six bits in the type-of-service byte in the IP header of each packet, plus two bits currently unused, to classify priority via “code points.” These code points, the so-called Differentiated Services code points (DSCP), create a class-of-service (CoS) system that eliminates scalability limitations, complex policy statements and management problems of other QoS standards.

Each DSCP code point value is mapped to a defined per-hop-behavior (PHB) identification code. PHBs specify the packet-forwarding priorities in routers or other network devices. These standard PHBs are:

  • Expedited forwarding, delivering the highest QoS level, is assigned one code point defining minimized delay and jitter.
  • Assured forwarding comprises four classes and three drop-precedences within each class (for a total of 12 code points), each defining a different “drop priority” for dropping a packet during congestion periods. The higher the drop priority, the sooner they are dropped. For example, video packets are likely to have higher drop priorities than voice packets because video frames are permanently repeated.
  • The default, or “best effort,” PHB is assigned a code point 000000, but other code points can be mapped to this setting.

The Diff-Serv standard is somewhat underspecified: It allows many possible implementations of assured forwarding and lacks a definition for how the service guarantee for expedited forwarding is achieved. As a result, instead of a standard method for forwarding packets, multiple algorithms exist, including priority queuing, weighted fair queuing and weighted random early detection.

End-to-end QoS requires that any packet-forwarding device supports Diff-Serv. Virtually all new routers are Diff-Serv-enabled and have dedicated traffic-management appliances. Also, end systems such as telephones or Windows clients and servers can mark the traffic by entering DSCP values. (Note that LAN devices must support both Layer 2 prioritization [like IEEE 802.1D/Q] and Layer 3 prioritization [Diff-Serv].)

Today, Diff-Serv is the most widely accepted QoS mechanism in enterprise networks. It has proven to be scalable, is supported by many devices and represents a well-balanced compromise between QoS effort and results. A best practice QoS solution for multisite networks combines traffic marking in end systems, moderate overprovisioning and Diff-Serv in the LANs, plus focusing on managing the traffic, based partially on DSCP marking, at converged WAN links between sites. These are usually the most critical segments of enterprise networks.

Although Diff-Serv is not a complete answer to all QoS issues, it is a critical step in achieving this long-term objective. By letting companies segment traffic by media type (voice, video), data type or even application (enterprise resource planning, accounting, and the like.), Diff-Serv opens the door to enterprisewide QoS.

Pawlita is director of IP strategy at Siemens ICN. He can be reached at Peter.Pawlita@icn.siemens.de.