The integration or convergence of voice, video, and data can provide a business with a competitive edge when effectively implemented. There are several business models and operating environments that present opportunities for strategic consideration when planning for this change. The key factors for success involve leveraging the integrated features to provide the greatest support for existing processes.
This chapter will look first at high-level business models and processes that are often impacted by service convergence. Later, the chapter will delve into the issues of call quality that affect every organization implementing an integrated service solution. Quality is often the single biggest factor in a successful implementation, so this chapter will explore a variety of approaches for delivering total quality network services, with a focus on integrated VoIP.
Business crosses a wide array of sectors, each having unique business requirements to support aspects of the core business. Call centers may play a central role for many businesses, particularly those in financial services, insurance, or travel. They also play a key role in many other sectors as smaller customer support teams. Interactive voice response (IVR) systems are frequently automated to reduce the requirement for staffing and provide information to customers. Computer telephony integration (CTI) isn't a new concept with the deployment of VoIP, but in many cases, it becomes easier. CTI may provide levels of service and application integration previously outside the financial grasp of some organizations.
In addition to the traditional sectors of business, the integration of the Internet has heightened awareness of four distinct business models in the Web-centric world of e-business. Some of these models fit with large enterprise; others are more amenable to small business and have been used by many an e-business startup company.
In the open market model, anyone can be a buyer, and anyone can be a seller. There's no centralized control, and minimal trust involved. There isn't particularly high value to integration of enterprise systems because relationships may be ephemeral. Market leadership for these ebusinesses requires being in the right place at the right time, with the right solution at the right price. OASIS and eBay are good examples of the open market business model.
The alliance model is more common in larger businesses. It embraces a distributed corporate environment with multiple leaders of the pack. The goal of these alliances is frequently optimization of specific solutions to solve identified customer problems. Alliances are often formed among the best and brightest in their respective fields. High levels of integration in services and applications between partners bring tremendous value to an alliance. Sun, IBM, Oracle, and Netscape demonstrate this model via the Java Alliance.
The aggregation model is typically adopted by the leader in a business sector. The aggregator positions itself between producers and consumers, providing access to products. Integration with consumers may be low, but integration with the producers and internally across the aggregator enterprise can add very high value. Wal-Mart represents a perfect example of this model.
The value chain model is adopted by most businesses. Every business is, in some facet, the leader of the pack in its' particular sector. Process optimization within the enterprise is crucial to business success. The leader focuses on optimizing the value chain through service and application integration rather than aggregating buyers and sellers. Cisco Systems, Dell, and Amazon represent value chain leaders in the world of e-business.
There is also an emerging competitive model, driven by competition between clusters, not individual companies. This model is often a matter of survival for businesses that need partnerships to deliver a complete solution set to market. In this model, companies maximize the user of distributors, resellers, and retail sales chains. Integration of services and applications may focus on facilitative technologies such as Web-based Electronic Data Interchange (EDI) to drive e-commerce online.
Business in the new economy of the Internet requires instantaneous reaction to customer behavior. Being nimble and responsive can provide a competitive edge in having the right solution for customers at the right time.
Examples of near-instantaneous change include Wal-Mart and K-Mart. Wal-Mart monitors computer inventories closely in stores. If a customer buys a package of tennis balls, the inventory and shipping systems are automatically updated to ship a replacement set to a specific store. If a store experiences a run on tennis balls, or an unusual trend exceeding normal thresholds for a product occurs, stores all across a geographic area may find they receive increased delivery of tennis balls to support the trend.
K-Mart takes a different approach, using outside data sources to drive product stocking. One of ten used example is their use of the National Weather Service (NWS). If K-Mart notes inclement weather headed for a particular part of the country, their stores may receive umbrellas and raincoats for stocking, in support of anticipated demand.
Businesses implement call centers to effectively administer incoming product support or provide information to customers. Call centers most often interact directly with consumers and are often the lifeline of the customer relationship. Outbound call centers are used for telemarketing, clientele management, and debt collection. The call center might also be a broader contact center, handling postal mail, fax communications, and email for an enterprise or business unit.
Call centers are generally built using large, open work spaces with workstations including computers, telephones with headsets, and supervisory stations. Some businesses build centralized call centers; others distribute call centers at diverse locations, connecting them with voice and data technology. Global companies may have call centers around the world, with each being the primary center as the time of day changes. Location, coupled with time, can provide the advantage of using resources during the local business day.
Call centers are linked to the corporate computer network, including mainframes, microcomputers, and LANs. Increasingly, the voice and data services are linked through CTI.
Most large enterprise businesses use call centers to interact with their customers. What has changed with the widespread deployment of VoIP is the barrier to entry. Now a midsized company can easily deploy a centralized or distributed call center, leveraging integrated technologies and bringing new services to customers that were previously out of reach.
Call center technology essentially provides a queuing network coupled with workforce planning and management to achieve desired service levels. A common example of call center service levels might require that at least 80 percent of the callers are answered within 20 seconds or no more that 3 percent of the customers hang up, due to their impatience, before being served. Call centers provide information about traffic patterns and business patterns as well. Statistics gathered can help determine whether a single large call center is more effective at providing customer service (answering calls) than several distributed, smaller ones might be.
Centralizing call management into a call center aims at improving business operations and reducing costs while providing a standardized, streamlined, uniform service for consumers. The efficiency of a repeatable process makes this approach ideal for large companies with extensive customer support needs.
Call centers use an array of voice and data technologies and provide a prime candidate for integrated services and applications. These technologies can ensure that customer service agents are kept as productive as possible and that calls are queued and processed as quickly as possible, producing the desired service levels for customers. Some of these technologies include:
Beyond the features and technologies, there is a standard suite of typical performance metrics used in the call center management methodology. When a company invests in a call center, it's crucial to monitor performance levels and ensure return on the investment. The most common metrics include:
The acceptance and widespread deployment of VoIP has enabled the staffing of call centers with remote agents. These agents work from home, often on flexible part-time schedules. In the past, they would use a basic-rate ISDN line, but widespread broadband deployments have made highspeed Internet access easy to couple with VPN and VoIP solutions to provide a fully integrated solution for teleworkers.
Clearly, the call center has been a key resource in large customer service organizations for many years. Today, the reduced barrier to entry in call centers has made the technology more available to a wide set of business environments.
IVR is a computerized system that allows a caller to choose options from a voice menu and otherwise interface with a computer system. Typically, the IVR system plays prerecorded voice prompts, and the caller responds by pressing numbers on the telephone keypad to select among the options. Many IVR solutions also allow the caller to speak simple answers such as yes, no, or numbers in response to the prompts. These systems have grown more sophisticated in the past few years, and do a much better job of recognizing human voice than they did when they first gained popularity.
Newer systems use natural language speech recognition to interpret the questions that the person wants answered. There is also a growing trend called guided speech IVR that integrates live human agents into the design and workflow of the application to help the speech recognition with human context.
Other innovations include the ability for the system to "read out" complex and dynamic information such as email messages, news reports, and weather information using Text-ToSpeech (TTS) conversion tools. TTS is computer-generated synthesized speech that has advanced well beyond the robotic voice people may associate with computerized systems of the past. Human voices are used to create the speech in very small fragments that are assembled to create very real-sounding responses before being played to the caller.
IVR systems are used to create service solutions such as airline ticket booking and banking by phone. Unlike voicemail systems, which are one-way communications, IVR systems provide some level of two-way information exchange between the caller and the company systems. An ACD group in a call center may be the customer's first point of contact. IVRs are often used to provide the primary front-end to a call center, automating the most common calls for account balances or other easily delivered information.
IVR systems today are built with scripting languages such as VoiceXML or Speech Application Language Tags (SALT), not unlike the way Web pages are constructed. In the case of an IVR, the Web server also acts as the application server, allowing the developer to focus on call flows rather than graphic presentation. Typically, Web developers understand and are familiar with tools in this environment and often don't require additional programming skills.
CTI provides for interaction between the telephone and computer systems. As technology has matured, CTI has expanded to include the integration of all customer contact channels, including voice, email, Web, and fax.
CTI evolved from relatively simple screen population (or screen pop) technology. This technique allows data collected from the telephone systems, most often via the touch pad, to be used as input data to query databases with customer information. That data can then be populated instantly to the customer service representative's screen. When the agent already has the required information on his or her terminal screen before speaking with the customer, overall transaction time is reduced.
This technology began in the closed, proprietary roots of every PBX/ACD vendor in the market space. Most vendors eventually adopted the Computer Supported Telecommunications Applications (CSTA) standard. CSTA originated in the ITU and was adopted as an OSI standard in 2000. Some other accepted service and application integration standards in CTI include:
Some commonly implemented functions in the CTI environment include:
CTI takes on two basic forms. The following excerpts from the Wikipedia online encyclopedia article about CTI provide helpful descriptions (Source: http://en.wikipedia.org/wiki/Computer_telephony_integration#Forms_of_CTI):
First party call control operates as if there is a direct connection between the user's computer and the phone set. An example of this would be a modem card in a desktop computer, or a phone plugged directly into the computer. Typically, only the computer associated with the phone can control it, by sending command directly to the phone. The computer can control all the functions of the phone, normally at the computer user's direction. First party call control is the easiest to implement but is not suited to large scale applications such as call centers.
Third-party call control is more difficult to implement and often requires a dedicated telephony server to interface between the telephone network and the computer network. Third party call control works by sending commands from a user's computer to a telephony server, which in turn controls the phone centrally. Specifically, the user's computer has no direct connection to the phone set, which is actually controlled by an external device. Information about a phone call can be displayed on the corresponding computer workstation's screen while instructions to control the phone can be sent from the computer to the telephone network. Any computer in the network has the potential to control any phone in the telephone system. The phone does not need to be attached directly to the user's computer, although it may physically be integrated into the computer (such as a VoIP soft phone), requiring only a microphone and headset in the circuit, without even a keypad, to connect to the telephone network.
Like many telecommunications technologies, CTI has made great advances over the past 10 years of evolution. The barrier to entry has lowered to a point that CTI is now available to small and midsized businesses and is widely adopted as a competitive tool to improve business processes.
As business advances, there has been enormous acceptance and adoption of an Enterprise Resource Planning (ERP)-driven, Web-centered collaboration in business-to-business (B2B) interaction. For many businesses, this is a competitive move. Companies around the world have focused on improving business processes for many years, spurred early on by W. Edwards Deming's Out of the Crisis and his 14 Points for Management.
Those works, and others, drove business to improve processes, but with advances during the same time period in IT, we've seen growth in the use of ERP systems across businesses of every size and shape, creating more integrated enterprises. Today, efficiency in process drives many organizations to focus on teamwork. ERP systems help dissolve the barriers that exist between different business units or departments. They help break down the silo effect so common in the past and change how people work together.
Web-centric business platforms and the success of e-commerce bring new levels of integration, allowing easier support for inter-organization business process integration between trading partners. ERP systems' goal is to integrate all data and process within an organization into a single unified system using computer hardware and software components. One key ingredient to most ERP systems is the use of a single, unified, master database to store data for all the disparate modules involved.
ERP originally implied a system for planning the use of resources across the enterprise, and although it originated in the manufacturing sector, today it is much broader in scope. Today's ERP systems strive to encompass all the basic functions of an organization regardless of the business. ERP systems have spread beyond manufacturing to business, non-profits, governmental organizations, and other large enterprises.
The term ERP system generally refers to an application that replaces two or more independent applications within an organization, eliminating the need for interfaces between systems. This approach provides benefits ranging from standardization and lower maintenance (a single system rather than multiple systems) to improved, dynamic reporting capabilities and enables managers to better monitor the business.
Some examples of different modules that might be available in an ERP system include:
Each of these discrete application modules support processes require both voice and data communications. Integrating voice services into a CRM module provides a unified customer database, easing customer contact to build relationships. Supply chain modules can build tighter communications processes with vendor partners. Manufacturing and warehouse communications integration can speed time to market. ERP represents the nervous system of an organization and provides an integration point that can tightly couple business process with communications tools to increase productivity and enhance efficiency.
CRM encompasses a broad set of capabilities, methodologies, and technologies that support an enterprise in managing customer relationships. The general purpose of CRM is to enable organizations to better manage their customers through the introduction of reliable systems, processes, and procedures.
CRM is a corporate-level strategy that focuses on creating and maintaining lasting relationships with its customers. CRM tools look at the relationship between a business and its' customers and help manage relationship building and process improvement. Although there are several commercial CRM software packages on the market that support CRM strategy, building value is not about the technologies. CRM often represents a holistic change in an organizational culture and philosophy, placing emphasis on the customer.
To be effective, the CRM process needs to be integrated end to end across marketing, sales, and customer service. An effective CRM program needs to:
As Figure 2.1 shows, CRM becomes central to both business process and IT systems. IT systems become a valuable repository of information about the enterprise business, providing insights into further improvements to increase productivity and profitability.
Figure 2.1: Building value with CRM.
Customer relationships are managed by a variety of communications tools. There is an old adage in sales that says "People buy from people." CRM places the focus on the customer, without whom no business can survive. Integration of CRM systems with VoIP technologies provides tighter coupling of several aspects of relationship management.
ERP and CRM solution vendors recognize the criticality of voice communications and are actively working on integration solutions. Because these systems are based on IP technologies, there is a natural synergy with VoIP technologies, which have matured to the point that creative convergence between the network infrastructure, services (voice and data communications), and applications can now provide a seamless working environment.
Call quality is the single biggest factor leading to user acceptance of VoIP solutions. Later, this guide will talk about managing call quality; this section will compare quality in the public switched telephone network (PSTN) with VoIP, and see how voice conversations are handled.
When you implement VoIP, you're trying to use technologies that have evolved in new ways over the past 30 years, specifically, IP. As you start adding voice traffic, a multimedia service, to an IP-based network, you encounter a challenge to networking in general. In the past, networks such as the PSTN were designed to perform specific functions and support a single type of traffic. With VoIP, you're using the Internet, or an IP network, to carry voice traffic.
The problem you face isn't trivial. It actually has ramifications that ripple through every facet of network engineering in both the Internet and in the PSTN. It's a new problem that wasn't anticipated. In the past, when you had a task that required a form of networking, you designed a new network to handle the task because different applications have completely different requirements. IP changed all that because anything that can be digitized can be carried in the payload of an IP packet.
Everything we understand about voice is based on how it's been handled in the PSTN, so let's examine some basic facts about voice transmission:
These basic facts bring us to the root of a number of the technical problems encountered today. The public phone network has been consciously designed and optimized over a hundred years to deliver voice traffic in the best way possible. This traffic engineering (in telco-speak) has been a critical component of the management and growth of the PSTN. The telecommunications industry has spent years analyzing the network, monitoring its growth, and designing into the network countless optimizations to carry voice traffic effectively. It is a voice network that guarantees delivery of the traffic within the users' expectations.
There is a packet switched public data network (PSPDN) that was specifically designed to carry packet data. Private data networks have been built around the world to deliver enterprise data applications. If you compare data networks, specifically IP networks like the Internet or the PSPDN, you will find that they have very different characteristics than the PSTN:
Voice Traffic on the PSTN
IP Network Traffic
Connection-oriented—A dedicated path is established for each telephone call; calls are long duration (4 minutes on average)
Connectionless—Conversations are packetized and transmitted over the best route based on routing protocols; packets are small, so conversations are cut up into many packets
Delivery is guaranteed once the call path is established
Best efforts are made to deliver traffic but there are no guarantees
Designed to use specific bandwidth; the PSTN uses a 64Kbps voice channel
Uses the bandwidth that is available
Real-time voice traffic is very sensitive to delay
IP data traffic is delay insensitive
Table 1: Voice and data traffic comparison.
The chart is small, but it makes one very obvious point. IP was not designed to carry voice traffic. IP was designed specifically to carry bursty data over diverse paths, and make a best efforts attempt at delivery. Data can be freely discarded along the way if there are any problems. This is nothing like the PSTN in the very design of the technology.
IP networks today are designed, redesigned, and modified to support carrying any kind of traffic. Most often that is what is today called multimedia traffic—a combination of data, voice, and video. Using digitization, any media can be carried inside an IP packet. The challenge in IPT and video networks is delivering business-quality voice conversations with all the characteristics users have come to expect, such as fidelity, clarity, and near-instantaneous delivery.
If users detect what seems to be unacceptable quality, time has shown they will most likely hang up and try again. If this happens frequently, users become dissatisfied and quit using the service. It's clear that to effectively deliver voice services, tools and mechanisms are required for measuring the quality of service (QoS) and guaranteeing that network resources can support the traffic load without degradation of call quality.
One method to address call quality has been to overprovision the network. In many cases, this simply means adding more bandwidth. Although this approach might work initially, in the long run, it's a road to ruin. First, it requires capital investment. Upgrading the capacity of connections, switches, and routers can be a very expensive undertaking. This approach might work for a time in a small local area network (LAN), but in a large enterprise network, it's often too expensive to be a practical solution. In addition, experience makes it clear that if the bandwidth is available, users will fill it. Data applications can quickly consume the additional bandwidth, leaving you with the same congestion and problems you started with in delivering voice service.
To achieve acceptable voice quality over an IP network, factors such as noise, delay, echo, and jitter must be managed to tolerable thresholds. Delay is present in every IP network due to the statistical multiplexing used in routers and the generally bursty nature of packet data. There will be delay. Jitter is nothing more than variation in delay. As different packets can easily take different paths through a large network such as the Internet, variable delay is fairly common. When transmitting voice, jitter can render the audio signal unintelligible to the human ear. Jitter needs to be tightly controlled. Delay can also be caused by the time required to perform the sampling in the codec used to digitize voice. Each router in the network can also induce packetizing and routing delays as decisions are made about how to route each packet. This is also referred to as nodal delay. When designing and managing an IPT service network, it's important to remember that delay is cumulative. Every place delay occurs, it adds to other delay in an endto-end service between two people.
Networks today are large and complex systems, with a variety of applications running concurrently. They evolve and grow so quickly that they are almost organic in nature. There is a concern for any enterprise about the spiraling complexity of network design. When you design a specific set of criteria to support a given application, you create a class of service for that application. The danger in doing so is that every new class of service you create increases network complexity. An enterprise with numerous applications could quickly create an unmanageable set of service classes. Many network designers lean toward simplicity and suggest only a few critical service classes:
It's easy to identify more classes of service in almost any network. For the sake of simplicity, these three classes give you adequate prioritization capability in this guide and in many networks. Although the debate continues over how many classes of service are really necessary, the bottom line is that any implementation of a QoS mechanism that distinguishes service classes is a vast improvement over the best efforts approach used by IP.
Classes of service are only one aspect of QoS, but they aren't the only factor involved. Let's think about how enterprise networks evolved over time:
There was a long-held perception among vendors and service providers that customers' networks were poorly designed. In truth, they often weren't designed at all. Like some unplanned cyber "big bang," they exploded and grew over time based on the needs of the business they supported. It is important to understand that this happened for good reason. Companies in growth mode were successful. This often led to mergers and acquisitions, producing exponential growth. The economy boomed, and networks connected and merged quickly to meet the needs of rapidly growing business. Sometimes networks were redesigned and new technologies were integrated. In other cases, pressing business needs led to cobbling together the best that the beleaguered IT staff could manage. Some of these networks were kept operating only through long hours of frustration and ongoing reconfiguration.
Earlier, this guide noted that networks have typically been designed and optimized for specific types of services. Voice traffic was the first networked application. The PSTN was tuned and optimized to support narrowband voice channels with very low delay.
Traffic engineering for voice is a highly developed field. Its foundation is built on traffic patterns, the busy hour of the day, and statistical mathematics using something called the Law of Large Numbers. This law basically says that large groups are easier to predict than small groups. The larger the group, the more group members are likely to be near the average. For example, if you measure 10 people's height, you may find several people (a high percentage of the group) 5 feet tall. If you measure one thousand people's heights, you'll find that the statistical accuracy of the sample is no longer skewed towards shorter people because the sample size provides for greater statistical accuracy. Both telephone company central offices and enterprise PBX systems are engineered for trunking requirements using a mathematical model known as the Erlang-B distribution. Using Erlang-B, call loads are measured in centi-call seconds (CCS), which is a unit equivalent to a 100-second call. 36CCS represents a telephony circuit at maximum occupancy with zero idle time.
This guide won't explore these formulas in any depth. The focus is the practical business of managing IPT. For those interested in further study of traffic engineering, the basic formula is:
The offered load in the formula isn't a problem in a network such as the PSTN because the network has been optimized to support the load. QoS is a manageable issue when the network is designed to serve a single purpose. In today's multimedia environment, there has been a phenomenon often referred to as convergence grab center stage. Separate parallel networks don't make either technical or economic sense. As all of today's data applications converge onto the IP infrastructure, the logical next step in that integration is, for many, to integrate voice, video, and data on a single, multi-service network.
As you look to IP networks as the next-generation architecture for delivery of multimedia services, the fundamental design of IP leads to some complex issues for engineers. IP, and all packet switched networks in use today, utilize time division multiplexing (TDM). This is a statistical multiplexing technology used inside the switches and routers in IP networks. The IP Suite protocols and hardware were developed to hand all traffic types, regardless of payload, in the same manner. Routers and other network nodes have traditionally handled traffic not only on a best efforts basis but often using a first-in first-out (FIFO) approach to processing the packet flow.
Classes of service describe what's needed in the network. QoS characteristics look at the technical aspects that make it possible to support those classes of service. There are several characteristics within a network that may need to meet certain performance levels for any given service or application:
As noted several times, IP is a best efforts protocol that provides no guarantees. That is not to be misconstrued to mean that the various parameters discussed so far cannot be obtained using IP. However, you must remember that network design becomes a vital factor in any implementation of converged services.
Although the techniques used vary widely, all approaches to QoS share a common characteristic. Regardless of approach, with the exception of over-provisioning, QoS is simply a means to implementing a prioritization scheme. In some cases, this prioritization might involve a routing mechanism that aggregates similar traffic types, the routes each traffic type takes over a path suited to the needs of the traffic. There are many approaches with intricate differences, but every approach, save one, adds some form of overhead to the traffic to provide either a prioritization function, or a "traffic cop" function to direct traffic appropriately. The one exception commonly referred to as giga-bandwidth has been seen by many to be the ultimate solution, but this fallacy only defers the need for proper engineering to a future point in time.
Figure 2.2: The TCP/IP packet structure.
Figure 2.2 serves as a reminder of the format of an IP packet, but it's also shown to review one field in particular. There is a Type of Service (TOS) field in the structure of the IP packet that can and often is used as a QoS mechanism. This prioritization tool was provided in the original specifications for IP.
The TOS field, expanded in Figure 2.3, is one octet, 8 bits in length. It consists of several components:
Although the designers of IP built this prioritization capability into the protocol, vendors rarely implemented or took advantage of this feature in the past. For many years, router vendors created OSs that didn't even read the field when processing packets. This was due mainly to a complete lack of standardization. The Internet Engineering Task Force (IETF), the IP standards body, never assigned values to any of the sub-fields in the TOS field. Thus, a precedence of zero might be the highest precedence to one vendor, and the lowest to another. Real-world implementations vary greatly in the absence of a standardized approach, but the field has been used as part of a prioritization scheme more in the past couple of years.
Once you accept that IP provides no guarantees of any kind for either prioritization or delivery, the next step becomes clear. If a user needs to specify some particular network requirement, or QoS, the user must add something to IP to provide it—add it in some other layer of the protocol stack. The following methods are all in use today. They implement QoS in IP by layering some other overhead into the data stream. There are other techniques used to provide QoS, but the following sections explore three common approaches.
Integrated Services (IntServ) introduces a signaling protocol to IP. Using IntServ, the user's application sends some sort of call setup signal to the network. This signal is basically a request for a set of service delivery parameters required to complete the call. Using the approach, the network can check resource availability and deliver traffic accordingly. This approach is very similar in process to the circuit setup and teardown associated with a telephone call on the PSTN.
Under IntServ operations, users, through automated software processes, request a particular type of service of the network using Resource Reservation Protocol. RSVP has two key aspects— policy control and admission control. Policy control is used to determine whether the user has authorization to request the specified resources from the network. Assuming the user has the necessary permission, admission control governs the process for allocating and reserving the requested resources or setting up the path for the connection. RSVP passes the user requirements from node to node through the network, requesting resources. If any node along the way is unable to comply, the request is denied and no connection is established.
Real-Time Transport Protocol (RTP) is a widely used supporting protocol in IntServ deployment. It's used to assure the integrity of a session through timestamping and sequencing of UDP segments. Real-time Transport Control Protocol (RTCP) is used in conjunction with RTP and provides some level of monitoring capability.
Although IP theoretically has a rather comprehensive prioritization scheme available, IntServ provides three levels of prioritization. They're familiar because the classes of service identified earlier have been derived from the development of IntServ:
RSVP provides a signaling capability that allows a user's application to send a request to the network reserving a particular set of requirements for a voice or video session. These requirements are referred to as the template.
User applications are referred to rater than users because it's important to understand that the person using the computer will not be required to understand QoS or application requirements. The applications will have requirements written into the code to automatically provide the service levels needed.
RSVP allows user applications to identify three of the parameters reviewed earlier that might be necessary for a given application to work properly:
In Figure 2.4, the user application makes a request of the network. RSVP policy-control software then evaluates the request against a permissions table and either confirms that the user has the necessary permission to reserve the requested resources or denies access. Assuming the user has permission, RSVP then engages admission control software to determine whether the network has the necessary resources available to complete the request. The network passes the template along the network from node to node in a PATH message until it reaches the receiver. Each node must run an RSVP daemon to validate the request for QoS.
In simple form, this specification is a request passed from router to router identifying a need. If an intermediate router can meet the need, the request gets passed to the next node. If not, the request is denied. Intermediate nodes play a vital role in RSVP because every intermediate node must be able to provide the necessary QoS PATH requested in the template. Lack of resources at any point along the path can cause the call to be dropped.
Figure 2.4: Using RSVP to reserve network resources.
Once a path has been identified, each node must pass a flow specification in a reservation (RESV) message back along the network from node to node. As you've gone to the trouble of reserving resources across the network, you now must ensure that you use the resource allocated. This flowspec reservation is each router's way of knowing where the next router in the reserved path is to pass packets associated with the call or session.
There are clearly a several factors to consider when implementing RSVP for QoS. These factors become crucial when using the Internet, as those routers are not all under the control of the implementer.
Many network designers agree that IntServ and RSVP provide a potential solution but only in a network that is completely under the implementer's control. Each and every intermediate router still presents a potential single point of failure. In the Internet, data crosses many provider networks en route to its destination. IntServ can work well in a fully controlled environment, like an enterprise-owned private network. It may also prove useful at the edges of the Internet, either in customer networks or the local metropolitan portion of the Internet provider's network.
Internet service providers have almost universally chosen not to adopt IntServ as a solution to the QoS problem. The value provided just doesn't offset the cost of conversion and implementation. IntServ fails the ROI case for service providers. IntServ has found some application in private networks and is still supported by all the major router vendors. Resource Reservation Protocol for Traffic Engineering (RSVP-TE), a variation, has been deployed with success in conjunction with Multiprotocol Label Switching (MPLS).
There is another approach that requires specific routes through the network that are predefined and available for each type or class of traffic called Differentiated Services (DiffServ—also called DiffServ Code Point or DSCP). These paths might be pre-existing as part of the network design or they might be set up on demand in some manner. This second option might include some type of signaling protocol such as RSVP to establish the paths. The DiffServ method is often used as a traffic aggregation approach in order to direct similar traffic types on similar network routes.
This guide won't consider the evolution to IPv6 but will make an observation: In the development of IPv6, the TOS field was the subject of direct discussion. In IPv6, the protocol has been expanded to provide improved granularity in the delivery of QoS. In the IPv6 packet, there is a field referred to as the DiffServ field as a replacement for the current TOS field. It uses six bits of this field as the DSCP to identify how the nodes in the network should handle each packet. Routers handle packets based on a set of forwarding treatments or Per Hop Behaviors (PHB). These rules must be predefined in each network element or node. This is the provisioned approach to QoS in the network.
DiffServ is also a development of the IETF. The DiffServ working group charter and information is available at http://www.ietf.org/html.charters/DiffServ-charter.html. The objective of this working group is to employ "a small, well-defined set of building blocks from which a variety of aggregate behaviors may be built." This suite is also defined by a series of RFCs:
The DiffServ approach is to categorize traffic into classes of service. Similar services are aggregated and treated the same way in the network. Thus, network paths have to be preconfigured to support each class of service. Packets are "tagged" at the edge of the network and the appropriate forwarding treatment for that class of service tag is applied. This approach results in a much coarser granularity at each router and reduces the need for large state tables. This helps control the need for CPU processing power.
DiffServ has two primary components described in RFC 2475. Packet marking redefines the TOS field of the packet and uses six bits as a coding scheme to classify packets into a class of service. The use of six bits provides for a prioritization scheme that can identify 64 different types of traffic or aggregates.
PHBs govern how an individual class or aggregate is handled. This is defined via behavior aggregates. In essence, the PHB describes the scheduling, queuing, and traffic shaping policies used at a specific node for routing the traffic.
DiffServ can scale to very large enterprise and provider networks. It is widely supported by manufacturers and has been deployed by several large service providers. There is far more to DiffServ than can be addressed in this guide, but information and technical specifications are easily located on the Web.
MPLS is a method of providing QoS that removes the usual hop-by-hop routing in IP from the equation. MPLS adds a "tag" to every packet. This tag shortcuts the delivery by directing the packet to the best available path for the type of traffic associated with the MPLS tag. MPLS is compatible with frame relay and ATM networks. It has been widely adopted in enterprise and service provider networks for adding QoS capabilities to support VoIP and video traffic. MPLS has often been referred to as a bypass or "shim" approach to QoS. Because of the addition of a tag into the data stream, it's also often referred to as a Layer 2½ protocol.
Implementing VoIP makes companies re-evaluate their service networks. Often, it brings some fundamental changes to the way these IP networks operate. As has already been reviewed, IP is a best efforts protocol with no assurances of delivery or quality. When organizations implement VoIP, many businesses discover a compelling need to implement some QoS methodology in order to provide acceptable voice call quality. MPLS is a method that allows packet-based networks to essentially emulate some of the behavioral properties of a circuit-switched network, such as the PSTN. The following section provides a look at MPLS as one method that's frequently used to deliver QoS assurance in a large-scale enterprise environment.
MPLS evolved from several different but similar techniques. One of the leading approaches was developed by a group of engineers at Cisco Systems. Initially, this proprietary protocol was called tag switching. As the technology evolved, industry leaders came together in a consolidated effort under the auspices of an IETF working group pursuing an open standard that became MPLS.
MPLS works by pre-pending packets with an MPLS shim header, or tag, to the beginning of a packet. Although this guide is focused on IP networks, MPLS works equally well with framerelay frames and ATM cells in those networks. This shim header contains one or more labels and is often called a label stack.
Figure 2.5: The MPLS packet and MPLS encapsulation.
As Figure 2.5 shows, each label stack entry contains four fields:
These MPLS-labeled packets are switched by performing a label lookup/switch instead of a lookup into an IP routing table. Because label switching can be performed within the switching fabric of the hardware, it processes much faster than traditional router-based IP address lookups process.
In an MPLS network, routers become label switching nodes that add and remove labels as needed. You'll hear the term label popping from time to time. Using this method, a large routed network looks like one single routing hop at Layer 3 of the TCP/IP stack. Path selection is based, not on a routing metric, but on the MPLS label. Routers may be thought of as Label Switching Routers (LSR) through the core of the network, with Label Edge Routers (LER) at the border points of the MPLS domain. Routers that provide ingress and egress to the MPLS are often called Provider Edge (PE) routers.
The Class of Service (COS) field is used to assign classes of service much as described earlier in the chapter in a section that looked at three classes. MPLS often adds a fourth class for management traffic. Typical MPLS classes of service are:
Using this approach, similar traffic types can be aggregated into the same class of service, not unlike DiffServ. When addressing is applied to the packets, they might be labeled by an application, a router, a switch, or some other mechanism at ingress to the network. This COS header is used to aggregate packets into what is called a forwarding equivalency class (FEC) for switching throughout the network. The undefined experimental bits are used by most MPLS vendors to carry the latest 3 of 5 DSCP priority bits in the IPv4 header, as a simple emulation of traffic prioritization.
When a labeled packet arrives at an MPLS router, the topmost label is "popped" and examined. Based on the contents of that label, a swap, push, or pop operation is performed on the packet's label stack. Routers can have predefined lookup tables so that they can process the packet very quickly. In a swap operation, the label is swapped with a new label, and the packet is forwarded along whatever network path is associated with that new label.
In a push operation, a new label is pushed on top of the existing label, effectively encapsulating the packet in another layer of MPLS. This allows the hierarchical routing of MPLS packets. Notably, this is used by MPLS VPNs.
In a pop operation, the label is removed from the packet, which may reveal an inner label below. If the popped label was the last on the label stack, the packet leaves the MPLS tunnel or domain.
This is usually done by the network egress router.
Figure 2.6: Label switching with MPLS.
During these operations, the contents of the packet below the MPLS label stack, the IP packet and payload, are not opened or processed. Intermediate transit routers only need to read the topmost label on the stack. Packet forwarding decisions are based on the contents of the labels, providing protocol independent packet forwarding. There is no need to look at a protocol-dependent routing table. This eliminates the cumbersome IP longest prefix match routing protocols require at each hop.
When the packet leaves the network at an edge router, and the last label has been popped, only the payload remains. This can be an IP packet or any of a number of other kinds of payload packet in other networks. The edge router must therefore have routing information for the packet's payload because the router must forward the packet using traditional routing methods. An MPLS transit router has no such requirement.
MPLS can't be compared directly with IP as a separate entity. They are complementary protocols. MPLS works with IP and IP's interior gateway (IGP) routing protocols. MPLS brings a level of basic traffic engineering capability to IP networks. MPLS relies on traditional IGP routing protocols to construct the label forwarding table, and the scope of any IGP is usually restricted to a single service provider for stability and policy reasons. There isn't a current standard for interoperable carrier-to-carrier MPLS, so it's not yet practical to span one MPLS service across more than one carrier.
MPLS is currently in use in large IP only networks and is standardized by IETF in RFC 3031. In practice, MPLS is mainly used to forward IP packets and Ethernet traffic. Major applications of MPLS are telecommunications traffic engineering and MPLS VPNs.
This chapter began by considering high-level the business models and processes because they're most often the ones directly affected by VoIP. They're also central focal areas as the concept of unified communications brings network services, such as voice and video, and applications together. The chapter then moved into factors crucial to providing call quality. The network can't effectively converge and thrive if suitable quality isn't present. The next chapter will delve into drivers for change in three areas: business drivers, const reduction drivers, and strategic drivers.