Your customer using a legacy phone system decides to switch to voice over internet protocol (VoIP). They install an IP PBX and buy some IP phones. Great, they’re all set, right? Wrong. Without configuring their data network for quality of service (QoS), they will experience a severe deterioration in voice quality and may regret making the decision to switch. Yes, the IP PBX and the IP endpoints will already be configured for QoS. But what about other parts of the network like the pre-existing routers, switches and firewall? All it takes is one missing link for the whole system to be compromised.
QoS is a big topic. In this article, we’ll look at two main approaches to QoS: IntServ and DiffServ, their strengths and limitations, and when to use which one.
A note on QoS
QoS is a discipline of networking devoted to the development and implementation of technologies allowing for the prioritization and specialized treatment of particular types of data transmitted over IP networks. QoS is not only applicable for voice services, but also for other time-sensitive categories of data, such as video, financial transactions, and network control data, to name a few. For this reason, there are several methods by which QoS can be applied based on the requirements of each application running on the network.
The two principle approaches to applying QoS mechanisms are Integrated Services (IntServ) and Differentiated Services (DiffServ).
IntServ
The IntServ approach involves the reservation of bandwidth on the network from end to end between two communicating devices, before communication begins. This is achieved using the Resource Reservation Protocol (RSVP). When a device such as an IP phone initiates communication, it requests the reservation of network resources, namely bandwidth, from the routers along the path to the intended destination. Once the reservation is acquired, the communication takes place. When completed, the network resources are relinquished to be used by other applications and services.
While IntServ is effective, it has some drawbacks. All routers within a network must be configured to support and respond to RSVP requests. If only one fails, the reservation will fail. Additionally, there may potentially be hundreds or even thousands of individual reservation requests for routers to create, maintain and tear down reservations on demand, a process that can quickly overwhelm the CPU and memory of the RSVP-enabled routers.
Even so, RSVP is still utilized for VoIP implementations, and is especially useful when employed in multisite telephony deployments. Such deployments rely on the often-limited and easily overwhelmed bandwidth made available on WAN links, which are frequently shared with other packetized data. Because RSVP will reserve the bandwidth from end to end, no other service can use that bandwidth, even under conditions of extreme congestion. DiffServ, on the other hand, will eventually fail beyond a certain level of severe congestion. This level of congestion should not be experienced in a properly designed LAN, but may be encountered on limited and shared WAN links.
For virtually every other type of deployment, DiffServ is the preferred approach, because it offers a more scalable and flexible implementation of QoS.
DiffServ
DiffServ is a QoS approach involving packet prioritization. With DiffServ, individual packets are marked according to the type of prioritization they require. Routers and switches use various queueing strategies to conform to these requirements.
How packets are prioritized in DiffServ
Each IP packet is composed of two sections: the header and the payload. The payload is the actual data being transported to the destination. In the case of voice, the payload contains a digitized sample of a human voice.
The header is a construct that is added to the payload containing various fields with vital information, such as the source and destination IP addresses, that allows routers to direct the packet to its final destination. To use a postal metaphor, the header can be considered as the envelope in which the payload is placed that has the sender’s and recipient’s addresses written on it, so the postal service knows where to send it. Within the header, there is an additional field called the Differentiated Services (DS) field, which, if we continue the metaphor, contains information akin to the classification of postal mail as air mail or bulk.
The DS field, in turn, contains what is called a Differentiated Service Code Point (DSCP) value. This value, sometimes called a marking (hence the term “marked” packet), is composed of a six-bit code. Six bits allows for 26 or 64 different values of DSCPs, which provides a high level of granularity in the QoS classification of packets. (Note: In older versions of IP, the DS field was referred to as the Type of Service (ToS) field, and some texts and professionals may still refer to it this way.)
When DSCP has a value of 0, routers treat the packet using what is called a “best effort” priority, which is a nice way of saying no priority at all. Needless to say, higher priorities get preferential treatment and get processed first.
When a packet is sent from a VoIP source such as an IP telephone, it populates the fields of the header with appropriate information, such as the source and destination IP addresses. In addition, it can mark the packet with a DSCP value in the DS field that indicates a high priority.
When a packet arrives at a router on the way to its destination, the router must transmit it to the next router along the path. To do so, it reads the destination address in the header to determine where it should be sent. At the same time, it reads the DSCP value to ascertain if the packet requires special prioritized treatment. If it does, it moves it up in the queue to be sent before any lower-priority data.
DSCP values are read and priority is evaluated at each router along the path. So, unlike IntServ, with Diffserv no specialized protocols or any end-to-end network preparation is needed for QoS to function. This is a more efficient, scalable, and simple approach compared with IntServ, and is especially useful for voice.
Don't forget the switches
DSCP values are assigned in the IP header, which is at Layer 3 of the OSI model. This works fine for routers, but switches employing Ethernet technology function at Layer 2 and therefore cannot read the Layer-3 IP header like routers can. Nonetheless, switches must also be able to apply QoS mechanisms to ensure the proper prioritization of voice.
Typically, an IP phone is connected to a switch, which in turn connects to a router and then to the rest of the network. Switches are shared with other network devices that may be using extensive bandwidth and causing network congestion on the switch itself. No amount of QoS mechanisms on the routers can remedy such a situation.
For this reason, a similar classification system is used at Layer 2 of the OSI model. Just like a Layer-3 IP packet has a header and a payload, so does a Layer-2 Ethernet frame. In this case, the payload of the frame is the IP packet itself. The frame header contains a field called the 802.1Q VLAN Tag. This field, in turn, encloses a three-bit Class of Service (CoS) identifier that is used in a similar manner as DSCP values for Layer 3. With three bits, the CoS can define up to 23 or eight CoS levels; not as detailed as DSCP values, but sufficient for implementation within the scope of a single switch.
When a router sends packets that are marked with non-zero DSCP values, these must be mapped or translated to a corresponding CoS value and used at Layer 2 by the switch to appropriately apply QoS. This is done by the router before it hands off the packet/frame to the switch. The switch can then prioritize the traffic based on the CoS value.
Keep in mind that CoS values only exist in frames where the 802.1Q VLAN tag is used. This tag is only present within the headers of frames traversing trunk links – that is, links carrying more than one VLAN. In other words, CoS values are only needed when multiple traffic types are vying for the same network bandwidth. It makes sense that if there is no competition for bandwidth, QoS is not an issue, because the voice packets can proceed unobstructed.
Conclusion
QoS is an often-overlooked aspect of Voice over IP. Many enterprises attempt to implement VoIP on a data network that has been functioning flawlessly for years, only to realize that it cannot support VoIP as-is. Understanding QoS functionality is vital for successfully adapting the infrastructure for a converged network, and for reaping all of its rewards and benefits.
You may also like:
Customizing a VoIP deployment for your multisite customer
Migrate your legacy customers to VoIP this year
A simple process for transitioning to VoIP
Add a Comment: