IP Quality of Service

Not long ago, IP was used primarily in Unix environments or for connecting to the Internet; other protocols, like SNA and IPX were used for other purposes. Now, however, many companies have begun using IP for everythingfrom sharing information within the company to running voice and other real-time applications across their global enterprise networks.

The rise of IP as a foundation for a universal network raises several issues for both enterprise IT departments and ISPs, not the least of which is how to guarantee that applications will receive the service levels they require to perform adequately across the network. For example, network managers might need a way to define a low level of latency and packet loss to ensure that a large file or a business-critical traffic flow gets to its destination on time and without delay. Or, they may need to ensure that a real-time session such as voice or video over IP doesn't look choppy or out of sequence.

The problem with IP is that, like Ethernet, it is a connectionless technology and does not guarantee bandwidth. Specifically , the protocol will not, in itself, differentiate network traffic based on the type of flow to ensure that the proper amount of bandwidth and prioritization level are defined for a particular type of application. By contrast, the cell -based ATM standard incorporates such service requirements in its specifications.

Because IP does not inherently support the preferential treatment of data traffic, it's up to network managers and service providers to make their network components aware of applications and their various performance requirements.

The QoS Dilemma

Quality of Service (QoS) generally encompasses bandwidth allocation, prioritization, and control over network latency for network applications. There are several ways to ensure QoS, no matter what type of network you're talking aboutEthernet or ATM, IP or IPX. The easiest one is simply to throw bandwidth at the problem until service quality becomes acceptable. This approach might involve upgrading the backbone to a high-speed technology such as Gigabit Ethernet or 622Mbit/sec ATM. If you have fairly light traffic in general, more bandwidth may be all you need to ensure that applications receive the high priority and low latency they require.

However, this simplistic strategy collapses if a network is even moderately busy. In a complex environmentone that has a lot of data packets moving in many paths throughout the network, or that has a mixture of data and real-time applicationsyou could run into bottlenecks and congestion.

Also, simply adding bandwidth doesn't address the need to distinguish high-priority traffic flows from lower-priority ones. In other words, all traffic is treated the same. In the network realm, such egalitarianism is not good, because network traffic is, by its nature, unpredictable. For instance, on some days, you'll see traffic bursts occurring at 8 a.m., while on other days you'll see them at noon or at the end of the day. These traffic bursts can move around too. One day, your Internet gateway or one of your switches is the bottleneck; another day, it's your intra-campus video conferences or heavy voice traffic causing the congestion.

As you can see, additional bandwidth can solve some of your short- term problems, but it's not a viable long-term solution, particularly if you already have enough bandwidth to accommodate all but the most highly sensitive network applications.

So how can you flag special traffic as high priority on an IP network? Options like Resource Reservation Protocol (RSVP), multiple flows, and tagging fields can help you give sensitive applications the resources they need.

Make A Reservation

RSVP, which enables non-QoS technologies such as Ethernet and IP to make QoS requests of the network, is an IETF Internet-Draft that has received a lot of attention. Specifically, the protocol lets end stations request specific QoS levels for QoS-enabled applications. For example, for a video conferencing application, a request could include information that defines the maximum frame transmission rate, the maximum frame jitter, and the maximum end-to-end delay.

When an end station makes an RSVP request for an application, each router situated between it and the source makes note of the QoS request and attempts to honor it. As the request travels through the routers to the source, it merges with requests from other end stations (see Figure 1). If a router can't comply with the requestthat is, if it can't guarantee the bandwidth or performancethe requesting station receives an error message, the equivalent of a busy signal on the voice network.

Figure 1: End- user stations send RSVP requests on behalf of an application. These requests go through each RSVP-enabled router up to the source. A router that can't honor the request sends an error message to the end user.

As you can see from all of these conditional statements, nothing is absolutely guaranteed with IP-based networks, even with an additional protocol like RSVP. For example, if a router refuses an RSVP request because it has already allocated its RSVP bandwidth, the packets associated with the request get dumped.

Another potential downside of RSVP is cost. Because the protocol requires each router to understand and support QoS requests, you might have to invest in firmware or even hardware upgrades to enable it.

RSVP could also lead to a perceived degradation of some network services. In a non-RSVP network, an application might run slowly or badly but at least it'll run. In an RSVP network, the application might not run at all if there's not enough bandwidth to support it. Similarly, if high-priority requests consume all the allotted bandwidth, a router could dump nonprioritized flows. If you end up with an "arms race," where many nonbandwidth-sensitive applications claim to be high priority anyway, you'll see no real benefits.

Another potential caveat is that routing protocols such as OSPF and Border Gateway Protocol (BGP) do not currently support RSVPand, ideally , they should, because a QoS request is actually made after a route is chosen for a particular data flow. It would be far better for an RSVP priority level to be taken into account before a route was chosen. Once the IETF's QoS Routing Working Group finishes its Internet-Draft for RSVP, it will begin working with the Working Groups for OSPF and BGP to integrate the routing protocols with RSVP.

Another criticism of RSVP is its inability to scale. Some industry watchers have warned that the protocol might not be suitable for large enterprise networks, specifically because each and every router along a particular path must support it. Given that requirement, using RSVP successfully over the public Internet could prove challenging.

Another router-based method for handling QoS requests is multiple queues. Routers that support this scheme identify flows that are tagged as high priority and move them to fast queues to expedite transmission.

Along these lines, the IETF's Integrated Services Working Group is debating how to use the 8-bit Type of Service (ToS) field in an IP packet header to tag traffic with different service levels. Currently, this field prioritizes traffic according to which end station initiated the flow, rather than the type of flow itself. If used in this new way, the TOS field would tell network devices that certain types of packets should receive a certain level of service. [Editor's note: Ultimately the Differentiated Services (diffserv) Working Group elaborated new standards for the TOS field (now renamed the differentiated services or DS field) in RFC2474 and RFC2475.]

Policy Makers

RSVP, multiple queues, and tagging can be valuable prioritization methods , but they aren't the only ways to address QoS.

A fairly new idea in the QoS realm is to make the network itself more intelligent by incorporating something called policy-based management. With this method, network managers could define policies that spelled out what levels of service certain types of traffic should have and what particular routing paths they should use. For example, with voice traffic, a path with a minimal number of hops would reduce delay and maintain the highest possible quality.

Policy-based management systems, which major networking vendors are starting to support, give IT managers and service providers a way to take a predefined policy and apply it across the board, rather than have to configure each network device with QoS support.

The Directory-Enabled Networks (DEN) initiative, which was launched in September 1997, is an interesting concept along these lines. Initially endorsed by Microsoft and Cisco, DEN allows network managers and service providers to create policy-based rules so that they can provide services based on users and applications. With DEN, directory services and networks are integrated, which means that network elements and services are represented in a directory. This scheme allows a centralized policy for network services to be associated with particular end-user stations and applications.

Because network devices and services are integrated with a directory, the network can be customized to provide a predictable level of service for users no matter where they are. For example, you might approve certain users for video conferencing applications, regardless of whether they log in to the network from their desktop or from a conference room with video conferencing equipment.

Not Out Of Reach

Although many of the QoS standards and protocols mentioned here are still in their infancy and not yet widely deployed, the growing need for QoS in IP-based networks will soon drive them to the top of any IT manager's or service provider's to-do list.

In corporate intranets or extranets, where all routers are typically part of a particular enterprise and therefore subject to the same policies, methods such as RSVP and policy-based networking shouldn't be difficult to use. The public Internet is another story, because you have no idea which routers are out there and whether or not they will honor QoS requests.

The IETF hopes to change that with IPv6, the next version of IP, which includes inherent provisions for QoS. For instance, IPv6 will allow applications to request different levels of service, and will guarantee these service levels even when a request goes over the WAN.

This inherent QoS will be a big boost for real-time applications such as voice and video. Currently, the only viable way you can ensure a specific QoS without adding on support for other protocols is through the use of ATM's User-to-Network (UNI) signaling and Private Network-to-Network Interface (PNNI) routing mechanisms. UNI allows sending and receiving stations and the network to work together to ensure that a particular traffic flow gets the QoS it needs. PNNI selects the most appropriate route through the network for traffic.

IP's Bright Future

As you can see, IP quality of service isn't quite the oxymoron it once was. By tweaking your existing routers, applications, and other network components, you can ensure that users and applications will have the bandwidth guarantees and low latency they requireall while reaping the management and cost benefits that IP offers.

Resources

For information on the IETF Working Group addressing RSVP and an index to the Internet Drafts, go to www.ietf.org/html. charters /rsvp-charter.html

For several informative reports on policy management and quality of service, go to The Burton Group's Web site www.tbg.com

To learn more about the directory-enabled network initiative, go to www.cisco.com/warp/public/734/den

This tutorial, number 119, by Anita Karv, was originally published in the June 1998 issue of Network Magazine.