Which of the below technologies extends the standard WFQ functionality to provide support for user defined traffic classes?

PESQ, whose operation is illustrated in Figure 7-4, was originally developed by British Telecom, Psytechnics, and KPN Research of the Netherlands. It has evolved into ITU Standard P.862, which is considered the current standard for voice quality measurement. PESQ can take into account CODEC errors, filtering errors, jitter problems, and delay problems that are typical in a VoIP network. PESQ combines the best of the PSQM method along with a method called Perceptual Analysis Measurement System (PAMS). PESQ scores range from 1 (worst) to 4.5 (best), with 3.8 considered "toll quality" (that is, acceptable quality in a traditional telephony network). PESQ is meant to measure only one aspect of voice quality. The effects of two-way communication, such as loudness loss, delay, echo, and sidetone, are not reflected in PESQ scores.

Figure 7-4

PESQ

Many equipment vendors offer PESQ measurement systems. Such systems are either stand-alone or they plug into existing network management systems. PESQ was designed to mirror the MOS measurement system. So, if a score of 3.2 is measured by PESQ, a score of 3.2 should be achieved using MOS methods.

Quality Measurement Comparison

Early quality measurement methods, such as MOS and PSQM, were designed before widespread acceptance of VoIP technology. PESQ was designed to address the shortcomings of MOS and PSQM.

MOS uses subjective testing where the average opinion of a group of test users is calculated to create the MOS score. This method is both time-consuming and expensive, and might not provide consistent results between groups of testers.

PSQM and PESQ use objective testing where an original reference file sent into the system is compared with the impaired signal that came out. This testing method provides an automated test mechanism that does not rely on human interpretation for result calculations. However, PSQM was originally designed for circuit-switched networks and does not take into account the effects of jitter and packet loss.

PESQ measures the effect of end-to-end network conditions, including CODEC processing, jitter, and packet loss. Therefore, PESQ is the preferred method of testing voice quality in an IP network. Table 7-3 offers a comparison of the various quality metrics.

Table 7-3 Voice Quality Measurement Comparison

Objectives of QoS

To ensure that VoIP is an acceptable replacement for standard public switched telephone network (PSTN) telephony services, customers must receive the same consistently high quality of voice transmission that they receive with basic telephone services.

Like other real-time applications, VoIP is extremely sensitive to issues related to bandwidth and delay. To ensure that VoIP transmissions are intelligible to the receiver, voice packets cannot be dropped, excessively delayed, or subjected to variations in delay (that is, jitter).

VoIP guarantees high-quality voice transmission only if the signaling and audio channel packets have priority over other kinds of network traffic. A successful VoIP deployment must provide an acceptable level of voice quality by meeting VoIP traffic requirements for issues related to bandwidth, latency, and jitter. QoS provides better, more predictable network service by performing the following:

• Supporting dedicated bandwidth—Designing the network such that the necessary bandwidth is always available to support voice and data traffic

• Improving loss characteristics—Designing a Frame Relay network such that discard eligibility is not a factor for frames containing voice, keeping voice below the committed information rate (CIR)

• Avoiding and managing network congestion—Ensuring that the LAN and WAN infrastructure can support the volume of data traffic and voice calls

• Shaping network traffic—Using Cisco traffic-shaping tools to ensure smooth and consistent delivery of frames to the WAN

• Setting traffic priorities across the network—Marking the voice traffic as priority traffic and queuing it first

Cisco routers support multiple QoS mechanisms that can be leveraged to accomplish the objectives listed in the preceding bullet points. The following sections detail specific QoS mechanisms and caution against poor design characteristics.

Using QoS to Improve Voice Quality

Voice features that provide QoS are deployed at different points in the network and are designed for use with other QoS features to achieve specific goals, such as minimization of jitter and delay. Cisco IOS includes a complete set of features for delivering QoS throughout the network. Following are a few examples of Cisco IOS features that address the voice packet delivery requirements of end-to-end QoS and service differentiation:

• The output queue of the router can use the following QoS mechanisms:

• — Class-based weighted fair queuing (CBWFQ)—Extends the standard Weighted Fair Queuing (WFQ) functionality by providing support for user-defined traffic classes. You can create a specific class for voice traffic by using CBWFQ.

  — Low latency queuing (LLQ)—Provides strict priority queuing in conjunction with CBWFQ. LLQ configures the priority status for a class within CBWFQ, in which voice packets receive priority over all other traffic. LLQ is considered a "best practice" by the Cisco Enterprise Solutions Engineering (ESE) group for delivering voice QoS services over a WAN.

  — Weighted fair queuing (WFQ)—Segregates traffic into flows and then schedules traffic to meet specified bandwidth allocation or delay bounds.

  — Weighted random early detection (WRED)—Provides differentiated performance characteristics for different classes of service. Specifically, WRED drops lower-priority traffic more aggressively than higher-priority traffic, as an interface's output queue begins to become congested.

• The WAN or WAN protocol can use the following QoS mechanisms:

• — Class-based policing —Provides a rate-limiting feature for allocating bandwidth commitments and bandwidth limitations to traffic sources and destinations. At the same time, it specifies policies for handling the traffic that might exceed bandwidth allocation.

  Note - Class-based policing typically replaces the rate-limiting feature previously provided by the committed access rate (CAR) feature.

  — Traffic shaping—Delays excess traffic by using a buffer or queuing mechanism to hold packets and shape the flow when the data rate of the source is higher than expected.

  — Frame Relay Forum 12 (FRF.12)—Ensures predictability for voice traffic by providing better throughput on low-speed Frame Relay links (that is, link speeds less than 768 kbps). FRF.12 interleaves delay-sensitive voice traffic with fragments of a long frame.

  — Multilink PPP (MLP)—Allows large packets to be multilink encapsulated, fragmented, and interleaved so that they are small enough to satisfy the delay requirements of real-time traffic.

VoIP traffic can use the following QoS mechanisms:

— Compressed Real-Time Transport Protocol (cRTP)—The Real-Time Transport Protocol (RTP) is a protocol for the transport of real-time traffic, including voice. RTP uses extensive headers that incorporate time stamps for individual packets. The cRTP feature compresses the extensive RTP header. The result is decreased consumption of available bandwidth for voice traffic and a corresponding reduction in delay.

— Resource Reservation Protocol (RSVP)—RSVP supports the reservation of resources across an IP network, allowing end systems to request QoS guarantees from the network. For networks that support VoIP, RSVP—in conjunction with features that provide queuing, traffic shaping, and voice call signaling—provides Call Admission Control (CAC) for voice traffic.

Recognizing Common Design Faults

Successful implementations of delay-sensitive applications such as VoIP require a network that is carefully engineered with QoS from end to end. Fine-tuning the network to adequately support VoIP involves a series of protocols and features geared toward improving voice quality.

QoS is the ability of a network to provide better service levels to selected network traffic over various underlying technologies. However, QoS is not inherent in a network infrastructure. Instead, QoS is implemented by strategically enabling appropriate QoS features throughout the network.

Poor design is characterized by the following issues:

• Ignoring Layer 2 QoS requirements—QoS technologies such as priority Layer 2 congestion management, FRF.12, Link Fragmentation and Interleaving (LFI), and traffic shaping must be correctly configured.

• Ignoring other QoS requirements—QoS technologies such as LLQ, RTP, congestion management, and congestion avoidance must be enabled.

• Ignoring bandwidth considerations—Planning for the total number of calls and their effect on data bandwidth is critical to all users of the network.

• Simply adding VoIP to an existing IP network—When considering VoIP, network administrators might need to insist on a complete network redesign for a comprehensive end-to-end solution.

Many people believe that the fastest way to fix network performance is simply to add a lot of bandwidth. That approach might work well in certain situations like campus networks, in which upgrading from 10 Mbps to 100 Mbps or even 1 GB links might be possible. However, it is not always feasible to add bandwidth in a WAN. Upgrading a WAN circuit from 56 kbps to T1 might be cost prohibitive and might not be possible for certain locations on the network. To provide effective performance in a voice network, you should configure QoS throughout the network, not just on the devices running VoIP. Not all QoS techniques are appropriate for all network routers. Edge routers and backbone routers in a network do not necessarily perform the same operations. The QoS tasks these routers perform might differ as well. To configure an IP network for real-time voice traffic, you should consider the functions of both edge and backbone routers and select the appropriate QoS tools accordingly.

AutoQoS

Cisco AutoQoS minimizes the complexity, time, and operating cost of QoS deployment. Cisco AutoQoS incorporates value-added intelligence into Cisco IOS software and Cisco Catalyst Operating System software to provision and manage large-scale QoS deployments. This section focuses on the Cisco IOS implementation of AutoQoS, on both router and Catalyst switch platforms.

AutoQoS Features

To expedite QoS deployment, the user interface must be simplified. Cisco AutoQoS addresses this issue by automating the following five main aspects of QoS deployment while maintaining a tunable solution:

• Application classification—Cisco AutoQoS identifies VoIP control and bearer traffic. Cisco AutoQoS uses Cisco Discovery Protocol (CDP) to ensure that the device attached to the LAN is really an IP phone.

• Policy generation—Cisco AutoQoS evaluates the network environment and automatically generates an initial policy on a given interface, port, or permanent virtual circuit (PVC).

• Configuration—With one command, Cisco AutoQoS configures a port to prioritize voice traffic without affecting other network traffic, while still offering the flexibility to adjust QoS settings for unique network environments. QoS settings are automatically disabled when a Cisco IP phone is relocated or moved.

• Monitoring and reporting—Cisco AutoQoS provides visibility into the classes of service deployed via system logging and SNMP traps.

• Consistency—Cisco AutoQoS policies are designed to work in harmony with each other across Cisco devices, ensuring consistent end-to-end QoS.

The increased deployment of delay-sensitive applications in networks (for example, voice, video, and other multimedia applications) requires proper QoS configuration to ensure application performance.

Before the availability of Cisco AutoQoS, proper QoS configuration of a network required a deep understanding of various QoS features (that is, queuing, dropping, traffic conditioning, queue depth, drop thresholds, burst parameters, LFI, and RTP). The use of Cisco AutoQoS helps minimize the complexity of configuring a network correctly for QoS by automatically configuring a device with the correct QoS parameters. Cisco AutoQoS automates consistent deployment of QoS features across Cisco routers and switches. It enables various Cisco QoS components based on the network environment and Cisco best-practice recommendations.

Users can subsequently tune parameters generated by Cisco AutoQoS to suit their particular application needs.

Cisco AutoQoS can perform the following functions on WAN interfaces:

• Automatically classifies RTP payload and VoIP control packets (H.323, H.225 Unicast, Skinny Client Control Protocol [SCCP], session initiation protocol [SIP], and Media Gateway Control Protocol [MGCP])

• Builds service policies for VoIP traffic that are based on Cisco's Modular QoS Command-Line Interface (MQC) configuration approach

• Provisions LLQ priority queuing for VoIP bearer and bandwidth guarantees for control traffic

• Enables WAN traffic shaping that adheres to Cisco best practices, where required

• Enables link efficiency mechanisms, such as LFI and RTP header compression (cRTP), where required

• Provides SNMP and syslog alerts for VoIP packet drops

Cisco AutoQoS can perform the following functions on LAN interfaces:

• Enforce the trust boundary on Cisco Catalyst switch access ports, uplinks, and downlinks

• Enable Cisco Catalyst strict priority queuing (also known as expedite queuing) with weighted round-robin (WRR) scheduling for voice and data traffic, where appropriate

• Configure queue admission criteria (that is, maps Layer 2 CoS priority markings in incoming packets to the appropriate queues)

• Modify queue sizes and weights where required