Implementing Quality of Service Over Cisco MPLS VPNs

The LAN Edge: L2 Configurations

Framing this in the context of a sample configuration, the switch device at the edge of the network has the following policy applied:

Depending on the switch model, it may be necessary to first activate QoS using this command:

switch(config)#mls qos

This command is required on both the Catalyst 3550 and the Catalyst 6500. The Catalyst 2950 has QoS enabled by default.

The trust is configured on the switch port using this command:

switch(config-if)#mls qos trust dscp

Any ISL or 802.1Q/p frames that enter the switch port have their CoS passed (untouched) through the switch. If an untagged frame arrives at the switch port, the switch assigns a default CoS to the frame before forwarding it. By default, untagged frames are assigned a CoS of 0. This can be changed using this interface configuration command:

switch(config-if)#mls qos cos default-cos

where default-cos is a number between 0 and 7.

The syntax to configure QoS trust switch-wide for IP phone endpoints is all that is required in typical installations:

Switch(config-if)#mls qos trust device ciscoipphone

Here's the legacy syntax that was required on a per-VLAN basis:

Switch(config-if)#switchport voice vlan {vlan-id | dot1p | none | untagged}

To instruct the Cisco IP Phone to forward all voice traffic through a specified VLAN, use this command:

Switch(config-if)#switchport voice vlan vlan-id

By default, the Cisco IP Phone forwards the voice traffic with an 802.1Q priority of 5. Valid VLAN IDs are from 1 to 4096.

An alternative to specifying a particular voice VLAN on the switch is to instruct the switch port to use 802.1P priority tagging for voice traffic and to use the default native VLAN (VLAN 0) to carry all traffic. By default, if enabled, the Cisco IP Phone forwards the voice traffic with an 802.1P priority of 5.

Switch(config-if)#switchport voice vlan dot1p

In some cases, it may be desirable—indeed, highly recommended—not to trust edge CoS for nonvoice/video endpoints and not to trust any CoS value that may be present in frames sourced from an edge device. For example, an office PC used for general applications, such as web browsing, e-mail, and file and print services, may not require special QoS treatment. Allowing it to request higher levels of QoS may adversely affect applications such as voice and video, which require guarantees of bandwidth and latency.

For this reason, it is possible to use the override parameter to tell the switch to ignore any existing CoS value that may be in the frame and apply the default value. This effectively disables any trust configuration that may have previously been applied to the port.

The CoS value assigned by the switch can be changed on a port-by-port basis using this interface configuration command:

Switch(config-if)#mls qos cos override

After this command is applied, the switch rewrites the CoS value for all incoming frames to the configured default value, regardless of any existing CoS value.

Other platforms, such as those that employ CatOS, vary. You should always verify such a reference to the correct procedure by reviewing the relevant documentation at http://www.cisco.com. For example, the following is an overview of configuring prioritization, with a 6500 platform running CatOS between Cisco CallManager and IP phones and gateways using TCP ports 2000 to 2002. The sample commands classify all Skinny Protocol traffic from IP phones and gateways (VLAN 110) and Cisco CallManager (4/2) as DSCP AF31, which is backward-compatible with IPP 3.

With older implementations, several steps need to be performed (see Example 5-1):

Example 5-1 Setup of a Catalyst Edge Switch (L2 Only)

cat6k-access> (enable) set qos enable
cat6k-access> (enable) set qos acl ip ACL_IP-PHONES dscp 26 tcp any any range 2000
 2002
cat6k-access> (enable) set qos acl ip ACL_IP-PHONES trust-cos ip any any
cat6k-access> (enable) set qos acl ip ACL_VOIP_CONTROL dscp 26 tcp any any range
 2000 2002
cat6k-access> (enable) set port qos 5/1-48 trust trust-cos
cat6k-access> (enable) set port qos 5/1-48 vlan-based
cat6k-access> (enable) set port qos 5/1-48 trust-ext untrusted
cat6k-access> (enable) set port qos 4/2 port-based
cat6k-access> (enable) commit qos acl all
cat6k-access> (enable) set qos acl map ACL_IP-PHONES 110
cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/2

Classifying Voice on the WAN Edge

A basic configuration of a WAN edge (CE) router is shown in Example 5-2 and defined further in this section. This applies the principles in base configuration terms, as discussed previously.

In this case, you apply a simple LLQ and CBWFQ policy to the router to support voice traffic. Voice traffic needs to be assigned to the LLQ, and voice-control traffic needs a minimum bandwidth guarantee.

Example 5-2 Matching Voice and Voice Control

ip cef
!
class-map match-all VOICE
 match ip dscp ef
!
class-map match-all VOICE-CONTROL
 match ip dscp cs3
 match ip dscp af31
!
!
policy-map WAN-EDGE
 class VOICE
 priority percent 33
 class VOICE-CONTROL
 bandwidth percent 5
 class class-default
 fair-queue
!
interface Serial0/0
 description WAN Link to CCT ID : 1234 :: SP-PE-1
 bandwidth 2048
 ip address 10.1.1.1 255.255.255.252
 service-policy output WAN-EDGE

The class map applied to VOICE and VOICE-CONTROL provides an example of matching against DSCP markings, which in this case are for the voice-bearer traffic and the voice signaling and control traffic. In this basic policy, you assume that no marking of traffic needs to happen directly on this box. Rather, it deals only with the outbound classification of the traffic.

In the policy map itself, in effect you assign three elements—those of prioritization for voice and specified as a percentage of the link bandwidth. This is an example of applying LLQ. Voice control specifies the allocation of 5 percent of link bandwidth for voice control, with the final classification being performed as class default, which uses the fair-queuing algorithm on the remaining traffic. In this case, it is assumed to be the default class.

The key to activating this policy is to attach the service-policy output to an interface—in this case, the output interface facing the SP PE. Thus, applying the classification actions as defined in the policy map WAN-EDGE to the output of the WAN serial interface provides this activation.

Classifying Video on the WAN Edge

In Example 5-3, videoconferencing traffic is assigned LLQ, and all nonvideo traffic is assigned to a default queue for WFQ.

Example 5-3 Matching Video

ip cef
!
class-map match-all VIDEO
 match ip dscp af41
!
!
policy-map WAN-EDGE
 class VIDEO-CONF
 priority 460
 class class-default
 fair-queue
!
interface Serial0/0
 description WAN Link to CCT ID : 1234 :: SP-PE-1
 bandwidth 2048
 ip address 10.1.1.1 255.255.255.252
 service-policy output WAN-EDGE

On the WAN edge, videoconferencing traffic should be assigned to an LLQ. The video stream minimum bandwidth guarantee should be the size of the stream plus 20 percent.

As before, this policy doesn't take effect until it is bound to an interface with a service-policy statement.

Classifying Data on the WAN Edge

Most enterprises have many applications that can be considered mission-critical (trans-actional). However, if too many applications are classified as mission-critical, they will contend among themselves for bandwidth, with the result of dampening QoS effectiveness. Taken to the extreme, a regular FIFO link (no QoS) is scheduled in the exact same manner as a link where every application is provisioned as mission-critical. Therefore, it is recommended that you classify no more than three applications as mission-critical (transactional).

These applications should be marked with different AF drop-preference values to distinguish them from each other. Such distinctions provide more granular visibility in managing and monitoring application traffic and aid in provisioning for future require-ments. Similar arguments are made for having no more than three applications in a guaranteed bandwidth (bulk data) class of applications and, likewise, marking these applications with different AF drop-preference values.

Default traffic is automatically marked as best-effort (DSCP 0). However, noncritical bandwidth-intensive traffic could (optionally) be marked as different so that adverse policies could be applied to control such traffic. These types of traffic can be described as "less-than-best-effort" or "scavenger" traffic.

It is imperative that DSCP classification be performed on all packets before they arrive at the WAN edges. In this manner, queuing and congestion avoidance can be performed at the WAN edge based strictly on DSCP markings.

The Eight-Class Model introduces a dual-LLQ design: one for voice and another for interactive video. As pointed out earlier in this chapter, the LLQ has an implicit policer that allows for time-division multiplexing of the single priority queue. This implicit policer abstracts the fact that there is essentially a single LLQ within the algorithm and thus allows for the "provisioning" of multiple LLQs.

Interactive video (or IP videoconferencing, also called IP/VC) is recommended to be marked AF41 (which can be marked down to AF42 in the case of dual-rate policing at the campus access edge). It is recommended that you overprovision the LLQ by 20 percent of the IP/VC rate. This takes into account IP/UDP/RTP headers as well as Layer 2 overhead. Additionally, Cisco IOS Software automatically includes a 200-ms burst parameter (defined in bytes) as part of the priority command. On dual-T1 links, this has proven sufficient for protecting a single 384-kbps IP/VC stream. On higher-speed links (such as triple T1s), the default burst parameter has shown to be insufficient for protecting multiple IP/VC streams.

However, multiple-stream IP/VC quality tested well with the burst set to 30,000 bytes (for example, priority 920 30000). Our testing did not arrive at a clean formula for predicting the required size of the burst parameters as IP/VC streams continually were added. However, given the variable packet sizes and rates of these interactive-video streams, this is not surprising. The main point is that the default LLQ burst parameter might require tuning as multiple IP/VC streams are added (which likely will be a trial-and-error process).

Optionally, DSCP-based WRED can be enabled on the Interactive-Video class, but testing has shown negligible performance difference in doing so (because, as has been noted, WRED is more effective on TCP-based flows than UDP-based flows, such as interactive video). In these designs, WRED is not enabled on classes such as Call-Signaling, IP Routing, and Network-Management because WRED would take effect only if such classes were filling their queues nearly to their limits. Such conditions would indicate a provision-ing problem that would be better addressed by increasing the class's minimum bandwidth allocation than by enabling WRED.

Additionally, the Eight-Class Model subdivides the preferential data class to separate control plane traffic (IP routing and network-management applications) from business-critical data traffic. IGP packets (such as RIP, EIGRP, OSPF, and IS-IS) are protected through the PAK_priority mechanism within the router. However, EGP protocols, such as BGP, do not get PAK_priority treatment and might need explicit bandwidth guarantees to ensure that peering sessions do not reset during periods of congestion. Additionally, administrators might want to protect network-management access to devices during periods of congestion.

The other class added to this model is for bulk traffic (the Bulk Data class), which is spun off of the Critical Data class. Because TCP continually increases its window sizes, which is especially noticeable in long sessions (such as large file transfers), constraining bulk data to its own class alleviates other data classes from being dominated by such large file transfers. Bulk data is identified by DSCP AF11 (or AF12 in the case of dual-rate policing at the campus access edges). DSCP-based WRED can be enabled on the Bulk Data class (and also on the Critical Data class). Example 5-4 shows the implementation of the Eight-Class Model for the WAN edge.

Example 5-4 Eight-Class Model

!
class-map match-all Voice
 match ip dscp ef ! IP Phones mark Voice to EF
class-map match-all Interactive Video
 match ip dscp af41 af42 ! Recommended markings for IP/VC
class-map match-any Call Signaling
 match ip dscp cs3 ! Future Call-Signaling marking
 match ip dscp af31 ! Current Call-Signaling marking
class-map match-any Network Control
 match ip dscp cs6 ! Routers mark Routing traffic to CS6
 match ip dscp cs2 ! Recommended marking for Network Management
class-map match-all Critical Data
 match ip dscp af21 af22 ! Recommended markings for Transactional-Data
class-map match-all Bulk Data
 match ip dscp af11 af12 ! Recommended markings for Bulk-Data
class-map match-all Scavenger
 match ip dscp cs1 ! Scavenger marking
!
policy-map WAN-EDGE
 class Voice
 priority percent 18 ! Voice gets 552 kbps of LLQ
 class Interactive Video
 priority percent 15 ! 384 kbps IP/VC needs 460 kbps of LLQ
 class Call Signaling
 bandwidth percent 5 ! BW guarantee for Call-Signaling
 class Network Control
 bandwidth percent 5 ! Routing and Network Management get min 5% Bandwidth
 class Critical Data
 bandwidth percent 27 ! Critical Data gets min 27% BW
 random-detect dscp-based ! Enables DSCP-WRED for Critical-Data class
 class Bulk Data
 bandwidth percent 4 ! Bulk Data gets min 4% BW guarantee
 random-detect dscp-based ! Enables DSCP-WRED for Bulk-Data class
 class Scavenger
 bandwidth percent 1 ! Scavenger class is throttled to 1% of bandwidth
 class class-default
 bandwidth percent 25 ! Fair-queuing is sacrificed for Bandwidth guarantee
 random-detect ! Enables WRED on class-default
!

This design is more efficient than strict policing, because these bandwidth-intensive noncritical applications can use additional bandwidth if it is available while ensuring protection for critical transactional data classes and real-time voice and video applications.

The development of this model is attributed to Tim Szigeti from the Cisco Enterprise Solutions Engineering Group.

For more information on this approach, go to

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/ccmigration_09186a008049b062.pdf.