Table Of Contents
QoS for IP Telephony using
CiscoWorks Management Tools
Because many enterprises are recognizing the value of converging their voice and data networks, Cisco Systems has published design recommendations for successful convergence, an important element of which is enabling quality of service (QoS) from every device in the network infrastructure.
To facilitate QoS deployment, Cisco has embedded these design recommendations within the CiscoWorks QoS Policy Manager (QPM) product through IP telephony QoS templates. These modifiable templates contain all the basic recommendations for QoS for voice over IP (VoIP). Provisioning QoS for an IP telephony-enabled enterprise becomes a simple, recursive task of using the CiscoWorks QPM graphical user interface (GUI) to assign device interfaces into predefined policy groups and then with a simple mouse click, deploying them.
In addition to policy configuration, QoS management involves monitoring, trending, and adjusting of QoS policies to ensure their objectives are being met. The CiscoWorks Service Management Solution (SMS) is a complementary product to CiscoWorks QPM that manages ongoing enterprise-wide testing of the network infrastructure to monitor QoS. CiscoWorks SMS is a proactive troubleshooting tool that can report service-level failures before these become noticeable to end users.
This document presents two case studies of enterprises that have successfully enabled QoS for IP telephony using CiscoWorks QoS management tools. The first is Bonita Unified School District, which is located in southern California and deploys 200 Cisco IP Phones; the second is Envision Financial, a credit union located in British Columbia, Canada, that deploys 400 Cisco IP Phones. Both enterprises have network infrastructures that include a broad range of Cisco routers and switches, and both use Cisco CallManager, which is the software-based call-processing component of the Cisco IP telephony solution. Additionally, both enterprises plan to expand the number of IP phones they deploy to meet their growing needs.
Bonita Unified partnered with a Top 100 value-added reseller (VAR) to converge voice and data onto a single IP network. Initially, IP telephony was deployed with no QoS, resulting in unacceptable call quality. As a next step, QoS was configured manually on the switches and routers. This process was time consuming and error ridden, because the policies deployed were incomplete, inaccurate, and outdated. This deployment inevitably produced inconsistent voice quality. Subsequently, Bonita used CiscoWorks QPM to rapidly deploy Cisco recommended QoS for IP telephony across the Bonita IP network and to uniformly provision priority service for voice with the IP telephony QoS templates. By deploying a single, converged network Bonita Unified has reduced its operating costs with the savings being funneled into school programs.
Envision saved three to four weeks of consulting time and cost by using CiscoWorks QPM to deploy QoS. Furthermore, with CiscoWorks SMS, the company was able to detect (and proactively correct) poor service levels caused by its service provider even before its banks opened for business; the problem was resolved before anyone had to experience or report poor quality calls. Convergence is positioning Envision to be a customer service leader by making every Cisco IP Phone in its enterprise a virtual call center.
Using CiscoWorks QoS management tools, both enterprises can manage their QoS for IP telephony requirements accurately and efficiently, and they are well positioned to make adjustments to their policies (or add new ones) to accommodate future QoS requirements, whether for voice, video, or data.
A steadily increasing number of enterprises recognize the value of converging voice, video, and data networks. For some companies, this translates to immediate cost savings in managing employee adds, moves, and changes. For others, the value comes from toll-bypass savings. For still others, the short-term payback of a converged infrastructure is considered a bonus compared with longer-term strategic objectives, such as the following:
•Increasing employee productivity by allowing for greater mobility (for example, with applications such as SoftPhone, employees can be reached at their extensions even if they are sitting at an airport waiting for a flight)
•Making every desktop a virtual call center (with customer information appearing at any phone the instant a customer calls)
•Laying the foundation for high-quality, two-way videoconferencing at any desktop or phone
While the reasons for convergence vary, the design principles for a successfully converged infrastructure remain the same. These guidelines include enabling QoS from every node in the network to provide the required service levels from the infrastructure to these advanced enterprise applications.
For a brief summary of these recommendations, refer to Appendix A: QoS for IP Telephony Recommendations Overview.
Alternatively, Cisco has embedded the design guidelines in CiscoWorks QPM using a set of IP telephony QoS templates. These templates contain all the recommended QoS policies for voice for each device type and role (for example, access switch, WAN aggregation router, remote branch router) found in converged networks. CiscoWorks QPM enables users to modify these templates as needed to meet specific, customized network requirements. For additional details, refer to Appendix B: Configuring QoS for IP Telephony with QPM Templates.
Provisioning QoS is one step in a continuous cycle of QoS management, which also includes monitoring pre- and post-QoS policy deployment and adjusting policies as new applications are introduced or as network conditions change.
CiscoWorks Service Management Solution (SMS) facilitates the ongoing monitoring of QoS. SMS is a complementary product to CiscoWorks QPM. QPM provides a user-friendly GUI for scalable and centralized QoS policy creation and deployment, and SMS enables management of comprehensive and ongoing infrastructure testing to ensure that predefined end-to-end service levels are being met. SMS performs these enterprise-wide tests by managing the Service Assurance Agent (SAA) within the Cisco IOS® Software. This agent allows devices running the Cisco IOS Software to simulate voice-over-IP (VoIP) conversations (in addition to tailored Transmission Control Protocol/User Datagram Protocol ([TCP/UDP] flows), between any pair of devices. Such paired testing efficiently demarcates and identifies network segments where QoS levels are not being met. For additional details, refer to Appendix C: Understanding the Service Assurance Agent and Appendix D: Configuring and Monitoring Voice Service Levels with SMS 2.0.
Bonita Unified School District Case Study
Bonita Unified School District lies 35 miles east of Los Angeles and provides education to more than 10,000 students enrolled in two comprehensive high schools, a continuation high school, an alternative education program, two middle schools, and eight elementary schools. The District is proud of its more than 1,000 employees who are dedicated to providing an excellent educational environment for their students. By creatively maximizing its financial resources, the Bonita Unified School District continues to provide programs and services that many other California school districts have been forced to eliminate for financial reasons, including a growing computer technology program in all schools. Of the District's nine community educational goals, number two is to "Infuse technology into the curriculum."
Bonita recognized the long-term value of converging voice and data networks and began rolling out Cisco IP phones in September of 2000 to all 13 locations. By December 2001, 180 Cisco IP Phones were deployed, and this number is expected to double by the end of 2002.
Figure 1 Bonita Unified School District IP Telephony Network
Evaluation of Initial Manual QoS Deployment:
Bonita Unified did not have the in-house expertise to provision QoS for its converged network, so the school district partnered with a third-party VAR to enable QoS in its enterprise. The school district chose a VAR that was the professional services arm of a multibillion dollar international IT leader—one that was listed within the top 100 of the VARBusiness annual listing of the top 500 solution providers, integrators, and IT consultants in North America for 2001.2
Because Bonita had adequate bandwidth in its network, a decision was made not to enable QoS before deploying the Cisco IP phones. However, bandwidth without service guarantees inevitably results in low call quality. Therefore, during the first few weeks of the IP Phone rollout, call quality was very poor and numerous users complained of static interference and conversation drops.
To remedy the situation, QoS was enabled via manual command-line interface (CLI) configuration on the switches and routers. This took a significant amount of time and effort that ultimately resulted in sub-optimal end-to-end service provisioning. It was determined that the configured QoS was not based on the Cisco recommendations for IP telephony. Specifically, three issues regarding QoS enforcement needed to be addressed:
Priority Queueing implemented instead of Low-Latency Queuing
1. Priority Queuing (PQ) is one of the oldest queuing algorithms available in the Cisco IOS Software (introduced in Cisco IOS Software Release 10.0). PQ is effective, yet crude. High-priority traffic is serviced via a strict priority queue, and subsequent queues (Medium, Normal and Low) are each in turn serviced as the higher queues are emptied.3 In PQ, high-priority traffic is indeed expedited, but at the direct cost of lower priority traffic. Traffic starvation is a common occurrence, and background traffic throughput is very inefficient. Therefore, Cisco developed Low-Latency Queuing (LLQ), which is a hybrid queuing algorithm, with elements of Priority-Queuing, and Class-Based Weighted-Fair Queuing. LLQ expedites Real-Time Priority (RTP) traffic, such as voice and video, but does not starve background data applications. Rather, it provisions minimum bandwidth guarantees for important data traffic and permits fair bandwidth division for other, less important applications.4 Although PQ protected Bonita's voice traffic, it handled the district's background traffic very inefficiently, resulting in major performance issues for other important data applications.
RTP Header Compression enabled in passive mode instead of active
2. VoIP is encapsulated in not only the IP packet, but also in a UDP segment and an RTP packet. This generates 40 bytes of header for a single VoIP packet, which normally carries only 20 bytes of payload. Therefore, to improve transport efficiency over WAN links, in certain scenarios Cisco recommends enabling RTP Header Compression (cRTP). cRTP compresses VoIP headers from 40 bytes to 2-5 bytes.5 Because cRTP is not supported over all WAN media, it allows for operation in a passive mode, in which RTP headers are compressed on a WAN link only if compressed headers have been received on the same link. If, however, (as in Bonita's case) both ends of the WAN links are configured to operate in cRTP passive mode, then cRTP will never be initiated and therefore no VoIP packets will ever have their headers compressed. Such a scenario completely defeats the purpose of enabling cRTP.
Link Fragmentation and Interleaving not enabled on WAN links slower than 768 kbps
3. VoIP requires a strict one-way latency (delay) constraint for acceptable call quality (150-200 ms). Serialization delay on slow links (less than 768 kbps) greatly affects not only the latency of VoIP packets, but also the variation in delay (jitter) of these packets. Serialization delay is the finite amount of time required to transmit packets over a link. For instance, on a 128-kbps circuit, a typical HTTP or FTP packet (1500 bytes) would require 93 ms to be serialized (or converted into electrical pulses for transmission across the circuit). To mitigate serialization delay, Cisco recommends all links under 768 kbps have a fragmentation and interleaving mechanism activated (LFI for MLP6 and FRF.12 for Frame-Relay7). No such mechanism was enabled on Bonita's slow-speed WAN links.
"Now I'm confident that our infrastructure is sound, and it's very important to get the infrastructure right. Then you can build on it solidly down the road. And it's the long term where the real cost savings come in."
—Jack Hipp, IT Director, Bonita Unified
CiscoWorks QPM Aligns QoS with Cisco Recommendations
Jack Hipp, IT Director of Bonita Unified, decided to use CiscoWorks QPM 2.1.2 to meet Bonita's IP telephony QoS needs. Additionally, Hipp determined that some of his devices required hardware and software upgrades to leverage the Cisco recommended QoS for voice features. Dollars are scarce in Bonita's budget, and therefore upgrades are scrutinized and tightly controlled; nonetheless, Bonita proceeded with the required upgrades, banking on the long-term cost savings of a solid, converged network infrastructure.
Using CiscoWorks QPM, Bonita's 43 devices were imported and their configurations parsed. Any discrepancies between previously deployed QoS policies and recommended QoS policies were presented prior to deployment. Hipp reviewed and approved the recommended corrections, which in turn were pushed out within minutes. The entire process took less than half a day.
Hipp states, "I found QPM very useful. The drawback on the whole quality of service issue is that the layman doesn't have that much interface with it. While it's understood to be important for the network, to a person who doesn't do it on a regular basis it's very confusing. Dragging-and-dropping device interfaces into predefined policy groups and then clicking on a single button to push out changes is incredibly simple. Traditional QoS configuration would require more steps and time. There's a big time saving with these IP telephony templates. And now that everything is setup, future changes are much easier to deploy, particularly as we consider adding new applications like IP videoconferencing."
Bonita also evaluated CiscoWorks SMS as a tool to test service-level performance for VoIP. Hipp comments further, "Performance testing is increasingly important, because it's crucial to have available bandwidth to meet the needs of the school, and if I don't have any tools to see what's happening there, it's like flying by the seat of your pants."
With QPM deploying the correct QoS policies, and performance testing planned for the future, Hipp concludes, "Now I'm confident that our infrastructure is sound, and it's very important to get the infrastructure right. Then you can build on it solidly down the road. And it's the long term where the real cost savings come in." In fact, Bonita expects to save thousands of dollars per month using a converged network.
Envision Financial Case Study
Envision Financial is a merger of two credit unions in British Columbia, Canada. Envision has 700 employees serving 110,000 customers at 23 branch locations scattered across the lower mainland area of BC. They use 400 Cisco IP Phones in about a dozen branches, with plans to rollout an IP Phone to each employee at every branch.
Envision's mission statement includes providing exceptional and innovative financial services to its customers. The company strives to be the best at what it does, and has an objective to build customer loyalty by providing exceptional value to its customers. An important factor in this competitive differentiation is Envision's creative use of information technology.
As Envision Vice President of Technology and Information Systems Hank Poelvoorde puts it, "Cisco IP telephony is an opportunity to provide more tools to our staff and members. The call center is becoming extinct and it's important to view the organization itself as the call center. Our strategic vision is to merge the directory database with our customer service database, so when customers call us, our staff will have all their relevant information appearing immediately on their Cisco IP Phone. This will not only save us the costs related to call center infrastructure, but also will lead to our employees providing better service to our customers."
QoS Requirements and Cisco Solution
Envision recognizes that it must provide not only high availability to its customers, but also high QoS. Poelvoorde comments further: "The phone is one of our touch-points to our customers. We must move the highest level of QoS to all our touch-points. We simply cannot have bandwidth problems that break up phone conversations, nor any intermittent static or drops in the conversation. QoS is integral to VoIP. You simply have to have it; otherwise you will experience unintelligible phone conversations. The customer wants to hear high-quality voice, and not have any reason for doubting the quality or reliability of their bank's infrastructure that is housing their money."
While the mandate for QoS was clear, the plan for executing QoS was not. Michael Gower, Envision's technical services manager, states: "We knew we needed QoS enabled throughout our network, initially for voice and later for other applications. With limited technical expertise in-house to do this, we looked into leveraging Cisco QoS Policy Manager; the other option was to hire a consultant to plan and deploy the required QoS."
The Envision networking team estimated that the IP telephony QoS templates within CiscoWorks QPM saved them three to four weeks of consulting time, effort, and cost.
With CiscoWorks QPM, QoS was rolled out to all of Envision's IP telephony-enabled network (Figure 2) in a single day. Additionally, CiscoWorks SMS was installed and enterprise-wide QoS testing was enabled within the same day.
"We now have the ability, not only to make policy changes and push these out on our own, but to monitor our components and make sure these are functioning up to spec. This was the solution we were looking for."
—Michael Gower, Technical Services Manager, Envision Financial
Figure 2 Envision's IP Telephony Network
The value that CiscoWorks SMS brought to Envision's solution was evident the next day. Overnight, SMS continually monitored latency (delay), jitter (variance in delay) and packet loss of all WAN links. Before the banks opened, a report was generated on each WAN link to ensure that QoS levels were being met. One of the branches, Sardis, reported packet-loss statistics of up to five percent, which was above the administratively defined threshold of two percent (Figure 2). Incidentally however, the third-party network management platform Envision was using showed nothing out of the ordinary and continued to display the link as green (representing availability).
Figure 3 Packet-Loss Report for Sardis Branch
Unfortunately for Envision, this was not an uncommon occurrence, and it was due to poor clocking provided by the company's service provider. Envision quickly opened a trouble ticket with the service provider, had the line reset, and the problem was solved immediately. After the line was reset, packet loss on the line was held at zero percent.
CiscoWorks SMS made the troubleshooting process very proactive. No poor quality voice calls were made, no employees needed to call internal technical support to complain of the problem, and most importantly, no customers had to experience poor call quality. This problem was detected and fixed before the bank even opened for business.
Overall, Envision was very pleased with their QoS management solution, especially the flexibility of rolling out QoS to new applications quickly and correctly, without requiring expensive third-party consultants to do so. The day after QoS for VoIP was deployed, Envision began modifying QoS policies for its enterprise to extend beyond VoIP and include provisioning for its mission-critical banking applications.
Gower concludes: "We now have the ability, not only to make policy changes and push these out on our own, but to monitor our components and make sure these are functioning up to spec. This was the solution we were looking for."
While the reasons for converging networks vary from enterprise to enterprise, the design principles remain the same. QoS is required from every device within the infrastructure to guarantee high-quality voice calls. Cisco has developed not only the necessary QoS mechanisms to achieve high-quality voice, but also comprehensive design guides to assist users in deploying the right QoS mechanisms at the right points in their infrastructure.
To facilitate QoS deployment, the recommendations of the Cisco IP Telephony QoS Design Guide have been embedded into Cisco's QoS Policy Manager via predefined (yet modifiable) IP telephony QoS templates. This simplifies QoS provisioning to a recursive exercise of dragging and dropping interfaces into their corresponding predefined policy groups. QoS policy deployment to hundreds of devices can then occur in a matter of minutes.
The IP telephony QoS templates enable network administrators that may not be experts in QoS to quickly and accurately deploy Cisco QoS recommendations. As both Envision Financial and Bonita Unified case studies have shown, this results in significant time and cost savings. An additional benefit is that subsequent additions or changes to enterprise-wide QoS policies can easily be made using the same QPM tool, for rules-based policy guidance and robust QoS administration.
As managing QoS also involves monitoring, before and after deploying policies, CiscoWorks SMS allows administrators to continually and proactively test their entire network infrastructure to guarantee that service-levels are being met. Network segments where QoS is not meeting defined service-level thresholds are quickly reported—usually before users begin to experience the effects of poor service levels.
CiscoWorks QoS management tools provide a complete solution for network administrators to monitor, provision, and adjust QoS for their converged enterprise IP infrastructure.
Appendix A: QoS for IP Telephony Recommendations Overview9
Why Is QoS Needed?
Voice quality is directly affected by two major factors:
Packet loss causes voice clipping and skips. The industry standard codec algorithms used in Cisco Digital Signal Processor (DSP) can correct for up to 30 ms of lost voice. Cisco VoIP technology uses 20-ms samples of voice payload per VoIP packet. Therefore, for the codec correction algorithms to be effective, only a single packet can be lost during any given time.
Packet delay can cause either voice quality degradation due to the end-to-end voice latency or packet loss if the delay is variable. If the end-to-end voice latency becomes too long (250 ms, for example), the conversation begins to sound like two parties talking on a CB radio. If the delay is variable, there is a risk of jitter buffer overruns at the receiving end. Eliminating drops and delays is even more imperative when including fax and modem traffic over IP networks. If packets are lost during fax or modem transmissions, the modems are forced to "retrain" to synchronize again. By examining the causes of packet loss and delay, you can gain an understanding of why QoS is needed in all areas of the enterprise network.
Voice packets can be dropped if the network quality is poor, if the network is congested, or if there is too much variable delay in the network. Poor network quality can lead to sessions frequently going out of service due to lost physical or logical connections. VoIP design and implementation is predicated on the assumption that the physical and logical network follows sound design methodologies and is extremely stable.
Network congestion can lead to both packet drops and variable packet delays. Voice packet drops from network congestion are usually caused by full transmit buffers on the egress interfaces somewhere in the network. As links or connections approach 100 percent utilization, the queues servicing those connections become full. When a queue is full, new packets attempting to enter the queue are discarded. This can occur on a campus Ethernet switch as easily as in the Frame Relay network of a service provider.
Because network congestion is typically sporadic, delays from congestion tend to be variable in nature. Egress interface queue wait times or large serialization delays cause variable delays of this type.
Delay and Jitter
Delay is the time it takes for a packet to reach the receiving endpoint after being transmitted from the sending endpoint. This time is termed the "end-to-end delay," and it consists of two components: fixed network delay and variable network delay. Jitter is the delta, or difference, in the total end-to-end delay values of two voice packets in the voice flow.
Fixed network delay should be examined during the initial design of the VoIP network. The International Telecommunications Union (ITU) standard G.114 states that a one-way delay budget of 150 ms is acceptable for high voice quality. Research at Cisco has shown that there is a negligible difference in voice quality scores using networks built with 200 ms delay budgets. Examples of fixed network delay include the propagation delay of signals between the sending and receiving endpoints, voice encoding delay, and the voice packetization time for various VoIP codecs. Propagation delay calculations work out to almost 0.0063 ms/km. The G.729A codec, for example, has a 25 ms encoding delay value (two 10 ms frames + 5 ms look-ahead) and an additional 20 ms of packetization delay.
Congested egress queues and serialization delays on network interfaces can cause variable packet delays. Without Priority or Low-Latency Queuing (LLQ), queuing delay times equal serialization delay times as link utilization approaches 100 percent. Serialization delay is a constant function of link speed and packet size. The larger the packet and the slower the link clocking speed, the greater the serialization delay. While this is a known ratio, it can be considered variable because a larger data packet can enter the egress queue before a voice packet at any time. If the voice packet must wait for the data packet to serialize, the delay incurred by the voice packet is its own serialization delay plus the serialization delay of the data packet in front of it. Using Cisco Link Fragmentation and Interleave (LFI) techniques, serialization delay can be configured to be a constant delay value.
Because network congestion can be encountered at any time within a network, buffers can fill instantaneously. This instantaneous buffer utilization can lead to a difference in delay times between packets in the same voice stream. This difference, called jitter, is the variation between when a packet is expected to arrive and when it actually is received. To compensate for these delay variations between voice packets in a conversation, VoIP endpoints use jitter buffers to turn the delay variations into a constant value so that voice can be played out smoothly.
Cisco VoIP endpoints use DSP algorithms that have an adaptive jitter buffer between 20 and 50 ms. The actual size of the buffer varies between 20 and 50 ms based on the expected voice packet network delay. These algorithms examine the timestamps in the Real-Time Transport Protocol (RTP) header of the voice packets, calculate the expected delay, and adjust the jitter buffer size accordingly. When this adaptive jitter buffer is configured, a 10 ms portion of "extra" buffer is configured for variable packet delays. For example, if a stream of packets is entering the jitter buffer with RTP timestamps indicating 23 ms of encountered network jitter, the receiving VoIP jitter buffer is sized at a maximum of 33 ms. If a packet's jitter is greater than 10 ms above the expected 23 ms delay variation (23 + 10 = 33 ms of dynamically allocated adaptive jitter buffer space), the packet is dropped.
Voice quality is only as good as the quality of the weakest network link. Packet loss, delay, and delay variation all contribute to degraded voice quality. In addition, because network congestion (or more accurately, instantaneous buffer congestion) can occur at any time in any portion of the network, network quality is an end-to-end design issue. The QoS tools discussed throughout this guide are a set of mechanisms to increase voice quality on data networks by decreasing dropped voice packets during times of network congestion and by minimizing both the fixed and variable delays encountered in a given voice connection.
These QoS tools can be separated into three categories:
The following sections describe these categories.
Classification tools mark a packet or flow with a specific priority. This marking establishes a trust boundary that must be enforced.
Classification should take place at the network edge, typically in the wiring closet or within the IP phones or voice endpoints themselves. Packets can be marked as important by using Layer 2 Class of Service (CoS) settings in the User Priority bits of the 802.1p portion of the 802.1q header or the IP Precedence/Differentiated Services Code Point (DSCP) bits in the Type of Service (ToS) Byte of the IPv4 header. All IP phone RTP) packets should be tagged with a CoS value of 5 for the Layer 2 802.1p settings and an IP Precedence value of 5 for Layer 3 settings. In addition, all Control packets should be tagged with a Layer 2 CoS value of 3 and a Layer 3 ToS of 3.
The practice of using IP Precedence to mark traffic is a transitional step until all IP devices support DSCP. Ideally, in the future, all Cisco VoIP endpoints will use a DSCP value of Expedited Forwarding (EF) for the RTP voice bearer flows and a DSCP value of Assured Forwarding 31 (AF31) for VoIP Control traffic.
Queuing tools assign a packet or flow to one of several queues, based on classification, for appropriate treatment in the network.
When data, voice, and video are placed in the same queue, packet loss and variable delay are much more likely to occur. By using multiple queues on egress interfaces and placing voice packets into a different queue than data packets, network behavior becomes much more predictable. Queuing is addressed in all sections of this guide because buffers can reach capacity in any portion of the network.
Addressing serialization delay is considered part of an overall queuing solution. Serialization delay is a factor only on slow-speed links (links of 768 kbps or below).
Network provisioning tools accurately calculate the required bandwidth needed for voice conversations, all data traffic, any video applications, and necessary link management overhead such as routing protocols.
When calculating the required amount of bandwidth for running voice over a WAN, it is important to remember that all the application traffic (that is, voice, video, and data traffic), when added together, should equal no more than 75 percent of the provisioned bandwidth. The remaining 25 percent is used for overflow and administrative overhead, such as routing protocols.
QoS for VoIP is guaranteed when proper VoIP network design is combined with the new Cisco Catalyst® products, the latest Cisco IOS® Software releases, and Cisco CallManager call admission control technologies. When building a Cisco AVVID (Architecture for Voice, Video and Integrated Data) network, follow these core principles:
•Use 802.1q/p connections for the IP phones and use the auxiliary virtual LAN (VLAN) for voice.
•Classify voice RTP streams as EF or IP Precedence 5 and place them into a second queue (preferably a priority queue) on all network elements.
•Classify Voice Control traffic as AF31 or IP Precedence 3 and place it into a second queue on all network elements.
•Enable QoS within the campus if LAN buffers are reaching 100 percent utilization.
•Always provision the WAN properly, allowing 25 percent of the bandwidth for overhead, routing protocols, Layer 2 link information, and other miscellaneous traffic.
•Use Low Latency Queuing (LLQ) on all WAN interfaces.
•Use Link Fragmentation and Interleaving (LFI) techniques for all link speeds below 768 kbps.
Appendix B: Configuring QoS for IP Telephony with QPM Templates
Using the QPM IP Telephony Templates
You create a new IP telephony database from the predefined IP Telephony Template database that is included with QPM. To open the IP Telephony Template, click on Open IP Telephony Template. The following template view will appear.
Figure 4 QPM IP Telephony QoS Templates
After you open the QPM IP Telephony database, you must save it with a new name because it is read -only.
Step 1. In the Policy Manager window, click the Open IP Telephony Template button.
Step 2. Choose File>Save As. The Save Database dialog box opens.
Step 3. Enter a name in the Database Name field.
Step 4. Enter a description in the Database Description field. Click OK.
Add Devices and Interfaces to IP Telephony Database
You must add or import all the devices and interfaces that require QoS configuration for IP telephony.12 After you have added the devices and interfaces to the IP telephony database, you add interfaces to the appropriate predefined device groups.
Step 1. Select the device group to which you want to add interfaces.
Step 2. Choose Devices>Device Group>Add/Remove Members.
The Add/Remove Members dialog box opens.
Step 3. Select the interfaces you want from the Available Interfaces list, and click >>.
The selected interfaces are added to the Group Members list.
Step 4. Click OK.
Repeat for each set of interfaces. Save the database when complete.
Deploy the Database from the Distribution Manager
After you have added all the required interfaces to the relevant device groups, you can deploy the IP telephony database from the Distribution Manager.
Note: You can preview the CLI commands that will be downloaded to the devices, using the Devices>View Commands option in the Distribution Manager.
Step 1. To open the Distribution Manager choose Tools>Distribution Manager.
Step 2. Click on Devices>Apply. Choose the database name and click OK.
Appendix C: Understanding the Service Assurance Agent
The Cisco SAA13 is an application-aware synthetic operation agent that monitors network performance by measuring response time, network resource availability, application performance, jitter (interpacket delay variance), connect time, throughput, and packet loss. Performance can be measured between any Cisco device that supports this feature and any remote IP host (server), Cisco routing device, or mainframe host. Performance measurement statistics provided by this feature can be used for troubleshooting, for problem analysis, and for designing network topologies.
The Cisco SAA can be especially useful for enterprise and service provider networks, because it provides expanded measurement and management capabilities. In particular, the SAA is a reliable mechanism for accurately monitoring the metrics in service-level agreements (SLAs).
Because SAA is accessible using Simple Network Management Protocol (SNMP), it also can be used in performance monitoring applications for network management systems such as CiscoWorks Internetwork Performance Monitor (IPM), and Service Management Solution (SMS).
SNMP notifications based on the data gathered by the SAA allow the router to receive alerts when performance drops below a specified level and when problems are corrected.
Appendix D: Configuring and Monitoring Voice Service Levels with CiscoWorks SMS 2.0
To begin setting up SLCs, you select Service Level Management > Administration > Service Level Manager > Define Service Contracts from the CiscoWorks2000 Server desktop.
Defining VoIP Service Level Agreements
Step 1. From the Define SLC in Folder <Folder Name> Window, click New, then choose Voice over IP. You can also use the shortcut keys.
Step 2. Enter the SLA name in the field provided. Choose a name that easily identifies the SLA.
Step 3. Complete the optional Comments field. Include comments that help to describe the SLA. Comments are used throughout the SLC reports.
Step 4. Select source port and target port.
Step 5. Enter the information in the required fields or accept the defaults.
Step 6. Click Next. The Select Devices - Voice over IP window opens.
Step 7. Select the SLA source device(s) from the left column and select target device(s) from the right column.
Step 8. Click Add.
The SLA device pair is now listed in the bottom frame of the Select Devices window.
Step 9. Click Next. The Define Thresholds - Voice over IP window opens.
Step 10. Set Jitter threshold using the field provided or accept the default of 30 ms.
Step 11. Set Round-Trip Latency threshold using the field provided or accept the default of 150 ms.
Step 12. Set Packet Loss threshold using the field provided or accept the default of 2%.
Step 13. Click Finish.
To begin generating reports, you select Service Level Management > Service Level Reports > View Reports from the CiscoWorks Server desktop. A new browser window opens from which you select your reports.
Figure 5 SMS Reports
2 VARBusiness Top 500 VARs for 2001:
3 Priority Queuing (PQ):
4 Low-Latency Queuing (LLQ):
5 Compressed Real-Time Protocol (cRTP):
6 Link Fragmentation and Interleaving (LFI) for Multilink Point-to-Point Protocol (MLP):
7 Frame Relay Forum 12 (FRF.12) for Frame Relay Fragmentation:
10 Configuring QoS for VoIP with CiscoWorks QPM 2.1 IPT QoS Templates:
11 Adding Devices to CiscoWorks QPM:
12 Service Assurance Agent (SAA):
13 Defining and Monitoring Service-Level Contracts with CiscoWorks SMS 2.0: