qos_hrhqf
QoS---Hierarchical Queueing Framework (HQF)
Downloads: This chapterpdf (PDF - 218.0KB) | Feedback

QoS Hierarchical Queueing Framework

Table Of Contents

QoS Hierarchical Queueing Framework

Finding Feature Information

Contents

Prerequisites for QoS Hierarchical Queueing Framework

Restrictions for QoS Hierarchical Queueing Framework

Information About QoS Hierarchical Queueing Framework

Background of QoS Hierarchical Queueing Framework

Functions of QoS Hierarchical Queueing Framework

Benefits of QoS Hierarchical Queueing Framework

New Functionality in QoS Hierarchical Queueing Framework

Behavioral Changes in QoS Hierarchical Queueing Framework

How to Configure QoS Hierarchical Queueing Framework

Configuring a Service Policy

Attaching an MQC Policy to a Map Class

Verifying the HQF Configuration

Configuration Examples for QoS Hierarchical Queueing Framework

Example: Configuring QoS Hierarchical Queueing Framework

Example: Verifying the HQF Configuration

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance

Feature Information for QoS Hierarchical Queueing Framework


QoS Hierarchical Queueing Framework


First Published: March 16, 2006
Last Updated: March 22, 2011

The QoS Hierarchical Queueing Framework (HQF) feature enables you to manage quality of service (QoS) at three different levels—the physical interface level, the logical interface level, and the class level of scheduling for applying QoS queueing and shaping mechanisms by using the modular QoS command-line interface (CLI) (MQC) to provide a granular and flexible overall QoS architecture.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for QoS Hierarchical Queueing Framework" section.

Use Cisco Feature Navigator to find information about platform support and software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.

Contents

Prerequisites for QoS Hierarchical Queueing Framework

Restrictions for QoS Hierarchical Queueing Framework

Information About QoS Hierarchical Queueing Framework

How to Configure QoS Hierarchical Queueing Framework

Configuration Examples for QoS Hierarchical Queueing Framework

Additional References

Feature Information for QoS Hierarchical Queueing Framework

Prerequisites for QoS Hierarchical Queueing Framework

Configure MQC in your network.

Restrictions for QoS Hierarchical Queueing Framework

Service policies with queueing features cannot coexist on child and parent interfaces, such as tunnel and physical interfaces, or subinterface and physical interfaces, simultaneously.

Information About QoS Hierarchical Queueing Framework

To use the QoS Hierarchical Queueing Framework feature, you should understand the following concepts:

Background of QoS Hierarchical Queueing Framework

Functions of QoS Hierarchical Queueing Framework

Benefits of QoS Hierarchical Queueing Framework

New Functionality in QoS Hierarchical Queueing Framework

Behavioral Changes in QoS Hierarchical Queueing Framework

Background of QoS Hierarchical Queueing Framework

MQC provides the means for you to configure QoS using a generic CLI applicable to all types of interfaces and protocols. MQC builds configurations that depend on HQF for queueing and shaping.

For example, to support Frame Relay, extensions to the HQF mechanism were required so that fragmentation could be provided within the queueing framework. These extensions enable priority queueing (PQ) configurations to be set up to support latency-sensitive traffic.

Functions of QoS Hierarchical Queueing Framework

HQF provides queueing and shaping capabilities. HQF is a logical engine used to support QoS features. The HQF hierarchy is a tree structure that is built using policy maps.

When data passes through an interface using HQF, the data is classified so that it traverses the branches of the tree. Data arrives at the top of the tree and is classified on one of the leaves. Data then traverses down the hierarchy (tree) until it is transmitted out the interface at the root (trunk).

For example, the following configuration builds the hierarchy shown in Figure 1:

policy-map class
 class c1
  bandwidth 14
 class c2
  bandwidth 18

policy-map map1
 class class-default
  shape average 64000
  service-policy class

policy-map map2
 class class-default
  shape average 96000

map-class frame-relay fr1
 service-policy output map1

map-class frame fr2
 service-policy output map2

interface serial4/1
 encapsulation frame-relay
 frame-relay interface-dlci 16
  class fr1
 frame-relay interface-dlci 17
  class fr2

Figure 1 HQF Tree Structure

Benefits of QoS Hierarchical Queueing Framework

The QoS Hierarchical Queueing Frameworkfeature provides the following benefits:

Faster deployment of QoS queueing and shaping in large-scale networks.

Consistent queueing behavior applied with common MQC CLI across all main Cisco IOS software releases, making implementation of QoS easier and transparent regardless of the Cisco IOS software release being used.

Common functionality for both distributed and non-distributed implementations, providing consistency of QoS feature behavior across all software-forwarding hardware, thus making implementation of QoS easier and transparent regardless of the platform being used.

Behavioral consistency across hardware, resulting in accelerated delivery of feature enhancements and new QoS features in different Cisco IOS software releases.

Multiple levels of packet scheduling.

Support for integrated class-based shaping and queueing.

The ability to apply fair queueing and drop policies on a per-class basis.

New Functionality in QoS Hierarchical Queueing Framework

The QoS Hierarchical Queueing Framework feature introduces the following functionality:

Hierarchical Policy with Queueing Features at Every Level

You can apply class-based queueing to any traffic class in the parent or child level of a hierarchical policy and obtain service levels for different sessions or subscribers.

In the example shown below, the traffic belonging to class parent-c2 has more scheduling time than class parent-c1:

policy-map child
 class child-c1
  bandwidth 400
 class child-c2
  bandwidth 400

policy-map parent
 class parent-c1 <------------------
  bandwidth 1000
  service-policy child
 class parent-c2 <------------------
  bandwidth 2000
  service-policy child

Shaping in an ATM PVC Policy

You can apply class-based shaping within an ATM PVC as shown in the following example:

policy-map p1
 class c1
  shape average 1000000
 class c2
  shape average 1000000

interface atm1/0.1
 pvc 1/100
  service-policy output p1

policy-map p1
 class c1
  shape average 1000000
 class c2
  shape average 1000000

interface atm1/0.1
 pvc 1/100
  service-policy output p1

Child Policy in a Priority Class

You can apply a child policy to a class with priority enabled as shown in the following example. The child policy can contain police or set features, but not queueing features.

policy-map p1
 class c1
  priority 256
  service-policy child

Behavioral Changes in QoS Hierarchical Queueing Framework

The QoS Hierarchical Queueing Framework feature introduces the following behavioral changes in some QoS features:

Flow-Based Fair-Queueing Support in Class-Default

The fair-queueing behavior for the class-default class is flow-based. This is a change from the weighted fair queueing (WFQ) behavior in previous releases. With flow-based fair queueing, the flow queues in the class-default class are scheduled equally instead of by weight based on the IP Precedence bits.

Default Queueing Implementation for Class-Default

When you do not explicitly configure the class-default class in a policy map, its default queueing behavior is FIFO. You can configure the bandwidth, fair-queue, or service-policy commands in the class-default class to achieve different queueing behaviors.

Class-Default and Bandwidth

The bandwidth assigned to the class-default class is the unused interface bandwidth not consumed by user-defined classes. By default, the class-default class receives a minimum of 1% of the interface bandwidth.

Default Queueing Implementation for Shape Class

When you configure the shape command in a class, the default queueing behavior for the shape queue is FIFO instead of weighted fair queueing (WFQ). You can configure the bandwidth, fair-queue, or service-policy commands in shape class to achieve different queueing behaviors.

Policy Map and Interface Bandwidth

In HQF, a policy map can reserve up to 100 percent of the interface bandwidth. If you do not assign an explicit bandwidth guarantee to the class-default class, you can assign a maximum of 99 percent of the interface bandwidth to user-defined classes and reserve the other 1percent for the class-default class.


Note If you are migrating to Cisco IOS Release 12.4(20)T and the configured policy map allocates 100 percent of the bandwidth to the user-defined classes, an error message appears in the console after booting the HQF image. The message indicates that the allocated bandwidth exceeds the allowable amount, and the service policy is rejected. In HQF, you must reconfigure the policy to account for the minimum 1 percent bandwidth guaranteed for the class-default. Then you can apply a service policy to the interface.


Per-Flow Queue Limit in Fair Queue

In HQF, when you enable fair queuing, the default per-flow queue limit is 1/4 of the class queue limit. If you do not enable the queue limit in a class, the default per-flow queue limit is 16 packets (1/4 of 64).

Over-Subscription Support for Multiple Policies on Logical Interfaces

When you attach a shaping policy to multiple logical interfaces including a subinterface, and the sum of the shape rate exceeds the physical interface bandwidth, congestion at the physical interface results in back pressure to each logical interface policy. This back pressure causes each policy to reduce the output rate down to its fair share of the interface bandwidth.

Here is an example: 10 subinterface policies each shaped to 2 Mbps, physical interface has 10 Mbps bandwidth (2:1 oversubscription), when all 10 subinterfaces are sending at 2 Mbps, each subinterface gets a throughput of 1 Mbps (10 Mbps/10 subinterfaces).

Shaping on a GRE Tunnel

In HQF, you can apply the shaping to a generic routing encapsulation (GRE) tunnel by using a hierarchical service policy after encapsulation. This means that the shape rate is based on packets with tunnel encapsulation and L2 encapsulation.

When configuring the shape feature in the parent policy applied to the tunnel interface, you can use the class-default class only. You cannot configure a user-defined class in the parent policy.

A typical hierarchical policy applied to a GRE tunnel interface is shown below:

Interface tunnel0
Service-policy output parent

policy-map parent
 class class-default
  shape average 10000000
  service-policy child

policy-map child
 class voice
  priority 512
 class video
  bandwidth 6000
 class data
  bandwidth 3000

Note Some QoS deployments include a service policy with queueing features applied at the tunnel or a virtual interface and a service policy with queueing features applied at the physical interface. In Cisco IOS Release 12.4(20)T, you can apply a service policy with queuing features only at one of these interfaces. When migrating to Cisco IOS Release 12.4(20)T, a router configuration containing service policies at both interfaces will only keep the one applied to the physical interface.


FRF.12 and FRF.9

With HQF implementation, when you enable Frame Relay fragmentation (FRF.12) on an FR PVC or FR main interface, priority class packets are no longer subject to fragmentation. Priority packets, regardless of the packet size, always interleave among data fragments.

When you enable Frame Relay payload compression (FRF.9) on an FR PVC or main interface, priority class packets are no longer compressed. When you enable both FRF.12 and FRF.9, priority class packets are neither fragmented nor compressed.

User-Defined Classes Added to Policy Maps Attached to Logical Interfaces

A policy map may be configured with multiple user-defined classes and may contain a default class, called class-default. Optionally, a policy map may contain just the class-default, as illustrated below:

policy-map parent 
 class class-default 
 service-policy child

Typically, at this point, you would attach the policy map to the interface. After the policy map has been attached the interface, the HQF would allow you to add a user-defined class to the policy map.

However, HQF behavior has now changed so that this kind of modification is no longer permitted on a logical interface. If you want to add a user-defined class to a policy map (and that policy map has already been attached to a logical interface), you must first remove the policy map from the logical interface. Then add the user-defined class to the policy map and reattach the policy map to the logical interface.


Note This behavior change applies only to logical interfaces. It does not apply to physical interfaces.


Nested Policy and Reference Bandwidth for Child-Policy

In HQF when you configure a nested policy with a child queueing policy under a parent shaping class, the reference bandwidth for the child queueing policy is taken from the following: minimum (parent shaper rate, parent class's implicit/explicit bandwidth guarantee). When you do not define bandwidth for the parent class, the interface bandwidth divides equally among all parent classes as the implicit bandwidth guarantee.

The example below shows a nested policy applied on a serial interface of 1536 Kbps. The 1536 Kbps is equally shared, as the implicit bandwidth, among parent classes parent-c1 and class-default. For the parent class, the shaping rate of 1200 Kbps is the maximum, while the implicit guarantee of 768 Kbps is the minimum.

interface serial 0/0
service-policy parent
policy-map child
 class child-c1
 bandwidth percent 10
policy-map parent
class parent-c1
   shape average 1200000
 service-policy child

For the child policy child-c1 to take the parent shaping rate as the reference bandwidth, configure parent class parent-c1 with an explicit guarantee greater than the shaping rate. For example,

policy-map parent
class parent-c1
   bandwidth 1300
   shape average 1200000
 service-policy child

When configuring explicit bandwidth for parent classes with oversubscription, the restriction here Policy Map and Interface Bandwidth applies.

Handling Traffic Congestion on an Interface Configured with Policy Map

In Cisco IOS Release 12.4(20)T, if an interface configured with a policy map is full of heavy traffic, the implicitly defined policer allows the traffic as defined in the bandwidth statement of each traffic class. The policer is activated whenever there is traffic congestion on an interface.

How to Configure QoS Hierarchical Queueing Framework

This section contains the following procedures:

Configuring a Service Policy (required)

Attaching an MQC Policy to a Map Class (required)

Verifying the HQF Configuration (optional)

Configuring a Service Policy

SUMMARY STEPS

1. enable

2. configure terminal

3. policy-map [type access-control] policy-map-name

4. class [class-name | class-default]

5. shape [average | peak] cir [bc] [be]

6. interface type number

7. encapsulation frame-relay [cisco | ietf]

8. service-policy [type access-control] {input | output} policy-map-name

9. end

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2 

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3 

policy-map [type access-control] policy-map-name

Example:
Router(config)# policy-map shape

Specifies the name of the policy map to be created. Enters policy-map configuration mode.

The optional type access-control keywords determine the exact pattern to look for in the protocol stack of interest.

Enter the policy-map name.

Step 4 

class [class-name | class-default]

Example:

Router(config-pmap)# class class-default

Specifies the class so that you can configure or modify its policy. Enters policy-map class configuration mode.

Enter the class-name argument or the class-default keyword.

Step 5 

shape [average | peak] cir [bc] [be]

Example:

Router(config-pmap-c)# shape average 256000

Shapes traffic to the indicated bit rate according to the algorithm specified.

Enter average or peak rate shaping.

Enter the committed information rate (CIR) in bits per second (bps).

(Optional) Enter the committed burst (bc) size or the excess burst (be) size in bits.

Step 6 

interface type number

Example:

Router(config-pmap-c)# interface serial4/3

Configures the interface type specified and enters interface configuration mode.

Enter the interface type and number.

Step 7 

encapsulation frame-relay [cisco | ietf]

Example:

Router(config-if)# encapsulation frame-relay

Enables Frame Relay encapsulation on an interface.

(Optional) Enter cisco or ietf to specify the encapsulation method.

Step 8 

service-policy [type access-control] {input | output} policy-map-name

Example:
Router(config-if)# service-policy output shape

Specifies the name of the policy map to be attached to the interface.

Note You can configure policy maps on ingress or egress routers and attach them in the input or output direction of an interface. The direction (input or output) and the router (ingress or egress) to which the policy map should be attached vary according to your network configuration.

The optional type access-control keywords determine the exact pattern to look for in the protocol stack of interest.

Enter the input or output keyword followed by the policy-map name.

Step 9 

end

Example:

Router(config-if)# end

(Optional) Exits interface configuration mode.

Attaching an MQC Policy to a Map Class

SUMMARY STEPS

1. enable

2. configure terminal

3. map-class frame-relay map-class-name

4. service-policy [type access-control] {input | output} policy-map-name

5. interface type number

6. frame-relay class name

7. frame-relay interface-dlci dlci [cisco | ietf] [voice-cir cir] [ppp virtual-template-name]

8. end

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2 

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3 

map-class frame-relay map-class-name

Example:

Router(config)# map-class frame-relay shape

Specifies the name of a Frame Relay map class that is to be created or modified and enters map-class configuration mode.

Enter the map-class name.

Step 4 

service-policy [type access-control] {input | output} policy-map-name

Example:
Router(config-map-class)# service-policy output 
shape

Specifies the name of the policy map to be attached to the interface.

Note You can configure policy maps on ingress or egress routers and attach them in the input or output direction of an interface. The direction (input or output) and the router (ingress or egress) to which the policy map should be attached varies according to your network configuration.

The optional type access-control keywords determine the exact pattern to look for in the protocol stack of interest.

Enter the input or output keyword followed by the policy-map name.

Step 5 

interface type number

Example:

Router(config-map-class)# interface serial4/3

Configures the interface type specified and enters interface configuration mode.

Enter the interface type and number.

Step 6 

frame-relay class name

Example:

Router(config-if)# frame-relay class shape

Associates a map class with an interface or subinterface.

Enter the name of the map class.

Step 7 

frame-relay interface-dlci dlci [cisco | ietf] [voice-cir cir] [ppp virtual-template-name]

Example:

Router(config-if)# frame-relay interface-dlci 16

Assigns a data-link connection identifier (DLCI) to a specified Frame Relay subinterface on a router and enters Frame Relay DLCI interface configuration mode.

Enter the DLCI number.

(Optional) Enter cisco or ietf for the encapsulation type.

(Optional; supported on the Cisco MC3810 only) Enter voice-cir and cir to specify the upper limit on the voice bandwidth that may be reserved for this DLCI. The default is the committed information rate (CIR) configured for the Frame Relay map class.

(Optional) Enter ppp to enable the circuit to use PPP in Frame Relay encapsulation.

(Optional) Enter the virtual template name to specify to which virtual template interface to apply the PPP connection.

Step 8 

end

Example:

Router(config-fr-dlci)# end

(Optional) Exits Frame Relay DLCI interface configuration mode.

Verifying the HQF Configuration

SUMMARY STEPS

1. enable

2. show policy-map interface [type access-control] interface-name [vc [vpi/] vci] [dlci dlci]
[
input | output]

3. exit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

(Optional) Enables privileged EXEC mode.

Enter your password if prompted.

Note Skip this step if you are using the show command in user EXEC mode.

Step 2 

show policy-map interface [type access-control] interface-name [vc [vpi/] vci] [dlci dlci]
[input | output]

Example:

Router# show policy-map interface serial4/3

Displays the packet statistics of all classes that are configured for all service policies either on the specified interface or subinterface or on a specific PVC on the interface.

Enter the interface name.

Step 3 

exit

Example:

Router# exit

(Optional) Exits privileged EXEC mode.

Configuration Examples for QoS Hierarchical Queueing Framework

This section provides configuration examples for the QoS Hierarchical Queueing Framework feature.

Example: Configuring QoS Hierarchical Queueing Framework

Example: Verifying the HQF Configuration

Example: Configuring QoS Hierarchical Queueing Framework

There are two main tasks for configuring this feature:

Configuring a policy map

Attaching the policy map to a map class

In the following example, a policy map called shape is configured on serial interface 4/3 and attached in the output direction. Its parameters include a class class-default, a traffic shaping average of 256000 bps, and Frame Relay encapsulation.

Router# configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# policy-map shape
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape average 256000
Router(config-pmap-c)# interface serial4/3
Router(config-if)# encapsulation frame-relay
Router(config-if)# service-policy output shape
Router(config-if)# end

In the following example, the policy map called shape is attached to serial interface 4/3 in the output direction and is associated with a map class called shape. There is also a PVC being associated with DLCI 16.

Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# map-class frame-relay shape
Router(config-map-class)# service-policy output shape
Router(config-map-class)# interface serial4/3
Router(config-if)# frame-relay class shape
Router(config-if)# frame interface-dlci 16
Router(config-fr-dlci)# end

Example: Verifying the HQF Configuration

In the following example, shaping is active with HQF installed on serial interface 4/3. All traffic is classified to the class-default queue.

Router# show policy-map interface serial4/3

 Serial4/3

  Service-policy output: shape

    Class-map: class-default (match-any)
      2203 packets, 404709 bytes
      30 second offered rate 74000 bps, drop rate 14000 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 64/354/0 
      (pkts output/bytes output) 1836/337280 
      shape (average) cir 128000, bc 1000, be 1000
      target shape rate 128000
        lower bound cir 0,  adapt to fecn 0

      Service-policy : LLQ

        queue stats for all priority classes:
         
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0

        Class-map: c1 (match-all)
          0 packets, 0 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match: ip precedence 1
          Priority: 32 kbps, burst bytes 1500, b/w exceed drops: 0

        Class-map: class-default (match-any)
          2190 packets, 404540 bytes
          30 second offered rate 74000 bps, drop rate 14000 bps
          Match: any

          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 63/417/0
          (pkts output/bytes output) 2094/386300

Additional References

Related Documents

Related Topic
Document Title

Frame Relay commands: complete command syntax, command modes, command history, defaults, usage guidelines, and examples

Cisco IOS Wide-Area Networking Command Reference

QoS commands: complete command syntax, command modes, command history, defaults, usage guidelines, and examples

Cisco IOS Quality of Service Solutions Command Reference

MQC

"Applying QoS Features Using the MQC" module


Standards

Standard
Title

No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.


MIBs

MIB
MIBs Link

No new or modified MIBs are supported by this feature, and support for existing MIBs has not been modified by this feature.

To locate and download MIBs for selected platforms, Cisco Software releases, and feature sets, use Cisco MIB Locator found at the following URL:

http://www.cisco.com/go/mibs


RFCs

RFC
Title

No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.


Technical Assistance

Description
Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html


Feature Information for QoS Hierarchical Queueing Framework

Table 1 lists the release history for this feature.

Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.


Note Table 1 lists only the Cisco IOS software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.


Table 1 Feature Information for QoS Hierarchical Queueing Framework (HQF)

Feature Name
Releases
Feature Information

QoS Hierarchical Queueing Framework (HQF)

12.2(28)SB
12.4(20)T

The QoS Hierarchical Queueing Frameworkfeature enables you to manage quality of service (QoS) at three different levels—the physical interface level, the logical interface level, and the class level of scheduling for applying QoS queueing and shaping mechanisms by using the modular QoS command-line interface (CLI) (MQC) to provide a granular and flexible overall QoS architecture.

In Release 12.2(28)SB, this feature was introduced as QoS: Frame Relay QoS Hierarchical Queueing Framework Support on the Cisco 7200 Series Router.

The following commands were introduced or modified: bandwidth (policy-map class), fair-queue (WFQ), max-reserved-bandwidth, police (two rates), queue-limit, random-detect, random-detect atm-clp-based, random-detect cos-based, random-detect prec-based, random-detect precedence, shape-max buffers, show policy-map, show policy-map interface, show queue, show queueing.