A. QoS refers to the ability of a network to provide better service to selected network traffic over various underlying technologies including Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet and 802.1 networks, SONET, and IP-routed networks.

QoS is a collection of technologies which allows applications to request and receive predictable service levels in terms of data throughput capacity (bandwidth), latency variations (jitter), and delay. In particular, QoS features provide better and more predictable network service by the following methods:

• Supporting dedicated bandwidth.

• Improving loss characteristics.

• Avoiding and managing network congestion.

• Shaping network traffic.

• Setting traffic priorities across the network.

The Internet Engineering Task Force (IETF) defines the following two architectures for QoS:

• Integrated Services (IntServ)

• Differentiated Services (DiffServ)

IntServ uses the Resource Reservation Protocol (RSVP) to signal explicitly the QoS needs of an application's traffic along the devices in the end-to-end path through the network. If every network device along the path can reserve the necessary bandwidth, the originating application can begin transmitting. Request for Comments (RFC) 2205 defines RSVP, and RFC 1633 defines IntServ.

DiffServ focuses on aggregated and provisioned QoS. Instead of signaling an application's QoS requirements, DiffServ uses a DiffServ Code Point (DSCP) in the IP header to indicate the required QoS levels. Cisco IOS® Software Release 12.1(5)T introduced DiffServ compliance on Cisco routers. For more information, refer to the following documents:

A. An interface experiences congestion when it is presented with more traffic than it can handle. Network congestion points are strong candidates for Quality of Service (QoS) mechanisms. The following is an example of typical congestion points:

A. MQC stands for modular Quality of Service (QoS) Command Line Interface (CLI). It is designed to simplify the configuration of QoS on Cisco routers and switches by defining a common command syntax and resulting set of QoS behaviors across platforms. This model replaces the previous model of defining unique syntaxes for each QoS feature and for each platform.

The MQC contains the following three steps:

1. Define a traffic class by issuing the class-map command.

2. Create a traffic policy by associating the traffic class with one or more QoS features by issuing the policy-map command.

3. Attach the traffic policy to the interface, subinterface, or Virtual Circuit (VC) by issuing the service-policy command.

Note: You implement the traffic conditioning functions of DiffServ, such as marking and shaping, using the MQC syntax.

A. On Versatile Interface Processors (VIPs) in a Cisco 7500 Series, only distributed Quality of Service (QoS) features are supported as of Cisco IOS 12.1(5)T, 12.1(5)E, and 12.0(14)S. Enabling distributed Cisco Express Forwarding (dCEF) automatically enables distributed QoS.

Non-VIP interfaces, known as legacy Interface Processors (IPs), support central QoS features as enabled on the Route Switch Processor (RSP). For more information, refer to the following documents:

A. Cisco IOS routers use the following two mechanisms to prioritize control packets:

• IP precedence

• pak_priority

A. QoS pre-classification enables you to match on and classify the original IP header contents of packets undergoing tunnel encapsulation and/or encryption. This feature does not describe the process of copying the original value of the Type of Service (ToS) byte from the original packet header to the tunnel header. For more information, refer to the following documents:

A. The class-based marking feature allows you to set or mark the layer 2, layer 3 or Multiprotocol Label Switching (MPLS) header of your packets. For more information, refer to the following documents:

A. Yes. Network Based Application Recognition (NBAR) allows you to classify packets by matching on fields at the application layer. Prior to the introduction of NBAR, the most granular classification was layer 4 Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) port numbers. For more information, refer to the following documents:

A. Queueing is designed to accommodate temporary congestion on a network device's interface by storing excess packets in buffers until bandwidth becomes available. Cisco IOS routers support several queueing methods to meet the varying bandwidth, jitter, and delay requirements of different applications.

The default mechanism on most interfaces is First In First Out (FIFO). Some traffic types have more demanding delay/jitter requirements. Thus, one of the following alternative queueing mechanisms should be configured or is enabled by default:

• Weighted Fair Queueing (WFQ)

• Class-Based Weighted Fair Queueing (CBWFQ)

• Low Latency Queueing (LLQ), which is in fact CBWFQ with a Priority Queue (PQ) (known as PQCBWFQ)

• Priority Queueing (PQ)

• Custom Queueing (CQ)

A. Fair queueing seeks to allocate a fair share of an interface's bandwidth among active conversations or IP flows. It classifies packets into subqueues, identified by a conversation identification number, using a hashing algorithm based on several fields of the IP header and the length of the packet. The following is how the weight is calculated:

• W=K/(precedence +1)

K= 4096 with Cisco IOS 12.0(4)T and earlier releases, and 32384 with 12.0(5)T and later releases.

The lower the weight, the higher the priority and the share of the bandwidth. In addition to the weight, the length of the packet is taken into account.

CBWFQ allows you to define a class of traffic and assign it a minimum bandwidth guarantee. The algorithm behind this mechanism is WFQ, which explains the name. To configure CBWFQ, you define specific classes in map-class statements. Then you assign a policy to each class in a policy-map. This policy-map will then be attached outbound to an interface. For more information, refer to the following documents:

A. Yes. Although the bandwidth guarantees provided by issuing the bandwidth and priority commands have been described with words like "reserved" and "bandwidth to be set aside", neither command implements a true reservation. Meaning, if a traffic class is not using its configured bandwidth, any unused bandwidth is shared among the other classes.

A. The priority and bandwidth commands differ in both functionality and in which applications they typically support. The following table summarizes these differences:

A. Assuming sufficient SRAM on the VIP or FlexWAN, the queue limit is calculated based on a maximum delay of 500ms with average packet size of 250 bytes. The following is an example of a class with one Mbps of bandwidth:

Queue limit = 1000000 / (250 x 8 x 2) = 250

Smaller queue limits are assigned as the amount of available packet memory decreases and with a larger number of Virtual Circuits (VCS).

In the following example, a PA-A3 is installed in a FlexWAN card for the Cisco 7600 Series and is supporting multiple subinterfaces with 2 MB Permanent Virtual Circuits (PVCs). The service policy is applied to each VC.

class-map match-any XETRA-CLASS 
  match access-group 104 
class-map match-any SNA-CLASS 
  match access-group 101 
  match access-group 102 
  match access-group 103 
policy-map POLICY-2048Kbps 
  class XETRA-CLASS 
    bandwidth 320 
  class SNA-CLASS 
    bandwidth 512 

interface ATM6/0/0 
 no ip address 
 no atm sonet ilmi-keepalive 
 no ATM ilmi-keepalive 
! 
interface ATM6/0/0.11 point-to-point 
 mtu 1578 
 bandwidth 2048 
 ip address 22.161.104.101 255.255.255.252 
 pvc ABCD 
  class-vc 2048Kbps-PVC 
  service-policy out POLICY-2048Kbps

The Asynchronous Transfer Mode (ATM) interface gets a queue limit for the entire interface. The limit is a function of total available buffers, the number of physical interfaces on the FlexWAN, and the maximum queueing delay allowed on the interface. Each PVC gets a portion of the interface limit based on the PVC's Sustained Cell Rate (SCR) or Minimum Cell Rate (MCR), and each class gets a portion of the PVC limit based on its bandwidth allocation.

The following sample output of the show policy-map interface command is derived from a FlexWAN with 3687 global buffers. Issue the show buffer command to see this value. Each two Mbps PVC is allocated 50 packets based on the PVC bandwidth of two Mbps (2047/149760 x 3687 = 50). Each class is then allocated a portion of the 50, as shown in the following output:

service-policy output: POLICY-2048Kbps
    class-map: XETRA-CLASS (match-any) 
      687569 packets, 835743045 bytes 
      5 minute offered rate 48000 bps, drop rate 6000 BPS 
      match: access-group 104 
        687569 packets, 835743045 bytes 
        5 minute rate 48000 BPS 
      queue size 0, queue limit 7 
      packets output 687668, packet drops 22 
      tail/random drops 22, no buffer drops 0, other drops 0 
      bandwidth: kbps 320, weight 15 
 
    class-map: SNA-CLASS (match-any) 
      2719163 packets, 469699994 bytes 
      5 minute offered rate 14000 BPS, drop rate 0 BPS 
      match: access-group 101 
        1572388 packets, 229528571 bytes 
        5 minute rate 14000 BPS 
      match: access-group 102 
        1146056 packets, 239926212 bytes 
        5 minute rate 0 BPS 
      match: access-group 103 
        718 packets, 245211 bytes 
        5 minute rate 0 BPS 
      queue size 0, queue limit 12 
      packets output 2719227, packet drops 0 
      tail/random drops 0, no buffer drops 0, other drops 0 
      bandwidth: kbps 512, weight 25 
      queue-limit 100 
 
    class-map: class-default (match-any) 
      6526152 packets, 1302263701 bytes 
      5 minute offered rate 44000 BPS, drop rate 0 BPS 
      match: any 
        6526152 packets, 1302263701 bytes 
        5 minute rate 44000 BPS 
      queue size 0, queue limit 29 
      packets output 6526840, packet drops 259 
      tail/random drops 259, no buffer drops 0, other drops 0

A. Use the following commands to monitor queueing:

A. The following diagram illustrates the key difference. Traffic shaping retains excess packets in a queue and then schedules the excess for later transmission over increments of time. The result of traffic shaping is a smoothed packet output rate. In contrast, traffic policing propagates bursts. When the traffic rate reaches the configured maximum rate, excess traffic is dropped (or remarked). The result is an output rate that appears as a saw-tooth with crests and troughs.

A. A traffic policer does not buffer excess packets and transmit them later, as is the case for a shaper. Instead, the policer executes a simple send or do not send policy without buffering. During periods of congestion, since you cannot buffer, the best you can do is drop packets less aggressively by properly configuring extended burst. Therefore, it is important to understand the policer uses the normal burst and extended burst values to ensure the configured Committed Information Rate (CIR) is reached.

The burst parameters are loosely modeled on the generic buffering rule for routers. The rule recommends configuring buffering equal to the round-trip time bitrate to accommodate the outstanding Transmission Control Protocol (TCP) windows of all connections in times of congestion.

The following table describes the purpose and the recommended formula for the normal and extended burst values:

CIR [BPS] * 
(1 byte)/(8 bits) * 
1.5 seconds

2 * normal burst

Not all platforms use or support the same range of values for a policer. Refer to the following document to learn the supported values for your specific platform:

A. A traffic policer uses the normal burst and extended burst values to ensure the configured CIR is reached. Setting sufficiently high burst values is important to ensuring good throughput. If the burst values are configured too low, the achieved rate may be much lower than the configured rate. Punishing temporary bursts can have a strong adverse impact on throughput of Transmission Control Protocol (TCP) traffic. With CAR, issue the show interface rate-limit command to monitor the current burst and determine whether the displayed value is consistently close to the limit (BC) and extended limit (Be) values.

rate-limit 256000 7500 7500 conform-action continue exceed-action drop 
rate-limit 512000 7500 7500 conform-action continue exceed-action drop 

router# show interfaces virtual-access 26 rate-limit 
    Virtual-Access26 Cable Customers 
      Input 
        matches: all traffic 
          params:  256000 BPS, 7500 limit, 7500 extended limit 
          conformed 2248 packets, 257557 bytes; action: continue 
          exceeded 35 packets, 22392 bytes; action: drop 
          last packet: 156ms ago, current burst: 0 bytes 
          last cleared 00:02:49 ago, conformed 12000 BPS, exceeded 1000 BPS 
      Output 
        matches: all traffic 
          params:  512000 BPS, 7500 limit, 7500 extended limit 
          conformed 3338 packets, 4115194 bytes; action: continue 
          exceeded 565 packets, 797648 bytes; action: drop 
          last packet: 188ms ago, current burst: 7392 bytes 
          last cleared 00:02:49 ago, conformed 194000 BPS, exceeded 37000 BPS

For more information, refer to the following documents:

A. Frame Relay Traffic Shaping, which you enable by issuing the frame-relay traffic-shaping command, supports several configurable parameters. These parameters include frame-relay cir, frame-relay mincir, and frame-relay BC. Refer to the following documents for more information on selecting these values and understanding related show commands:

A. As of Cisco IOS 12.1(5)T, only the distributed version of QoS features are supported on VIPs in the Cisco 7500 Series. To enable traffic shaping on Frame Relay interfaces, use Distributed Traffic Shaping (DTS). For more information, refer to the following documents:

A. As of Cisco IOS 12.2, ATM interfaces support service policies at three levels or logical interfaces: main interface, subinterface, and Permanent Virtual Circuit (PVC). Where you apply the policy is a function of the Quality of Service (QoS) feature that you are enabling. Queueing policies should be applied per Virtual Circuit (VC) since the ATM interface monitors the congestion level per VC, and maintains queues for excess packets per VC. For more information, refer to the following documents:

A. The bandwidth and priority commands configured in a service policy to enable class-based weighted fair queueing (CBWFQ) and low latency queueing (LLQ), respectively, use a Kbps value that counts the same overhead bytes as are counted by the show interface command output. Specifically, the layer 3 queueing system counts Logical Link Control / Subnetwork Access Protocol (LLC/SNAP). It does not count the following:

A. The following document provides useful guidelines on the number of Asynchronous Transfer Mode (ATM) VCS that can support. About 200 to 300 VBR-nrt Permanent Virtual Circuits (PVCs) have been safely deployed:

A. IP to ATM COs refers to a set of features that are enabled on a per-Virtual Circuit (VC) basis. Given this definition, IP to ATM COs is not supported on the ATM Interface Processor (AIP), PA-A1 or 4500 ATM network processors. This ATM hardware does not support per-VC queueing as the PA-A3 and most network modules (other than the ATM-25) define it. For more information, refer to the following document:

A. Interactive traffic such as Telnet and Voice over IP is susceptible to increased latency when the network processes large packets such as File Transfer Protocol (FTP) transfers over a WAN. Packet delay for interactive traffic is significant when the FTP packets are queued on slower WAN links. A method was devised for fragmenting larger packets, and queueing the smaller (voice) packets between the fragments of the larger packets (FTP) packets. Cisco IOS routers support several layer 2 fragmentation mechanisms. For more information, refer to the following documents: