Hierarchical QoS and Policies Aggregation PDF

Hierarchical QoS and Policies
Aggregation
BRKRST-2504
BRKRST-2504_c2 © 2009 Cisco Systems, Inc. All rights reserved. Cisco Public 1
Agenda
 Hierarchical QoS overview
QoS general concepts
HQoS Deployments examples
 “Traditional MQC” HQoS
MQC and HQF overview, restrictions
HQF IOS and platforms support
 Evolution : Policies Aggregation
Drivers behind policies aggregation: economy class
Policies Aggregation deep dive with QFP overview
“3 level Hierarchical QoS” with policies aggregation
Future: 4 level policies and policies aggregation
 Summary
QoS General Concepts
Why Quality of Service (QoS)
 Bandwidth optimization for voice, video and data

applications
VoIP and Video needs to meet strict SLA on delay and jitter
 Critical customers and/or applications prioritization

Enhance delivery and productivity
Financial transactions
 More Bandwidth is available but

Branch/Hubs/subscribers bottlenecks still exist
Bandwidth sharing is still needed
Why Hierarchical QoS
 Different policies at different levels ( branch, HQ, etc)

 Traffic aggregation
 Bandwidth Optimization
 Originally associated with Metro Ethernet, basic
concept has been used since ATM and FR days
Ethernet WAN
Service Provider
QFP
!!! !!!
QoS Components
 Classification
 Policing
 Marking
 Shaping*
Congestion management and
 Queuing*
Scheduling
 Link Efficiency (cRTP, fragmentation, etc.)
Scheduling and QoS
 A Qos scheduler determines when a packet will be

serviced or dequeued
Dequeuing times can be relative or absolute
Relative packet dequeue times  packet dequeue orders
e.g. Low Latency Queuing
Absolute packet dequeue times  shaping
Queuing Parameters
 Priority (priority)
Packets serviced before any other class
Two levels of priority queuing are possible in certain platforms
 Min Bandwidth (bandwidth)

Packets are serviced in the order determined by configured
bandwidth
 Max Bandwidth (Shape)

Packets are service at the configured max rate
 Excess Bandwidth (bandwidth remaining)

Excess packets are service in the order determined by
remaining rate
QoS Hierarchical Levels
Data Traffic 1st Level

3rd Level 2nd Level
Best Effort
Priority
Traffic
 Each level could represent a branch, type of traffic, etc

and each one requires a different level of service or
distinctive action
Typical Single-Level Scheduler
 Single level scheduler,

i.e. no hierarchy Physical
Interface
Scheduler determines order
of packets dequeued
Physical interface enforces
max aggregate rate across Data
Traffic
all classes Control 1st Level
Backpressure from interface priority

determines when packets
are sent
Two-Level Scheduler
 1st layer
Parent level scheduler
enforces max aggregate rate
or excess bw
Determines when
packets are sent
Data
 2nd layer Traffic Interface
1st Level
Child queuing policy 2nd Level Best
Effort
determines order in which
Multiple
packets are sent priority
traffic
Service Propagation
 Behavior defined at one layer in the hierarchy

propagates through to upper layers, enforcing SLA at
all levels
 Service propagation helps overcome the issues of
conventional scheduling implementations
 Priority Propagation:
Parent Scheduler knows that a packet was scheduled from a
Priority Entry – Preserves Priority Through Hierarchy
“Available” in software based platforms, until CPU utilization
or congestion is too high. Only specialized hardware can
really deliver priority at a very high throughput
Typical Hierarchical QoS Deployments
Traditional WAN Aggregation
with HQoS
 HQ aggregates branches HEADQUARTER

( FR, LL, ATM)
 From HQ, each branch is
shaped down to a
contracted rate, in which
VoIP or applications are
Service Provider
prioritized
 Same applies from each BRANCH
Branch towards HQ
CPE
Ethernet WAN with HQoS
 Same as before + few HEADQUARTER

extras
 Branches can subdivide
BW and share among
different services or dpts
 HQoS can be applied to Service Provider
VLAN or Sessions
directly BRANCH
CPE
DMVPN HQoS
Secure On-Demand Meshed Tunnels
 Provides full meshed and
secured connectivity with Hub
simple configuration of
hub and spoke
 Same as before, each
spoke ( GRE tunnel ) or VPN
Spoke 1
SA has to be shaped
down
 Classification can be
Spoke n Spoke 2
done based pre
DMVPN Tunnels
GRE+IPSec Traditional Static Tunnels
encapsulation Static Known IP Addresses
Dynamic Unknown IP Addresses
Typical BRAS Deployments with HQoS
BRAS for PTA
 Subscriber session could
be represented by: Internet
VLANs PE
IP/MPLS Core
PPP session LAC/LNS
PE PE
IP session
BRAS ISP 1 ISP 2
 Subscriber gets an X Aggregation
Residence Residence
Mbps service plus Voice

LNS LNS
or Video C
P
E
C
P
E
IP/MPLS
Core
LAC
Aggregation
Residence Residence
CPE CPE
MQC/HQF Overview
QoS with IOS Modular QoS CLI (MQC)
 Cisco IOS command syntax for QoS

Template-based syntax
Separates classification engine from
the policy
Uniform CLI for QoS features
Cisco Platform independent
 Hierarchical Policies are basically configured by calling

a “child” policy from within a “parent” policy, etc
Basic Hierarchical QoS with IOS MQC
Two MQC Levels
Policy-map PARENT Gig 0/1.1001
Service
class class-default Level
shape average 200000000
service-policy output CHILD
Policy-map CHILD
class EF
priority level 1
class AF4 AF1
priority level 2
class AF1 200 Mbps
bandwidth remaining ratio 9
class class-default
bandwidth remaining ratio 1 AF4
Default
Interface gigabitethernet 0/1.1001

service-policy output PARENT EF
FRTS with Hierarchical QoS
Policy-map PARENT Two MQC Levels
class class-default
shape average 128000 Ser 0/0.1
service-policy output CHILD Service
Policy-map CHILD Level
class EF
priority percent 5
class AF4
bandwidth percent 45
class AF1 AF1
class class-default 128 Kbps
AF4
Map-class frame-relay Hshape Default
service-policy output PARENT
EF
Interface serial 0/0.1 point-to-point
frame-relay interface-dlci 100
class HShape
Three-Level Hierarchical MQC Policies
policy-map GRANDCHILD
class BUSINESS-NO-MGMT
police cir 128000 Ser 0/0.1
conform-action transmit Service
exceed-action set-frde-transmit Level
!
policy-map CHILD
class VOICE
priority percent 25
class BUSINESS BUSINESS
bandwidth remaining percent 66
512 Kbps
service-policy GRANDCHILD
!
policy-map PARENT
OUT-POLICE
class class-default
service-policy CHILD VOICE
Supported on Cisco 7200 and 7500 Series Routers, and Low-End

Routers, Since Cisco IOS Software Release 12.2(8)T ( NON HQF)
Basic Hierarchical QoS over GRE
Two MQC Levels
Policy-map PARENT Service Gig 0/1.1001
class class-default Level =
shape average 200000000 Tunnel
Policy-map CHILD
class EF
priority level 1
class AF4 AF1
priority level 2
class AF1 20 Mbps
Default
class class-default
bandwidth remaining ratio 1 EF and
AF4
Interface Tunnel 0
DMVPN HQoS
Policy-map PARENT
class Tunnel 1 Secure On-Demand Meshed Tunnels
description match any-to-campus
service-policy output CHILD Hub
….
class Tunnel 500
Policy-map CHILD
class VOICE VPN
priority 100 Spoke 1
class CONTROL
bandwidth percent 5
class DATA
class class-default
Spoke n Spoke 2
DMVPN Tunnels
Interface GigabitEthernet 0/0 Traditional Static Tunnels
Static Known IP Addresses
Interface Tunnel 0 Dynamic Unknown IP Addresses
qos preclassify
QoS Preclassify Review
 The use of qos-preclassify depends on which header

you need to use for classification and where to apply
the QoS Policy
Apply the QoS policy to the tunnel interface without qos-
preclassify when you want to classify packets based on the pre-
tunnel header.
Apply the QoS policy to the physical interface without qos-
preclassify when you want to classify packets based on the post-
tunnel header. In addition, apply the policy to the physical
interface when you want to shape or police all traffic belonging to
a tunnel, and the physical interface supports several tunnels.
Apply the QoS policy to a physical interface and enable qos-
preclassify on a tunnel interface when you want to classify
packets based on the pre-tunnel header.
BRAS Hierarchical Queuing
Example
BRAS for PTA
policy-map sub-3play-out
class voice Internet
priority level 1
police cir 128000 PE
class video
priority level 2 IP/MPLS Core
police cir 1000000

class gaming PE PE
class class-default BRAS
Aggregation
policy-map 1.5mbps_subscriber Residence Residence
class class-default
bandwidth remaining ratio 1 C C
P P
shape average 1500000 E E
service policy sub-3play-out

 Hierarchical policy is attached to the
interface Virtual-Template1 subscriber session – relationship with
ip unnumbered Loopback1 physical interface is automatically
ppp authentication chap PTA_AUTH created. Not visible in running config.
ppp authorization PTA_AUTH
ppp accounting PTA_AUTH  Attached via RADIUS attribute or on the
ppp ipcp address required virtual-template which is referenced in
service-policy output 1.5mbps_subscriber the bba-group or vpdn-group.Can also
be attached as a service policy for ISG
cases (including IP sessions)
Ethernet Hierarchical Scheduling
Example (2)
Ethernet
policy-map sub-3play-out Internet
class voice
priority level 1 PE
police 128000
class video IP/MPLS Core
priority level 2
police 1000000 PE PE
class gaming
bandwidth remaining ratio 9 BRAS
class class-default Aggregation
bandwidth remaining ratio 1 Residence Residence
!
policy-map 1.5mbps_subscriber C C
P P
class class-default E E
bandwidth remaining ratio 1  Hierarchical policy is attached to the

service policy sub-3play-out subscriber session – relationship with
! physical and VLAN subinterface is
policy-map 50mbps_dslam automatically created. Not visible in
class class-default running config
!  Attached via RADIUS attribute or on the
interface GigabitEthernet0/0/0.1 virtual-template which is referenced in
encapsulation dot1q 2 the bba-group or vpdn-group. Can also
service-policy output 50mbps_dslam be attached as a service policy for ISG
cases (including IP sessions)
Bandwidth Remaining Ratio
 Supported in 12.2(31)SB, 12.2(33)SRD and IOS XE 2.1

 Available at both child and parent level
Total Bandwidth = 100 Mbps ( parent Policy child-output
shaper)
class EF
priority
Remaining Bandwidth = 100- EF = 95 Mbps
class AF
AF Bandwidth = (50/95)*95 = 50 Mbps
class class-default
Default Bandwidth = (45/95)*95 = 45 Mbps
Policy parent-output
class class-default
service-polcy child-output
Bandwidth Remaining Ratio
BRR BRP
 Parameter is unitless  Parameter is a percentage
 Part of ratio that changes with  Total % for all classes/levels
addition of classes can’t be more than 100%
 Inconvenient when trying to  Convenient when a class must
figure out % for each class always get same %
 Convenient with a very  Inconvenient with a very
dynamic class configuration dynamic class configuration
 Convenient with dynamic  Convenient with traditional
configurations with more than configurations with few and
100 vlans/classes very static vlans/classes
MQC/HQF Available Combinations
Allowed in ( class-default ) Allowed in Child policy
Parent policy
Policer Yes Yes
Shape Yes Yes
Bandwidth Yes Yes
Bandwidth remaining Yes Yes
Priority Yes ( if child policy is non Yes

queuing)
WRED Yes (if there are other queuing Yes

in same class)
Hierarchical Queuing Framework (HQF)
 Cisco has developed a new way of handling queuing

Supported since IOS 12.0(26)S, 12.2(28)SB, IOS XE 2.1 and
just recently 12.4(20)T
 The objective is to handle hierarchical QoS policies

more efficiently and consistently across Cisco platforms
 With HQF customers, using any of the IOS releases
and specific platforms, will have:
The ability to provide multiple levels of packet scheduling
The ability to support integrated class-based shaping and
queuing
Hierarchical Queuing Framework (HQF)
 Platforms may implement the framework with different

levels of hierarchy and algorithms, with different
resulting capabilities and behaviors
Just because two platforms both support HQF does not mean
they support the same underlying functionality!!
 Bottom line is that HQF is as consistent as possible

given the underlying hardware
 Next slides are some of the most important HQF
enhancements, which as mentioned before, are
available since IOS 12.0(26)S, 12.2(28)SB, IOS XE 2.1
and just recently 12.4(20)T
HQF Major Enhancements
 Hierarchical Policy with Queuing Features at Every

Level
You can apply class-based queuing to any traffic class in the
parent or child level of a hierarchical policy
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
 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 shape rate exceeds the
physical interface bandwidth, congestion at the physical interface
results in backpressure to each logical interface policy. This
backpressure causes each policy to reduce the output rate down
to its fair share of the interface bandwidth.
Example: 10 subint policies each shaped to 2Mbps, physical
int has 10Mbps bandwidth (2:1 oversubscription), when all
10 subint are sending at 2Mbps, each subint gets a
throughput of 1Mbps (10 Mbps / 10 subint
 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
class c2
interface atm1/0.1
pvc 1/100
service-policy output p1
 Fair Queue in an MQC class

You can apply the fair-queue command to a user-defined class
 Child Policy in a Priority Class

You can apply a child policy to a class with priority enabled. The
child policy can contain police or set features, but not queuing
features
 Strict Priority with No Policing Rate

Only one class is allowed strict priority configuration. Other
classes cannot have priority or bandwidth configuration. If
minimum bandwidth is required by one of the other classes the
bandwidth remaining percent command must be used
Some platforms support multiple levels of priority queuing
:priority level 1 and priority level 2
HQF Behavioral Changes
Major Differences in Existing QoS Commands

 Flow-Based Fair-Queuing Support in Class-Default
The fair-queuing behavior for the class-default class is flow-based. This
is a change from the WFQ behavior in previous releases. With flow-
based fair queuing, the flow queues in the class-default class are
scheduled equally instead of by weight based on the IP Prec. Better to
use separate class if you have application or user flow w/special
needs
 Default Queuing Implementation for Class-Default

When you do not explicitly configure the class-default class in a policy
map, its default queuing behavior is FIFO. You can configure the
bandwidth, fair-queue, or service-policy commands in the class-
default class to achieve different queuing behaviors.
 Default Queuing Implementation for Shape Class

When you configure the shape command in a class, the default
queuing behavior for the shape queue is FIFO instead of
weighted fair queuing (WFQ). You can configure the bandwidth,
fair-queue, or service-policy commands in shape class to
achieve different queuing 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.
 Policy Map and Interface Bandwidth

In HQF, a policy map can reserve up to 100% 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% of
the interface bandwidth to user-defined classes and reserve the
other 1% for the class-default class.
The command max-reserved-bandwidth is not longer
needed
 Per-Flow Queue Limit in Fair Queue

In HQF, when you enable fair queuing, the default per-flow
queue limit is ¼ 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).
 Shaping Behavior on GRE Tunnel

In HQF, shaping on GRE tunnel is done after encapsulation. This
means the shape rate is based on packets with tunnel
encapsulation and L2 encapsulation. If you configure IPSEC on
the GRE tunnel, shaping occurs after encryption.
Only absolute parent shapers are supported at this time and for
the support of GRE and physical policy, see next slide
 Change in FRF.12 and FRF.9 Behavior

when you enable (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 (FRF.9) on an FR PVC
or main interface, priority class packets are no longer
compressed.
HQF—GRE Multiple Policy (MPOL)

Service
class class-default
Level =
shape average 200000000 Non GRE
service-policy output CHILD Traffic 20 Mbps
Policy-map CHILD
class EF
priority
class AF1
class class-default Service
bandwidth remaining ratio 1 Level =
GRE Traffic
20 Mbps
Interface Tunnel 0
Interface Ethernet 0
HQF GRE MPOL Supported Only in 12.4(22)T

HQF Behavioral Changes Highlights
HQF QoS NEW Behavior Classic QoS Behavior
Flow-Based Fair-Queuing Flow based and all flows are equal WFQ Based on IP prec
Support in Class-Default
Default Queuing FIFO WFQ
Implementation for Class-
Default
Default Queuing FIFO WFQ
Implementation for Shape
Class
Class-Default and Bandwidth Default 1%, otherwise remaining Default 25% but not guaranteed,
from other classes or assigned otherwise remaining from other
classes or assigned
Policy Map and Interface 100% can be assigned to MQC max-reserved-bandwidth is need to
Bandwidth
classes. max-reserved-bandwidth reserve more then 75% to MQC
is NOT needed classes
Per-Flow Queue Limit in Fair Per flow queue limit is ¼ of the N/A
Queue
class
HQF Commands Changes
 New random-detect Option Support

The random-detect command supports the atm-clp-based,
cos-based, and byte-based options to calculate the probability
of dropping a packet
 Commands not needed/supported

random-detect prec-based replaced by random-detect
precedence-based
shape max-buffers replaced by queue-limit
max-reserved-bandwidth not needed
show queuing and show queue Commands replaced by show
policy-map interface
shape average Tc is 4 ms by default
HQF IOS and Platforms Support
HQF Platform Support
 With 12.0(26)S, 12k and 7200VXR ,7500*

 With 12.2(31)SB, 7200VXR,7304 and c10k
 With 12.2()SRA, 7600 SIP400
 With 12.2(33)SRC, 7200VXR, ES20
 With 12.4(20)T, all ISR and 7200VXR
 With IOS XE 2.1, ASR1000
Please Work with Your AT and/or Cisco.com

Documentation to Verify Each Platform Capabilities
Hardware-Based Platform and HQF
 Software based platforms do support HQoS rules and

configurations, as long as congestion is not high
enough to overload CPU and Tx-ring
 As mentioned before several platforms support HQF
based on each platforms capabilities
12000 Eng 3
7600 SIP400, ES and ES+
C10000 PRE3/4
7304 NSE150
ASR1000
DMVPN HQoS Performance Comparison
Platform Number of VoIP VoIP G.729 Data Total PPS Total
Tunnels, Drop% Calls Mbps
QoS conf Jitter
and shape Delay
rate
7200 30 0% 454 81259 pps 58 Kpps 124 Mbps
G2/VSA
mGRE QoS 1.3 ms 40550 pps
4 Mbps 2.7 ms
7600 240 0.22 % 4009 53,951 pps 455 Kpps 1002 Mbps
SIP400
per class- 0.6 ms 400,900 pps
per vlan
2.1 ms
4 Mbps
ASR 1000 240 0.25 % 4055 81,259 pps 487 Kpps 953 Mbps
ESP10
per class- 2.5 ms 400,550 pps
RP1
per vlan
2.6 ms
4 Mbps
ASR 1000 QFP Introduction
Forwarding Route
 RP (Route Processor)
Processor Processor
ESP
CPU
RP Handles control plane traffic
Manages system
Interconn.
Crypto
assist
QFP
 ESP (Forwarding Processor)
Interconn. Handles forwarding plane traffic
 Quantum Flow Processor

Midplane
(QFP)
Consists of two subsystems:
Interconn. Interconn.
SPA
SIP
SPA
SIP
QFP TM ( Traffic Manager)
CPU CPU
Agg. Agg.
QFP PPE ( Packet Proccesors)
SPA … SPA SPA … SPA
 SPA Interface Processor (SIP)
Houses the SPAs ( Shared PA)
ASR 1000 QFP and Hierarchical QoS
 ASR1000’s QFP was designed specifically to support

several scheduling levels
in and outside MQC
 QFP’s PPEs are fully dedicated to MQC classification,

policing, marking, etc
 QFP TM is fully dedicated for Hierarchical Queuing
MQC policies are mapped into QFP TM scheduler
Two level of high priority traffic and priority propagation
 This capabilities allows the ASR1000 to delivery HQF

policies at very high throughput while maintaining LLQ
QFP, How Many Levels of Scheduling?
 Getting back to the topic

of scheduling levels Service SIP
Level
This assumes scheduling of
all traffic for a particular
physical interface
AF1
The ASR1000 uses an extra
EF and
level since scheduling is AF4 Interface
centralized on ESP
This level represents the SIP Default
slot
 Therefore a typical 3-level

scheduling example is
actually 4 levels on the
ASR 1000
Basic Hierarchical QoS with IOS MQC
Two MQC Levels
Service
class class-default Level
Policy-map CHILD
class EF
priority level 1
class AF4 AF1
priority level 2
class AF1 200 Mbps
class class-default AF4
bandwidth remaining ratio 1 Default
Interface gigabitethernet 0/1.1001 EF

Basic Hierarchical QoS in QFP TM
2 Level (Class + VLAN) + Non-MQC Physical Level
“Bandwidth Remaining Ratio

” for AF1 and Default
Performed Here
Priority 1 and Priority 2 Passes
AF1 and Class-Default
…
Shape Average <parent policy
> Enforced Here
Evolution: Policies Aggregation
Why Policies Aggregation
 Existing 3-level hierarchy could not handle it
No way to aggregate only data traffic at interface level – interface shaper would shape ALL
traffic
Shaper at VLAN level would shape ALL subscriber traffic (Voice/Video/Data), adding extra
latency when oversubscribed
 Priority queues need to be separated from the Data queues in the

hierarchy
Benefit: Priority traffic ( + oversubscribed data) is not capped by logical interface shaper
 Introduces the concept of an Economy Class Rate

Think of airline model: data traffic stays within its assigned class of service all through the
hierarchy
First class traffic (like voice/video) is not affected by this rate
 Physical & logical interface policies linked via new “fragment CLI”
Benefit: Data classes can be linked together to provide both VLAN level and aggregate level
service
ASR 1000 Policies Aggregation
Priority
Gig 0/1.1001
Service Level
Data
200 Mbps
Default
Priority Queues Need to Be Separated from the Data

Queues in the Hierarchy
Policies Aggregation with QFP TM
2 Level (Class + VLAN) + Non-MQC Physical Level
… …
4 Level Hierarchy:
1. Class -> MQC defined
2. Logical -> MQC VLAN
3. Aggregate -> MQC
Fragment CLI
4. Physical -> ASR 1000
… SIP
Policies Aggregation
MQC CLI policy-mapSubscriber(VLAN100)
class VoIP These queues are not
priority level 1 shaped at main
class McastTV
interface
Policy-map main-interface priority level 2
Class data service-fragment Economy class class-default fragment Economy
shape average 150 Mbps
shape average 400000000 bandwidth remaining ratio 2
LINKED service-policy AF1plusDefault
policy-map AF1plusDefault
class PremiumData
class class-default
policy-map Department2 (VLAN200)

class VoIP These queues are not
priority level 1 shaped at main
class McastTV interface
priority level 2
class class-default fragment Economy
shape average 150 Mbps
service-policy AF1plusDefault
policy-map AF1plusDefault
class PremiumData
class class-default
ASR1000 Policies Aggregation
Applications
ASR1000 in Distributed Integrated Service Edge
Voice & Video Telephony (SBC, v4/v6)
Internet Access (BB, LAC, PPPoE, v4)
IPTV VoD (SBC, HDTV, v6)
IPTV B’cast TV (Multicast, SDTV/HDTV, v6)
Gq’ Diameter
RACS Applications
H.248
Control
Residence IPv4 / IPv6 Dual Core
AAA/
Access Network DHCP
(DSL, PON…) LNS
Content
CPE NT
V POTS Servers
Access SW
MG
SBC
VoIP
Access SW Operators
Ethernet WAN with Three Level HQoS
 Branches can Service Provider
subdivide Sub gig

BW,and share it
among different dept
 This requires 3 level Dept/VLAN1
Policy:
CPE
Physical
VLAN
Dept 3
Dept 2
Class
ASR 1000 “Three Level” Policies
Aggregation
Gig Interface
Service Level
Aggregate BW
Data Class
VLAN Available
BW
Best Effort
Multiple priority Class
Class
 ASR1000/QFP scheduler is flexible to enough

to accommodate this change
ASR 1000 “Three Level” Policies
Aggregation
class class-default fragment ALL-P
Policy-map main-interface bandwidth remaining ratio 24
Class data service-fragment ALL-P service-policy ALL-CHILD
policy-map ALL-CHILD
class EF This queue is shaped at
priority
LINKED
main interface
class AF4
class AF41
class class-default

class class-default fragment ALL-P
service-policy ALL-CHILD
policy-map ALL-CHILD
class EF
priority
class AF4
class AF41
class class-default
Policies Aggregation Restrictions
 Only the default class in a policy map can be configured as a
fragment.
 Fragments only work when multiple policy maps are attached to
the same physical interface.
 Only queuing features are allowed in classes where the fragment
keyword is entered, and at least one queuing feature must be
entered in classes where the fragment keyword is used.
 A policy map with a class using the fragment keyword can only be
applied to egress traffic.
 The fragment keyword cannot be entered in a child policy map.
 Fragment aggregate counters are only absolute ( not bps )
Future: Four Level MQC Policies
 Several Scenarios
deployments require Interface
scheduling at additional levels

Aggregate
 Shape or BRR at the Service
Aggregate Level for a VLANs Level
or EVCs
 Shape at the Interface Level
for a 3 level policy applies to a
VT or GRE Service
Level
 All of these are possible with EVC or

VLAN
specialized scheduling
hardware such as the QFP or
ES+
Future: Policies Aggregation
 All Non-default queuing happens at the aggregate level
 Premier data is not longer mixed with default traffic and not subject
to vlan shaper
Priority Traffic
Gig 0/1.1001
Premier Data
Service Level
200 Mbps
Default
Summary
Summary HQoS and Policies
Aggregation
 Hierarchical QoS gives you great flexibility to distribute

and manage bandwidth
Service Providers can overprovision, and basically resell the
same bandwidth
Enterprises can redistribute bandwidth according each campus,
user or application usage
 HQF establishes the foundation to deliver a much more

uniform and consistent QoS scheduling behavior
 Cisco ASR1000, QFP and its Policies Aggregation,
allows for even a greater flexibility in order to satisfy a
diverse set of requirements.
HQoS and Policies Aggregation Doc
 HQF documentation
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6
558/white_paper_c11-481499.html
 Policies Aggregation documentation

http://www.cisco.com/en/US/docs/ios/ios_xe/qos/configuration/g
uide/qos_policies_agg_xe_ps9587_TSD_Products_Configuratio
n_Guide_Chapter.html
Please Visit the Cisco Booth in the
World of Solutions
See the technology in action
 Network Infrastructure and Systems
NS1 – Cisco Catalyst Series: Optimize and
Virtualize
NS2 – Cisco Catalyst Series: Fueling
Collaboration
NS3 – Cisco ISR: Application Integration at
Branch
NS4 – Enhance Collaboration with Cisco
WebEx Node
NS5 – Optimize the WAN with Cisco ASR
1000 Series
NS6 – Pedal Power for the Cisco Catalyst
4500
Recommended Reading
 End-to-End QoS Network Design:
Quality of Service in LANs,
WANs, and VPNs,
ISBN: 1-58705-176-1
 Cisco Catalyst QoS: Quality of
Service in Campus Networks,
ISBN: 1587051206
 QoS for IP/MPLS Networks,
ISBN: 1-58705-233-4
Complete Your Online
Session Evaluation
 Give us your feedback and you
could win fabulous prizes.
Winners announced daily.
 Receive 20 Passport points for
each session evaluation you
complete.
 Complete your session evaluation
online now (open a browser
through our wireless network to
access our portal) or visit one of
the Internet stations throughout
the Convention Center.
Don’t forget to activate your
Cisco Live Virtual account for access to
all session material, communities, and
on-demand and live activities throughout
the year. Activate your account at the
Cisco booth in the World of Solutions or visit
www.ciscolive.com.

Hierarchical QoS and Policies Aggregation PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hierarchical QoS and Policies Aggregation PDF

Uploaded by

Copyright:

Available Formats

Hierarchical QoS and Policies

 Bandwidth optimization for voice, video and data

 Critical customers and/or applications prioritization

 More Bandwidth is available but

 Different policies at different levels ( branch, HQ, etc)

 A Qos scheduler determines when a packet will be

 Min Bandwidth (bandwidth)

 Max Bandwidth (Shape)

 Excess Bandwidth (bandwidth remaining)

Data Traffic 1st Level

 Each level could represent a branch, type of traffic, etc

 Single level scheduler,

Backpressure from interface priority

 Behavior defined at one layer in the hierarchy

 HQ aggregates branches HEADQUARTER

 Same as before + few HEADQUARTER

 Subscriber gets an X Aggregation

Mbps service plus Voice

 Cisco IOS command syntax for QoS

 Hierarchical Policies are basically configured by calling

Interface gigabitethernet 0/1.1001

Supported on Cisco 7200 and 7500 Series Routers, and Low-End

 The use of qos-preclassify depends on which header

police cir 1000000

policy-map 1.5mbps_subscriber Residence Residence

service policy sub-3play-out

policy-map sub-3play-out Internet

class class-default Aggregation

bandwidth remaining ratio 1 Residence Residence

bandwidth remaining ratio 1  Hierarchical policy is attached to the

 Supported in 12.2(31)SB, 12.2(33)SRD and IOS XE 2.1

Policer Yes Yes

Shape Yes Yes

Bandwidth Yes Yes

Bandwidth remaining Yes Yes

Priority Yes ( if child policy is non Yes

WRED Yes (if there are other queuing Yes

 Cisco has developed a new way of handling queuing

 The objective is to handle hierarchical QoS policies

 Platforms may implement the framework with different

 Bottom line is that HQF is as consistent as possible

 Hierarchical Policy with Queuing Features at Every

 Over-Subscription Support for Multiple Policies on

 Shaping in an ATM PVC Policy

 Fair Queue in an MQC class

 Child Policy in a Priority Class

 Strict Priority with No Policing Rate

Major Differences in Existing QoS Commands

 Default Queuing Implementation for Class-Default

 Default Queuing Implementation for Shape Class

 Class-Default and Bandwidth

 Policy Map and Interface Bandwidth

 Per-Flow Queue Limit in Fair Queue

 Shaping Behavior on GRE Tunnel

 Change in FRF.12 and FRF.9 Behavior

Policy-map PARENT Gig 0/1.1001

HQF GRE MPOL Supported Only in 12.4(22)T

 New random-detect Option Support

 Commands not needed/supported

 With 12.0(26)S, 12k and 7200VXR ,7500*

Please Work with Your AT and/or Cisco.com

 Software based platforms do support HQoS rules and

 Quantum Flow Processor