Applying class of service in converged VoIP networks

Traditional voice networks that use dedicated circuits and TDM virtual circuit paths have evolved over the last century to allow an outstanding degree of voice quality. They obtain this result by using tools and techniques completely different from those used on the Internet and other connectionless networks. Yet despite this inherent unsuitability, Internet protocol networks have proved an irresistible target for voice network designers as they seek to gain the advantages in efficiency, scalability and integration that converged networks offer. Using the class-of-service capabilities of modern routers, voice can be combined with best-effort data to form compelling residential or business service offerings.

The challenges of carrying voice traffic over connectionless datagram networks are easily described but intractable, particularly in networks that also carry data traffic. The primary difficulties are related to three traffic parameters:

• Latency: the amount of time it takes for a transmitted packet to be received at the other end. Most people have a difficult time conducting a conversation when the end-to-end latency approaches a half-second

• Jitter: Also known as delay variation, jitter is a measure of changes in latency over a period of time, such as the life of a phone call. Ideally, whatever latency exists should stay as constant as possible during a call

• Loss: Loss is simply a measure of the percentage of packets that are transmitted but never received. The human brain is able to tolerate a surprising amount of loss during a conversation, but smaller amounts of loss improve quality. And when modems or fax machines are using the voice channel, they demand little or no loss.

The primary mechanisms used by network designers to guarantee acceptable values of these parameters are packet handling and transmission options available within the routers in the converged network. These options become VoIP service enablers in the context of converged networks, because without them a voice service would not be possible. The effective design and use of packet handling capability can make the difference between a VoIP service that is indistinguishable from a traditional telephony offering and one that is of such poor quality that it cannot be used. Even more importantly, the efficient and balanced use of network resources that flexible packet handling allows is essential to a profitable multiservice network, where voice and other types of traffic each provide a revenue source while using the same network infrastructure to control costs.

What is IP CoS?

While there is a great deal of rather academic debate about the correct name for it, IP class-of-service (CoS) capability is the most commonly employed name for the network's ability to discriminate between the needs of different applications, and treat each differently. CoS is really nothing more than the preferential treatment of packets with certain characteristics. For example, a converged network should ensure that voice packets are handled in such a way as to guarantee that they will reach their destination with allowable amounts of latency, jitter and loss. Of course, to do this, the network may have to delay or even discard non-voice traffic--a condition that, while not desirable, is nevertheless better than lowering the quality of a voice call below acceptable levels.

There are a number of components of any CoS model, but a simple and voice-specific example might encompass the following functions:

1. Classification differentiates voice traffic from data traffic.

2. Queuing defines separate voice and data buffers in memory.

3. Scheduling refers to the scheme used for emptying the queues, allowing prioritized transmission, performing congestion control and other functions such as traffic shaping.

4. Policy actions such as filtering, policing, rate limiting, marking, logging, policy routing and other actions that allow the user to customize their control of a particular traffic class.

It's worth taking a moment to consider each of these CoS components in more detail:

Classification

In order to treat each type of traffic according to its requirements for a successful service offering, one must first be able to differentiate between and identify traffic types. In the connectionless world, this usually necessitates looking at each packet and assigning to it a class of service based on some explicit or implicit data in the header. For example, explicit CoS information may be carried in the TOS byte (also known as the diffserv byte) of the IP header, or in the EXP field of an MPLS header.

For a packet to elicit a particular CoS from a network of routers in this manner, however, it must be marked when it arrives at the edge of the network, and issues around this marking are surprisingly complicated. There are differences in the ways that VoIP gateways and softswitches assign TOS or diffserv codes to voice traffic--in fact, some cannot explicitly mark traffic at all. There are also disagreements between vendors and implementers about what codes specific types of traffic should bear. This had led some router vendors to build into their products a multiservice classification capability, which allows a router to look at any field in any header of a packet, and thereby use implicit information to assign the desired class of service. For example, a router might be configured to look for IP packets that bear an RTP (the real-time transport protocol, used in some architectures to carry voice traffic) header, and assign to them a CoS.

Queueing

Once packets have been classified and any policy actions applied, it's necessary to buffer them for some small amount of time as they await transmission according to the model in effect for their class. Queuing only matters during periods of transient congestion, so packets shouldn't have to wait in a queue if the network is provisioned properly. (It's also worth remembering that the process of queuing a packet does not effect forwarding performance unless there are other packets ahead of it. Each class of service usually needs its own buffer space for queuing, and the amount of space required is a function of the speed with which traffic enters and exits the queue and the maximum time that a packet should be allowed to await transmission. In the case of VoIP and other real-time services, buffer memory can be comparatively small, because voice traffic that is queued for too long will be useless to the receiving gateway, and therefore be ignored. It is therefore no great loss for the occasional packet to be lost because of insufficient queue memory.

Scheduling

Perhaps the most complex part of a CoS model is deciding exactly how often to transmit packets of various classes so that each service is given the traffic characteristics it needs, without impinging too much on other services. The simplest type of scheduling is FIFO (first-in, first-out), which is exactly that--packets are transmitted in the order they arrive. While attractive from an implementation point of view, such a simple approach carries with it a number of problems. Even for simple converged voice and data networks, flows of relatively small voice packets spaced evenly in time will experience increased latency, jitter, and loss as they are forced to "line up" behind larger, variable-sized data packets in router after router. It makes much more sense to segregate voice and data packets into their own buffers and service each buffer in accordance with the needs of the traffic. There are many ways of scheduling the servicing of multiple queues, each with its own benefits and compromises:

• Priority queuing allows each queue to be given a priority, and queues are serviced so that voice queues are always emptied before data queues. This is simple to implement and understand, but can result in long delays and excessive loss of data packets as they wait for the voice queues to empty. A variant of PQ called rate-controlled priority queuing allows engineers to configure a limit on how much bandwidth the voice queue can use, thereby keeping the data traffic from being completely starved.

• Fair queuing attempts to address the limitations of priority queuing by assigning each flow of voice or data its own queue, and servicing each queue in round-robin order. This provides a more consistent and predictable level of service to each queue, but places significant demands on router memory and processing power.

• Weighted fair queuing gives each queue a weight that corresponds to its required percentage of bandwidth and takes the length of packets into account when deciding whether to service a particular queue. This can help put a boundary on the delay that a particular service class will experience, but is complex to implement.

• Weighted round-robin queuing attempts to address the limitations of the above approaches by assuring appropriate treatment for flows with very different requirements. It accomplishes this by allowing a single queue to send more than a single packet each time it is serviced. Allowing this but still ensuring a degree of fairness for all queues is tricky, and there are a number of enhancements to and variants of the process.

These brief descriptions are far from comprehensive treatments of each queuing method--they are meant to illustrate the degree of complexity that can accompany discussions of the CoS requirements of a converged voice and data network. Rather than implementing a single model, vendors typically implement a hybrid scheduling model--often allowing the user to configure many of the parameters discussed above to customize the handling of particular types of traffic.

Policy actions

Finally, it is often necessary to be able to apply additional policy actions to individual flows, classes, or packets. One such example is TOS or CoS rewriting, where the router explicitly marks packets with some indication of the class of service they should be assigned as they are forwarded through the network. In other words, if multifield classification must be performed at the edge of the network, packets belonging to a particular class may be marked as such by setting the TOS or diffserv value of the packet as it is transmitted. This relieves subsequent routers from having to perform multifield classification, allowing them to simply note the explicit CoS and treat the packet accordingly. More importantly, it means that only the routers at the edge of the network need to be configured with the multifield classifier information, thus reducing an operational task.

Putting it all together

As one can see from the large number of options outlined above, there are as many ways of crafting a comprehensive CoS plan as there are networks. The trouble in choosing and implementing an approach to CoS for a given set of services lies not only in determining the needs of the services themselves and how they will interact on the network, but also in determining how to elicit the desired behavior from the routers and other devices that provide the infrastructure.

Given the complexity of some of the approaches to, for example, queue servicing, it's tempting to think of CoS as an extremely complex topic, the planning for and analysis of which will only respond to heavy mathematics. This is surely true in some examples of multidimensional multiservice networks that seek to integrate the transport of many types of real-time, near-real-time, and non-real-time traffic, but it is just as clearly not true for relatively straightforward mixes of voice and best-effort data. And while one can spend a lifetime studying queuing theory, servicing algorithms, and other elements of CoS functionality, the majority of providers' current converged voice and data CoS problems will yield surprisingly well to some simple common-sense planning, because they seek to fulfill relatively simple goals:

1. Keep the voice and data traffic from interfering with each other as much as possible.

2. Maintain voice quality, even at the expense of best-effort data traffic.

Translating these requirements into a reasonable router configuration, while certainly not trivial, need not be as achingly difficult as frequently portrayed. A simple approach to deploying a converged voice and best-effort data network can revolve around the refinement of a few basic premises:

• Classify once, at the edge. If the voice gateways or softswitches are capable of explicit marking of voice packets, thus relieving the core routers from multifield classification, that's even better.

• Forwarding performance makes up for a lot. Jitter is never good, but it's much more tolerable under conditions of low latency.

• When choosing a scheduling discipline, make sure that your router can handle the load. Some scheduling methods demand a significant amount of processing power, and some routers use non-optimal architectures to implement them. This can cause more trouble than it solves as the CoS mechanism actually adds delay and jitter to some traffic classes. A routing platform with a hardware-based scheduler will be able to implements effective CoS on even very high-speed interfaces.

• Simplicity is always good, particularly in CoS design. By starting with a simple design, you can introduce traffic and observe the results, using the feedback from real traffic to adjust traffic levels and relatively simple CoS parameters. Increase complexity only when there's no other way to achieve your goals.

The designers of the IP protocols never foresaw them being used for realtime services like voice, particularly when mixed in with other types of best-effort traffic. Luckily, though, the inherent adaptability of the protocols themselves, together with enhancements in router CoS capabilities, can result in a network environment that is up to the challenge. The trick with CoS, as with so many things, is to not let the technology take over, and lose sight of the goal in the process.

Matt Kolon is Senior Solutions Manager for Juniper Networks.

Visit Juniper Networks online.