QoS Through the Network

Gilbert Held

This article is the fifth and final article of a series focused on the various pieces of communications technology that can be used to obtain a Quality of Service (QoS) capability. The previous article discussed the Type of Service (ToS) byte in the IP header and showed how the ToS byte can be used to provide differentiated service (DiffServ) information to routers. (See the sidebar "The Story thus Far" for more background.) In this article, I will point out some of the limitations of DiffServ and then examine an alternative approach to QoS based on Integrated Services and the use of RSVP. I will briefly describe and discuss a few techniques that can facilitate obtaining a QoS capability under different networking environments. There are many aspects associated with QoS that make network managers and LAN administrators yearn for the good old days when the use of 64-Kbps time slots was the only way to obtain a Quality of Service. Fortunately, the ability to support a much higher level of traffic through the use of packet networks compensates for the effort involved in effecting a QoS capability.

Return to DiffServ

In the previous article, I noted that this traffic expediting technique divides transmission into a small number of classes. Routers then apply a standardized set of behaviors to each class of traffic, which is referred to as a per hop behavior. Because DiffServ-aware routers perform their operation without the need to know the path of traffic or information about other routers in the network, the technology avoids the need for conveying signaling information other than the bit composition of the revised ToS byte. While this is a key advantage of DiffServ, it also results in the need to carefully consider, as well as control, the arrival rate of one or more types of traffic classes. For example, consider the use of expedited forwarding (EF), which represents a simple per hop behavior that informs routers that packets marked for EF status should be forwarded with minimal delay and loss. The only way that a network operator can guarantee minimal delay and loss to all packets marked for expedited forwarding is to limit the arrival rate of such packets to less than the rate at which routers can forward them. Although this task may appear simple, in actuality, this method of flow control can be quite complex as shown in Figure 1.

In examining Figure 1, let's assume routers 1 and 2 are connected via a T1 circuit in the middle of a network, while router 1 has connections via circuits labeled A, B, and C to three other devices. This means that the network operator must limit the aggregate arrival rate of EF packets via circuits A, B, and C destined to router 2 via router 1 to less than 1.544 Mbps. In actuality, the network operator must also consider other traffic classes and control the aggregate arrival rate of EF-marked packets to a rate significantly under 1.544 Mbps to enable router 1 to transfer other traffic to router 2. Because routers connected to circuits A, B, and C may have one or more inputs that will flow from router 1 to router 2, EF-marked packets at another hierarchy in the network must also be considered. As a network increases in complexity, it becomes harder for the network operator to configure devices at the edge of the network to mark packets that allow routers to guarantee a consistent handling of the packets. For this reason, an alternate approach to provide a QoS capability through a network may be desirable. One such method is based upon what is referred to as Integrated Services (IntServ).

Integrated Services

Integrated Services refer to a suite of evolving standards intended to provide a QoS transport capability over IP-based networks. IntServ dates to the work of the IEFT during the mid-1990s and is defined in RFC 1633.

The basic design issue covered by IntServ concerns sharing available bandwidth during times of congestion. Under IntServ, congestion management consists of the following:

• Admission control, which is invoked by a reservation protocol to determine whether resources are available for the flow at the requested QoS
• A routing algorithm, which maintains a routing database that provides next hop information for each destination address
• A queuing algorithm, which controls the flow of traffic through a router
• A discard policy, which provides a uniform mechanism that denotes the conditions under which packets are sent to the great bit bucket in the sky

Although IntServ includes an admission control function, it does not define the method of control to be used. However, when discussing admission control, many people incorrectly associate the ReSerVation Protocol (RSVP) as part of IntServ. In actuality, RSVP can be used under IntServ but is not a required member of the architecture. Because RSVP is currently the only mechanism that can be employed to deliver guaranteed bandwidth within an IP network, I will describe the basics of this signaling protocol.

RSVP

RSVP is a signaling protocol that enables applications to request guaranteed bandwidth from a network. In doing so, RSVP provides an admission control capability on an end-to-end basis, since the availability of required bandwidth determines whether the application gains access to the network.

Unlike most protocols that are sender driven, RSVP is receiver driven. The rationale for this change is based upon the need to accommodate different members of a multicast group that can have different resource requirements. For example, one member of a multicast group could be connected to an IP network via a 56-Kbps digital circuit, while a second member is connected via a corporate LAN using a T1 line operating at 1.544 Mbps. Under RSVP, a sender will transmit a Path message downstream toward all receivers. The Path message includes information on the traffic characteristics of the data stream that will be generated. Each receiver requests a specific QoS from the network by responding to the Path message with a reservation (Resv) message. As a Resv message flows toward the originator, each router in the path checks to determine whether sufficient resources are available. If so, a reservation is established, and the Resv message is forwarded to the next upstream router. Otherwise, the reservation fails, and an error message is returned to the receiver.

To reduce signaling requirements, a sequence of packets from a common address with a common destination are treated as a flow specification (flowspec). The flowspec describes the service requirements in terms of a desired QoS or reservation request and can include information such as a service class defined by the application and a reservation specification (Rspec) that defines the bandwidth required.

Each RSVP-compliant router includes a packet classifier and packet scheduler. The classifier determines the route of the packet, while the scheduler is responsible for servicing and forwarding decisions required to achieve the requested QoS.

Another integral part of each RSVP-compliant router is a filter specification (filterspec). The filterspec specifies the packets that will be serviced and the manner in which they will be serviced based upon the flowspec. An example of the relationship between the filterspec and flowspec is shown in Figure 2. Note that the packet classifier aggregates a series of packets that flow to a common destination. The filterspec specifies packets that will be serviced by the flowspec, while the flowspec parameters are used by the router to place packets into applicable QoS-delivery queues.

Both Resv and Path messages have timeout values that are used by routers and switches to set their internal timers. If those timers expire, the reservation and routing information associated with the reservation are turned down. This limits the seizure of resources by the failure of a receiver to terminate an RSVP session.

Although RSVP is several years young, its implementation is commonly restricted to small intranets. The reasons for its limited use are primarily the signaling overhead associated with the protocol, the need for all routers in a network to be RSVP compliant, and the inability to negotiate the cost of bandwidth when a QoS traffic flow crosses an ISP boundary. Concerning the latter, the simplicity of allocating bandwidth to an application does not mean that it is easy to bill for the bandwidth. This is because allocated bandwidth can be temporarily deallocated when the application is quiescent, permitting a router to use previously allocated bandwidth until the application needs it. Thus, an interesting issue is how, for example, would one ISP bill another for an application that required 8 Kbps of bandwidth that was available for use by the host ISP 60 percent of the time? While billing issues between ISPs may take a while to resolve, many carriers are taking another look at RSVP for internal use to include its proposed extension to support label distribution and explicit routing. This issue requires knowledge of label distribution, so I'll address this topic with the help of Internet draft documents that describe multiprotocol label switching (MPLS). (For further discussion of RSVP, see Ron McCarty's article in this issue.)

MPLS

Multiprotocol Label Switching (MPLS) represents a switching architecture where packets entering a network are assigned a label. Then, instead of forwarding packets based upon searching their routing table, a router uses the label as a forwarding criteria. Because there can be tens of thousands of entries in a routing table (while label entries are associated with device interfaces), it is much faster for the router to make forwarding decisions based upon the contents of the label.

The original goal of MPLS was to provide the efficiency of Layer 2 switching to Layer 3 networking. Although the manufacture of application-specific, integrated circuit (ASIC)-based routers permits relatively fast router table lookup operations, that negates the original goal of MPLS, there are other benefits associated with label switching. Those benefits include the ability to define paths for different types of traffic through a network (i.e., traffic engineering) and the creation of IP tunnels through a network facilitating the creation of virtual private networks (VPNs).

The MPLS Label

The MPLS label is 32 bits in length and consists of four fields as indicated below:

|-20 bits Label-|-3 bits CoS-|-1 bit stack-|-8 bits TTL-|

The fourth field, time to live (TTL), consists of eight bits that provide the functionality of the conventional IP TTL field in the MPLS header. That is, it prevents a labeled packet from endlessly wandering through a network. The MPLS label is inserted after the Layer 2 header, preceding the IP header. The specific path through an MPLS network is referred to as a label switch path (LSP). The LSP is provisioned via the use of a label distribution protocol (LDP), which both establishes a path through an MPLS network and reserves resources to satisfy the predefined service requirements for the data path. One pending LDP is the previously mentioned extension to RSVP to support label distribution and explicit routing referred to as RSVP-TE.

While one group of vendors (including Cisco and Juniper Networks) supports the extension of RSVP, a second group of vendors (including GDC and Nortel) are backing a second signaling mechanism referred to as CR-LDP. Although both proposed signaling protocols have many similarities, they are not interoperable, and the IETF's MPLS working group has its work cut out in attempting to select one. The MPLS Resource Center (www.mplsrc.com) functions as a clearinghouse for information on the IETF's MPLS Standard. There, you can determine whether a selection between the two signaling protocols was made, as well as access a wealth of MPLS-related information. Please refer to Ron McCarty's two-part series on MPLS (Sys Admin Vol 9, Issue 5 and 6) and Randy Zhang's article in Sys Admin Vol 9, Issue 12 for further discussion of MPLS.

Other QoS Techniques

Although DiffServ, MPLS, and other techniques represent traffic-expediting methods, there are other techniques end users can employ that also affect QoS. Those techniques are generally classified as efficiency methods that facilitate data flow through a network. An example of an efficiency method is the use of Real-Time Transport Protocol (RTP) header compression.

RTP adds time stamping and data sequencing information to a packet. In a voice over IP environment, an RTP header consisting of 12 bytes is used behind an 8-byte UDP header. The RTP and UDP headers are in turn prefixed with a 20-byte IP header. If RTP is employed with an 8-Kbps voice digitization method that results in 20-ms portions of speech being encoded, then the payload of the UDP segment will be 160 bits or 20 bytes. This means that the total length of the IP datagram conveying the digitized voice sample is 60 bytes, of which only 20 bytes represent the actual payload. Through the use of RTP header compression, it becomes possible to reduce the IP/RTP/UDP header from 40 bytes to 2-5 bytes, with the actual reduction dependent upon the susceptibility of the header's contents to compression. RTP compression is currently defined in the IETF draft Compressed RTP (CRTP).

Several vendors, including Cisco Systems, have implemented RTP header compression to enhance communications on serial lines using Frame Relay, HDLC, Point-to-Point Protocol (PPP) encapsulation, or via an ISDN interface. Note that there is a relationship between router processing time to perform header compression and the speed at which compressed data is provided to a router's interface. In general, the higher the data rate, the higher the processing time. Thus, RTP header compression is commonly recommended for use on slower links operating up to 512 Kbps where RTP header compression can reduce overhead.

Another QoS technique that can be protocol independent is setting router queues to prioritize traffic based on packet length. Because digitized voice and interactive queries are typically transported in relatively short packets, it becomes possible to favor such applications over traffic transported in long frames, such as Web pages and graphics.

Focusing on a particular communications transport protocol may provide control over one or more transmission parameters in conjunction with a service level agreement (SLA) initiated with a carrier. For example, in Frame Relay networking, you can use an SLA governing the delivery rate of frames with or without their discard eligibility (DE) bit set along with a maximum latency time to provide a QoS capability to traffic.

As I've noted in this series, there are many parts of this puzzle. Unlike when the telephone company provided QoS in the form of reserved 64-Kbps time slots, the ability to provide QoS to packet networks is significantly more complex. However, the fact that packet networks dynamically allocate bandwidth makes their transport efficiency much greater than the use of reserved time slots, resulting in an economic reward for our efforts. Although it may be quite some time until all the pieces of the QoS puzzle come together in an orderly and manageable manner, it doesn't take an expert to note the future.

With communications carriers installing tens of thousands of fiber miles each year, while the migration from single channel to wavelength division multiplexing (WDM) and dense WDM (DWDM) continues to add significant networking bandwidth, it is quite possible that another approach to QoS will evolve. That approach is for carriers to provide sufficient bandwidth to overcome any potential bottlenecks. As we plan for the vast migration onto packet networks, we need to periodically check the progress of standards, examine SLA offerings, and be aware of the techniques used to expedite traffic through our networks. Who said the life of a network manager or LAN administrator is boring?

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, Cisco Router Performance Field Guide, and Cisco Access List Field Guide (co-authored with Kent Hundley), all published by McGraw Hill Book Company. Gil can be reached via email at: gil_held@yahoo.com.