Latency, Jitter, and Packet Loss

Latency is the delay packets’ experience when traversing across many different network devices. Jitter is similar to latency in that it is also a delay, but jitter is a variable of the latency that occurs over a period of time. If every packet sent between phone A and phone B took the exact same amount of time to traverse the network, there would be no jitter, but there could still be a delay. When the time between when packets are delivered is different, that time variance is referred to as jitter. Jitter can be overcome with buffers, but that will add to the overall latency that occurs. Packet loss refers to packets being dropped by the router due to congestion on a link. As mentioned before, TCP packets are drop insensitive because they will be retransmitted if an acknowledgment is not received by the initiating application. By contrast, UDP packets, such as voice and video, will not be retransmitted and are therefore drop sensitive.

Bandwidth

Bandwidth capacity limitations come into play when multiple flows through the router compete for limited bandwidth. QoS is not a substitute for bandwidth, and increasing the available bandwidth will not solve all these problems either. Before bandwidth issues can be resolved, an engineer needs to calculate the bandwidth being consumed across the network. Based on the information covered earlier in this book, calculating bandwidth consumption for voice and video is relatively easy.

To calculate bandwidth requirements for voice-only traffic, an engineer must first identify the codecs being used. Other codecs may be chosen to control or limit bandwidth consumption. Although the actual codec being used is the most important parameter in this assessment, it is still very important to know about packetization and the technologies that will be used. The payload size is comparable to the header size. The more packets being sent and the shorter the packetization time, the more overhead is being consumed. If the G.711 codec, which consumes 64 kbps bandwidth, is being used with a packetization period of 20 ms, and the voice payload is 160 bytes at 50 packets per second, the bandwidth for the call is 87.2 kbps. However, this calculation does not factor in the Layer 2 or Layer 3 overhead. If we take the overhead into account, the total bandwidth being consumed will be even higher. Some QoS tools also affect overhead bandwidth, such as Compressed Real-time Transport Protocol (cRTP) and link fragmentation and interleaving (LFI), but they will be discussed later in this chapter. All packets being equal, there are definitive bit counts to the Layer 2 and Layer 3 headers. Figure 13-1 illustrates the total bandwidth calculations for a G.711 call with Layer 2 and Layer 3 overhead included.

Calculating the bandwidth for a video call is similar to an audio call, except the math required for calculating the overhead is much simpler. First, an engineer must specify the codec being used along with the resolution of the call. These two factors together determine the bandwidth and compression of the video call. The codec alone cannot determine the bandwidth used for a video call, nor can the resolution alone. A user can place a video call at 720p30 using H.263 and will consume 1152 kbps bandwidth. The same call can be placed using the 720p30 resolution and the H.264 codec and consume only 768 kbps bandwidth. However, if the H.264 codec is used for a 480p30 call, the bandwidth required could range anywhere between 256 kbps and 512 kbps.

Another consideration when calculating bandwidth for a video call is that the total bandwidth allocated for the call is for both audio and video. If you were to place a 384 kbps call using the G.711 codec for audio and H.264 codec for video, 64 kbps would be allocated to audio, leaving 320 kbps for video. In that same call, if G.722 were used at 48 kbps, 336 kbps bandwidth would be available for video.

Once you know the total bandwidth available for the call and the codecs being used for audio and video, you can break down the Layer 2 and Layer 3 headers for audio and video separately and then add the total bandwidth back together. There is an easier way to calculate total bandwidth consumption for video calls. Simply add in 20 percent to the payload bandwidth for overhead. So, a 768 kbps call will consume approximately 922 kbps bandwidth with overhead. A 384 kbps call will consume 460 kbps bandwidth with overhead. You can do the math the long way, but you will find the actual numbers are very close to 20 percent overhead.

Once the bandwidth consumption has been calculated per call, some simple math based on actual call volume will determine the overall bandwidth consumed via voice and video communications. Determining the other limitations within a network will require other assessments of the network itself. A proper QoS design begins with a network audit and a business audit to determine the type of traffic that is running on the network and then determine the QoS requirements for the different types of traffic. Once that has been accomplished, the next step is to group the traffic into classes with similar QoS requirements. The third step occurs at the WAN Aggregation layer: to define QoS policies that will meet the QoS requirements for each traffic class.

4/5 Class Model

The 4/5 class model is the simplest of the three models in terms of QoS polices and typically accounts for real-time communications, call signaling, critical data, best-effort data, and scavenger data. The call signaling and critical data are often grouped together as a “mission-critical” category, thus this model is called the 4/5 class model. There could be four or five classes depending on how services are grouped together. The mission-critical class can also be used for multimedia conferencing, multimedia streaming, and bulk data applications. The 4/5 class model is commonly used within small and medium-sized businesses (SMB) that have deployed VoIP telephony. The five traffic classes of QoS markings and guarantees are as follows:

• Real Time: Typically voice-only communications. Marked with EF and provisioned to leverage up to 33 percent of link bandwidth.

• Call Signaling: Marked with CS3 and provisioned to leverage a minimum of 7 percent of link bandwidth.

• Critical Data: Marked with AF31 and provisioned to leverage 35 percent of link bandwidth. When Signaling and Critical Data are combined, CS3 is used across the board.

• Best Effort Data: Marked with DF and provisioned to take advantage of 25 percent of link bandwidth.

• Scavenger: Marked with CS1 and provisioned to utilize any unused available link bandwidth. The Scavenger class does not have bandwidth directly provisioned, so packets marked CS1 will be sent only if bandwidth is available and will be the first packets to drop during high congestion times.

Voice and signaling guarantees must be selected based on the volume of voice calls and the VoIP codec that is used through the given link. Mission-critical data is selected based on the decision of the director of each company department who has given info about critical business application needs to the networking team. Platform-specific constraints or service-provider constraints may affect the number of classes of service. Businesses should consider a migration strategy to allow the number of classes to be smoothly expanded as future needs arise.

8 Class Model

As needs arise, businesses might need to expand their service groups to the 8 class model, which builds on the 4/5 class model by dividing three of the classes into two more granular classes each. The additions to this model include splitting the Real Time class into two distinct classes: Voice and Video. The Critical Data class is divided into Network Control and Critical Data. The explicitly defined Network Control traffic class is used for applications such as network routing protocol updates or network infrastructure control traffic such as operations, administration, and maintenance (OAM). Finally, the Best Effort class is divided into Bulk Data and Best Effort classes. The recommendations for each traffic class in this model are as follows:

• Voice: Marked with EF and limited to 10 percent of link bandwidth in a strict-priority queue.

• Video: Marked with AF41 or sometimes as EF and limited to 23 percent of link bandwidth in a strict-priority queue.

• Call Signaling: Marked CS3 and provisioned with a minimum of 2 percent of link bandwidth.

• Network Control: Marked with CS2 and provisioned with a minimum of 5 percent of link bandwidth.

• Critical Data: Marked with AF31 and provisioned with 25 percent of link bandwidth.

• Bulk Data: Marked with AF11 and provisioned with 10 percent of link bandwidth with WRED enabled.

• Best Effort: Marked with DF and provisioned with 25 percent of link bandwidth.

• Scavenger: Marked with CS1 and provisioned to utilize any unused available link bandwidth. The Scavenger class does not have bandwidth directly provisioned, so packets marked CS1 will be sent only if bandwidth is available and will be the first packets to drop during high congestion times.

Although Cisco does recommend configuring call signaling with CS3, some legacy Cisco Unified IP phone products still mark call signaling to AF31. Cisco has been working on a marking migration from AF31 to CS3 with its newer Cisco Unified IP phone models, but some businesses that use older phone models may still want to reserve both AF31 and CS3 for call signaling. In these cases, the critical data applications should be marked to a temporary placeholder nonstandard DSCP, such as 25. After companies migrate their phones to the newer IP phone models, the QoS Baseline marking recommendations of CS3 for call signaling and AF31 for critical data applications should be used.

QoS Baseline Model (11 Class)

Cisco has adopted a new initiative called the QoS Baseline. The QoS Baseline is a strategic document designed to unify QoS within Cisco, from enterprise to service provider and from engineering to marketing. The QoS Baseline was written by Cisco’s most qualified QoS experts, who have developed or contributed to the related IETF RFC standards and as such are supremely qualified to interpret these standards. The QoS Baseline also provides uniform, standards-based recommendations to help ensure that QoS designs and deployments are unified and consistent. You can see the “QoS Baseline at a Glance” document at the following link: https://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295a9b.pdf. Several books that go into more detailed information about this model also are available.

The QoS Baseline defines up to 11 classes of traffic that might be viewed as critical to a given enterprise. The 11 class QoS Baseline model builds on the 8 class model, and represents Cisco’s interpretation of the RFC 4594 recommendation, which outlines 12 different classes of traffic. The recommendations for each traffic class in this model are as follows:

• Voice: Refers to voice only, and it is marked with EF and limited to 10 percent of link bandwidth in a strict-priority queue.

• Interactive Video: Refers to voice and video, and it is marked with AF41 or sometimes as EF and limited to 13 percent of link bandwidth.

• Streaming Video: Marked with CS4 or sometimes as EF and limited to 10 percent of link bandwidth.

• Call Signaling: Marked with CS3 and provisioned with a minimum of 2 percent of link bandwidth.

• IP Routing: Marked with CS6 and limited to 3 percent of link bandwidth.

• Network Management: Marked with CS2 and provisioned as guaranteed 2 percent of link bandwidth.

• Mission Critical Data: Marked with AF31 and provisioned with 15 percent of link bandwidth.

• Transactional Data: Marked with AF21 and provisioned with 10 percent of link bandwidth with Weighted Random Early Detection (WRED) enabled.

• Bulk Data: Marked with AF11 and provisioned with 10 percent of link bandwidth with WRED enabled.

• Best Effort Data: Marked with 0 and provisioned with 25 percent of link bandwidth.

• Scavenger: Marked with CS1 and provisioned to utilize any unused available link bandwidth. The Scavenger class does not have bandwidth directly provisioned, so packets marked CS1 will be sent only if bandwidth is available and they will be the first packets to drop during high congestion times.

Enterprises do not need to deploy all 11 classes of the QoS Baseline model. This model is intended to be a forward-looking guide that considers as many classes of traffic with unique QoS requirements as possible. Familiarity with this model can assist in the smooth expansion of QoS policies to support additional applications as future requirements arise. However, at the time of QoS deployment, the enterprise needs to clearly define its organizational objectives, which will correspondingly determine how many traffic classes will be required.

This consideration should be tempered with the determination of how many application classes the networking administration team feels comfortable with deploying and supporting. Platform-specific constraints or service-provider constraints may also affect the number of classes of service. At this point, you should also consider a migration strategy to allow the number of classes to be smoothly expanded as future needs arise. Figure 13-2 illustrates the strategy Cisco recommends for expanding the number of classes of service over time.

QoS Trust Boundaries

When it comes to QoS, it is best practice to mark packets as close to the source as possible. Most devices, such as computers and servers, cannot mark their own packets and should not be trusted even if they can. Cisco phones, however, can mark their own packets and can be trusted with the QoS markings they provide. Therefore, QoS trust boundaries should be set up so that the switch will trust the QoS markings that phones place on their own packets. Layer 2 QoS uses a mechanism called class of service (CoS), which operates on the 802.1Q VLAN. Unlike Layer 3 QoS mechanisms, CoS does not ensure network performance or guarantee priority in packets being delivered. Therefore, after packets are marked with CoS, they will need to be converted to DSCP using the cos-to-dscp map, which is built into all Cisco switches. By default, QoS on a Cisco access switch is disabled. Once enabled, the switch does not trust QoS settings from a phone. Two simple commands can be entered under the global menu on a switch to enable QoS and change the trust boundary. Once it is enabled, you can use a show command to verify these settings. Example 13-1 illustrates the QoS enable and trust boundary commands and the show verification command.

Example 13-1 QoS Enable and Trust Boundary Commands

Click here to view code image

Switch(config)# mls qos
Switch(config)# interface fastethernet 0/1
Switch(config-if)# mls qos trust cos
Switch(config-if)# end
Switch# show mls qos interface fastethernet 0/1
FastEthernet0/1
trust state: trust cos
trust mode: trust cos
cos override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none

Obviously, this is the simplest design, and there are many other concerns to consider, along with many other settings that can be configured. This example is intended to provide a basic understanding of QoS at the Layer 2 level. For more information on QoS, refer to the “Enterprise QoS Solution Reference Network Design Guide” available at https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book.html.

Congestion Management

The WAN presents the greatest potential to be a bottleneck point within an enterprise network. WAN Internet speeds are usually much slower than LAN speeds; however, the network switches use hardware-based buffers, which compared to the interface speed are much smaller than those found on WAN interfaces in routers. This merely increases the potential for even short-lived traffic bursts on the LAN to cause buffer overflow and dropped packets. For these reasons, different QoS tools are available at the WAN than what exist within the LAN; however, all of these tools work together to provide an overall QoS implementation that has been carefully designed. The content that follows examines some of the key concepts to a proper QoS implementation.

Three models of QoS can be implemented in a Cisco network design:

• Best Effort model: This model uses no QoS and does not guarantee that packets will be delivered. Obviously, this is not the model most companies would choose to implement.

• IntServ model: This model uses RSVP to guarantee predictable behavior on the network for applications that have specific bandwidth and delay requirements.

• DiffServ model: This model operates on classes that require special QoS treatment. It is the model that has been discussed up to this point and will continue to be the focus of this dialogue. QoS components used in the DiffServ model include classification, marking, congestion management, congestion avoidance, policing and shaping, and link efficiency.

Classification was discussed previously in the examination of class models. Markings were discussed briefly with class models and Layer 2 CoS marking and Layer 2 to Layer 3 conversion mapping. A detailed explanation of these markings is available later in the section titled “>Traffic Classifications.”

Congestion management mechanisms use the marking on each packet to determine in which queue to place packets. Different queues are given different treatment by the queueing algorithm that is based on the class of packets in the queue. Generally, queues with high-priority packets receive preferential treatment. The Cisco IOS software for congestion management, or queuing, includes the following queuing methods:

• First-In First-Out (FIFO): Performs no prioritization of data packets on user data traffic. It entails no concept of priority or classes of traffic. When FIFO is used, ill-behaved sources can consume available bandwidth, bursty sources can cause delays in time-sensitive or important traffic, and important traffic may be dropped because less important traffic fills the queue.

• Priority Queue (PQ): Guarantees strict priority in that it ensures that one type of traffic will be sent, possibly at the expense of all others. For PQ, a low-priority queue can be detrimentally affected, and, in the worst case, never allowed to send its packets if a limited amount of bandwidth is available or if the transmission rate of critical traffic is high.

• Custom Queuing (CQ): Guarantees some level of service to all traffic because bandwidth can be allocated to all classes of traffic. You can define the size of the queue by determining its configured packet-count capacity, thereby controlling bandwidth access.

• Weighted Fair Queuing (WFQ): Does not require configuration of access lists to determine the preferred traffic on a serial interface. Rather, the fair queue algorithm dynamically sorts traffic into messages that are part of a conversation.

• Class-Based Weighted Fair Queuing (CBWFQ): Provides class bandwidth guarantee for user-defined traffic classes. It provides flow-based WFQ support for nonuser-defined traffic classes.

• Low-Latency Queuing (LLQ): A congestion management mechanism developed by Cisco to bring strict priority queuing (PQ) to Class-Based Weighted Fair Queuing (CBWFQ). LLQ allows delay-sensitive data, such as voice and video, to be given preferential treatment over other traffic by letting this data be dequeued and sent first.

Congestion Avoidance

Congestion avoidance mechanisms monitor network traffic loads in an effort to anticipate and avoid congestion at common network bottlenecks. Congestion avoidance is achieved through packet dropping. Congestion avoidance mechanisms are typically implemented on output interfaces where a high-speed link feeds into a lower-speed link, such as a LAN feeding into a WAN. Weighted Random Early Detection (WRED) is an early detection congestion avoidance mechanism that ensures high-precedence traffic has lower loss rates than other traffic during times of congestion. WRED is not recommended for voice and video queues, and the network should not be designed to drop voice and video packets.

Policing

Policing is used to condition traffic before transmitting or receiving through the network. Policing controls traffic bursts by marking or dropping packets when predefined limits are reached. Policing mechanisms can drop traffic classes that have lower QoS priority markings. Policing tools include class-based policing and committed access rate (CAR). CAR services limit the input or output transmission rate on an interface or subinterface based on a flexible set of criteria.

Shaping

Shaping mechanisms are used on output interfaces to help smooth out mismatches in the network and limit transmission rates. Although these mechanisms are typically used to limit the flow from a high-speed link to a low-speed link, shaping could also be used to manage the flow of traffic at a point in the network where multiple flows are aggregated. Cisco IOS software uses two traffic-shaping tools called Generic Traffic Shaping (GTS) and Frame Relay Traffic Shaping (FRTS) to manage traffic and congestion on the network.

Link Efficiency Methods

Link efficiency methods reduce the overhead that is associated with voice and video transportation. These bandwidth-saving mechanisms, such as compression and link fragmentation and interleaving (LFI), help support large amounts of traffic over a slower link. Compression is one of the link efficiency mechanisms that work in conjunction with queuing and traffic shaping to manage existing bandwidth more efficiently and predictably. Two types of compression are available. Compression of the payload of Layer 2 frames can be implemented using the Stacker or Predictor algorithm. The other compression available is cRTP, which can compress the IP, UDP, and RTP headers down from 40 bytes to 2–4 bytes. Compression should be used only on slow WAN links because the drawback is the consumption of computational resources on a hop-by-hop basis. Another link efficiency method is link fragmentation and interleaving. Interactive traffic, such as voice and video, is susceptible to increased latency and jitter when the network processes large packets. This susceptibility increases as the traffic is queued on slower links. LFI can reduce delay and jitter on slower-speed links by breaking up large data packets and interleaving low-delay traffic packets with the resulting smaller packets. LFI is typically used on slow WAN links to ensure minimal delay for voice and video traffic. Figure 13-3 summarizes all of the QoS components needed for an efficient network deployment.

LAN and WAN Traffic Classifications

As mentioned previously, Layer 2 classification uses CoS markings for packets at the Access layer. The Distribution and Core layers use the existing CoS markings to map QoS to Layer 3 classifications. These Layer 3 classifications include differentiated services code point (DSCP), per hop behavior (PHB), and type of service (ToS) or IP Precedence (IPP). Table 13-2 summarizes each of these classifications and how they map to one another for different applications.

In Table 13-2, voice only and voice with video traffic are separated into two different categories. The reason for this is so that when a video call is placed, both voice and video packets reach the destination at roughly the same time. There is no support for lip synchronization in SIP, so this will help preserve lip-syncing during the call. Also, when a video call is placed, the expectation is that both the voice and video media will share the same quality during the call. These reasons are why Cisco recommends deploying QoS in this manner. Notice, however, that this table is slightly different from the QoS Baseline model, although there are 11 classes in both design models. Table 13-2 provides a classification for Voice/Video and another for Telepresence Video. Cisco offers different endpoints that will utilize different QoS classifications based on type. Based on Cisco’s current endpoint portfolio, the Voice/Video applications include the 8845, 8865, and Jabber client endpoints. If you have a DX endpoint running the legacy Android software, it would fall under this category too. The Telepresence Video applications include all endpoints running CE or CTS software, including the DX, MX, SX, IX, and Webex endpoints.

After packets have been classified for Layer 2 and Layer 3, the next step is to queue traffic based on the classification. Transmit interface buffers within a campus tend to congest in small, finite intervals as a result of the bursty nature of network traffic. When this congestion occurs, any packets destined for that transmit interface are dropped. The only way to prevent dropped voice traffic is to configure multiple queues on campus switches. By enabling multiple queues on campus switches, you can configure all voice traffic to use separate queues, thus virtually eliminating the possibility of dropped voice packets when an interface buffer fills instantaneously. For this reason, Cisco recommends always using a switch that has at least two output queues on each port and the ability to send packets to these queues based on QoS Layer 2 or Layer 3 classification. The majority of Cisco Catalyst switches support two or more output queues per port.

WLAN Traffic Classifications

Just as QoS is necessary for the LAN and WAN wired network infrastructure in order to ensure high voice and video quality, QoS is also required for the wireless LAN infrastructure. Because of the bursty nature of data traffic and the fact that real-time traffic such as voice and video are sensitive to packet loss and delay, QoS tools are required to manage wireless LAN buffers; limit radio contention; and minimize packet loss, delay, and delay variation. Unlike most wired networks, however, wireless networks are a shared medium, and wireless endpoints do not have dedicated bandwidth for sending and receiving traffic. While wireless endpoints can mark traffic with 802.1p CoS, ToS, DSCP, and PHB, the shared nature of the wireless network means limited admission control and access to the network for these endpoints.

As with the wired network infrastructure, it is important to classify or mark pertinent wireless traffic as close to the edge of the network as possible. Because traffic marking is an entrance criterion for queuing schemes throughout the wired and wireless network, marking should be done at the wireless endpoint device whenever possible. Marking or classification by wireless network devices should be identical to that for wired network devices. In accordance with traffic classification guidelines for wired networks, the Cisco wireless endpoints mark voice media traffic or voice RTP traffic with DSCP 46 (or PHB EF), video media traffic or video RTP traffic with DSCP 34 (or PHB AF41), and call control signaling traffic (SCCP or SIP) with DSCP 24 (or PHB CS3). Once this traffic is marked, it can be given priority of better than best-effort treatment and queuing throughout the network. All wireless voice and video devices that are capable of marking traffic should do so in this manner. All other traffic on the wireless network should be marked as best-effort or with some intermediary classification as outlined in wired network marking guidelines. If the wireless voice or video devices are unable to do packet marking, alternate methods such as port-based marking should be implemented to provide priority to video and voice traffic.

While 802.1p and differentiated services code point (DSCP) are the standards to set priorities on wired networks, 802.11e is the standard used for wireless networks. This is commonly referred as user priority (UP), and it is important to map the UP to its appropriate DSCP value. Table 13-3 compares the 802.11e QoS values compared to wired QoS values.

After traffic marking has occurred, it is necessary to enable the wired network access points (APs) and devices to provide QoS queuing so that voice and video traffic types are given separate queues to reduce the chances of this traffic being dropped or delayed as it traverses the wireless LAN. Queuing on the wireless network occurs in two directions: upstream and downstream. Upstream queuing concerns traffic traveling from the wireless endpoint up to the AP, and from the AP up to the wired network. Downstream queuing concerns traffic traveling from the wired network to the AP and down to the wireless endpoint.

For upstream queuing, devices that support Wi-Fi Multimedia (WMM) are able to take advantage of queueing mechanisms, including priority queueing. As for downstream QoS, Cisco APs currently provide up to eight queues for downstream traffic being sent to wireless clients. The entrance criterion for these queues can be based on a number of factors, including DSCP, access control lists (ACLs), and VLAN. Although eight queues are available, Cisco recommends using only two queues when deploying wireless voice. All voice media and signaling traffic should be placed in the highest-priority queue, and all other traffic should be placed in the best-effort queue. This ensures the best possible queuing treatment for voice traffic.

To set up this two-queue configuration for autonomous APs, you can create two QoS policies on the AP. Name one policy Voice and configure it with the class of service Voice < 10 ms Latency (6) as the Default Classification for all packets on the VLAN. Name the other policy Data and configure it with the class of service Best Effort (0) as the Default Classification for all packets on the VLAN. Then assign the Data policy to the incoming and outgoing radio interface for the data VLAN(s) and assign the Voice policy to the incoming and outgoing radio interfaces for the voice VLAN(s). With the QoS policies applied at the VLAN level, the AP is not forced to examine every packet coming in or going out to determine the type of queuing the packet should receive.

For lightweight APs, the WLAN controller has built-in QoS profiles that can provide the same queuing policy. Voice VLAN or voice traffic is configured to use the Platinum policy, which sets priority queueing for the voice queue. Data VLAN or data traffic is configured to use the Silver policy, which sets best-effort queuing for the Data queue. These policies are then assigned to the incoming and outgoing radio interfaces based on the VLAN. The preceding configurations ensure that all voice and video media and signaling are given priority queuing treatment in a downstream direction.

To avoid exceeding the capacity limit of a given AP channel, some form of call admission control is required. Cisco APs and wireless Unified Communications clients now use Traffic Specification (TSPEC) instead of QoS Basic Service Set (QBSS) for call admission control. Wi-Fi Multimedia Traffic Specification (WMM TSPEC) is the QoS mechanism that enables WLAN clients to provide an indication of their bandwidth and QoS requirements so that APs can react to those requirements. When a client is preparing to make a call, it sends an Add Traffic Stream (ADDTS) message to the AP with which it is associated, indicating the TSPEC. The AP can then accept or reject the ADDTS request based on whether bandwidth and priority treatment are available. If the call is rejected, the client receives a Network Busy message. If the client is roaming, the TSPEC request is embedded in the reassociation request message to the new AP as part of the association process, and the TSPEC response is embedded in the reassociation response. Alternatively, endpoints without WMM TSPEC support, but using SIP as call signaling, can be managed by the AP. Media snooping must be enabled for the Service Set Identifier (SSID). The client’s implementation of SIP must match that of the wireless LAN controller, including encryption and port numbers.

Class Map

Traffic classification and traffic marking are closely related and can be used together. Traffic marking can be viewed as an additional action, specified in a policy map, to be taken on a traffic class. Traffic classification allows you to organize packets into traffic classes on the basis of whether the traffic matches specific criteria. For example, all traffic with a CoS value of 2 is grouped into one class, and traffic with DSCP value of 3 is grouped into another class. The match criterion is user defined.

After the traffic is organized into traffic classes, traffic marking allows you to mark an attribute for the traffic belonging to that specific class. For instance, you may want to change the CoS value from 2 to 1, or you may want to change the DSCP value from 3 to 2. The match criteria used by traffic classification are specified by configuring a match command in a class map. The marking action taken by traffic marking is specified by configuring a set command in a policy map. These class maps and policy maps are configured using the MQC.

The following commands explain how to create a class map to define traffic classes. Within the class map, the appropriate match command is used to specify the matching criteria for the traffic classes. To create the class map and specify the matching criteria, complete the following steps:

Click here to view code image

Router> enable

Router# configure terminal

Router(Config)# class-map class-map-name

From this point, you can use a few options available within the class map to establish the search criterion against which packets are checked to determine if they belong to the class. Table 13-4 identifies four of these criteria.

Policy Map

As previously mentioned, creating a table map is not required unless the desired outcome is to change some of the CoS or DSCP values. The table map contains the mapping scheme used for establishing the to-from relationship and equivalency between one traffic-marking value and another. The table map can be configured for use with multiple policy maps. The policy maps can then be configured to convert and propagate the traffic-marking values defined in the table map. Then the policy maps can be attached to the input or output interface of either the ingress or egress router, as appropriate, to serve the QoS requirements of your network. To create and configure the table map, enter the following MQC commands:

Click here to view code image

Router> enable

Router# configure terminal

Router# table-map name map from from-value to to-value
        [default default-action-or-value]

To configure a policy map and create class policies that make up the service policy, begin with the policy-map command to specify the policy map name. Then use one or more of the following commands to configure the policy for a standard class or the default class:

• priority

• bandwidth

• queue-limit or random-detect

• fair-queue (for class-default class only)

For each class that you define, you can use one or more of the commands listed to configure the class policy. For example, you might specify bandwidth for one class and both bandwidth and queue limit for another class. The default class of the policy map, commonly known as the class-default class, is the class to which traffic is directed if that traffic does not satisfy the match criteria of the other classes defined in the policy map.

You can configure class policies for as many classes as are defined on the router, up to the maximum of 64. However, the total amount of bandwidth allocated for all classes in a policy map must not exceed the minimum committed information rate (CIR) configured for the virtual circuit (VC) minus any bandwidth reserved by the frame-relay voice bandwidth and frame-relay ip rtp priority commands. If the minimum CIR is not configured, the bandwidth defaults to one-half of the CIR. If all of the bandwidth is not allocated, the remaining bandwidth is allocated proportionally among the classes on the basis of their configured bandwidth.

The following commands describe how to create and configure a policy map to use the class map and the table map. The policy map applies the appropriate QoS feature to the network traffic based on the traffic classification. To configure class policies in a policy map, use the MQC commands described in the following sections.

Click here to view code image

Router> enable

Router# configure terminal

Router(Config)# policy-map name

Router(Config-pmap)# class {class-name | class-default}

Router(Config-pmap-c)# set cos cos-value

or

Click here to view code image

Router(Config-pmap-c)# set cos dscp table name

The policy-map name command creates a policy map by the name provided and enters the policy-map configuration mode. The class command specifies the name of the class whose policy you want to create and enters policy-map class configuration mode. This class is associated with the class map created earlier. You can either enter the name of the class created earlier or enter the class-default keyword. The class-default class is used to classify traffic that does not fall into one of the defined classes. Even though the class-default class is predefined when you create the policy map, you still have to configure it. If a default class is not configured, then traffic that does not match any of the configured classes is given best-effort treatment, which means that the network will deliver the traffic if it can, without any assurance of reliability, delay prevention, or throughput. The set cos command and set cos dscp table name commands are examples of the set commands that can be used when marking traffic. Other set commands can be used as well. For a list of other set commands, refer to the “Cisco IOS Quality of Service Solutions Configuration Guide” at Cisco.com.

Other class policies can be configured here as well. To configure a class policy for a priority queue, enter the following command:

Click here to view code image

Router (config-pmap-c)# priority bandwidth in kbps

This command creates a strict priority class and specifies the amount of bandwidth in kbps to be assigned to the class.

To configure a class policy using a specified bandwidth, enter the following command:

Click here to view code image

Router (config-pmap-c)# bandwidth bandwidth in kbps

This command specifies the amount of bandwidth to be assigned to the class in kbps, or as a percentage of the available bandwidth. Bandwidth must be specified in kbps or as a percentage consistently across classes. Bandwidth of the priority queue must be specified in kbps.

To configure a class policy that specifies a number of queues, enter the following command:

Click here to view code image

Router (config-pmap-c)# fair-queue number-of-dynamic-queues

This command specifies the number of dynamic queues to be reserved for use by flow-based WFQ running on the default class. The number of dynamic queues is derived from the bandwidth of the interface.

You can create and configure as many policy maps as you need for your network. To create and configure additional policy maps, repeat the preceding commands per your network deployment plan. After all the policy maps have been created, they will need to be attached to the appropriate interface. The next section on service policy will explain how to attach the policy maps to the interfaces.

Service Policy

After you create the policy map, you must attach it to an interface. Policy maps can be attached to either the input or output direction of the interface. Depending on the needs of your network, you can attach policy maps to an interface, a subinterface, or an ATM permanent virtual circuit (PVC). To attach the policy map, enter the following commands in the MQC:

Click here to view code image

Router> enable

Router# configure terminal

Router(Config)# interface type number [name-tag]

Router(Config-if)# service-policy {input | output}
policy-map-name

This last command is the key. It attaches the specified service policy map to the output interface and enables LLQ, assuming LLQ has been configured throughout this process. Next, all these QoS settings will need to be verified.

Verify and Monitor LLQ Settings

After the QoS designs have been finalized and the proof of concept tested, it is vital to ensure that the networking team thoroughly understand the QoS features and syntax before enabling features on production networks. Such knowledge is critical for both rollout and subsequent troubleshooting of QoS-related issues. Furthermore, it is recommended to schedule network downtime in order to roll out QoS features. While QoS is required end-to-end, it does not have to be deployed end-to-end at a single instance. A pilot network-segment can be selected for an initial deployment, and pending observation, the rollout can be expanded in stages to encompass the entire enterprise. A rollback strategy is always recommended, to address unexpected issues arising from the QoS deployment.

From the Privileged Exec Mode on the router, you can use several show commands to verify that all the QoS settings have been configured correctly. Table 13-5 illustrates these show commands with a description of what information each command displays.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 32, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep Software Online.