Enterprise QoS Solution Reference Network Design Guide

Chapter 1 Quality of Service Design Overview
3) Designing the QoS Policies
Version 3.3
How is QoS Optimally Deployed within the Enterprise?
Once a QoS strategy has been defined and the application requirements are understood, end-to-end QoS
policies can be designed for each device and interface, as determined by its role in the network
infrastructure. A separate QoS design document delves into the specific details of LAN, WAN, and VPN
(both MPLS and IPSec VPN) QoS designs. Because the Cisco QoS toolset provides many QoS design
and deployment options, a few succinct design principles can help simplify strategic QoS deployments.
For example, one such design principle is to always enable QoS policies in hardware— rather than
software—whenever a choice exists. Cisco IOS routers perform QoS in software, which places
incremental loads on the CPU, depending on the complexity and functionality of the policy. Cisco
Catalyst switches, on the other hand, perform QoS in dedicated hardware ASICS and as such do not tax
their main CPUs to administer QoS policies. This allows complex policies to be applied at line rates at
even Gigabit or Ten-Gigabit speeds.
Other simplifying best-practice QoS design principles include:
Classification and Marking Principles
Policing and Markdown Principles
Queueing and Dropping Principles
Classification and Marking Principles
When classifying and marking traffic, an unofficial Differentiated Services design principle is to classify
and mark applications as close to their sources as technically and administratively feasible. This
principle promotes end-to-end Differentiated Services and PHBs. Do not trust markings that can be set
by users on their PCs or other similar devices, because users can easily abuse provisioned QoS policies
if permitted to mark their own traffic. For example, if DSCP EF received priority services throughout
the enterprise, a PC can be easily configured to mark all the traffic of the user to DSCP EF, thus hijacking
network priority queues to service non-realtime traffic. Such abuse could easily ruin the service quality
of realtime applications like VoIP throughout the enterprise.
Following this rule, it is further recommended to use DSCP markings whenever possible, because these
are end-to-end, more granular and more extensible than Layer 2 markings. Layer 2 markings are lost
when media changes (such as a LAN-to-WAN/VPN edge). There is also less marking granularity at
Layer 2. For example, 802.1Q/p CoS supports only 3 bits (values 0–7), as does MPLS EXP. Therefore,
only up to 8 classes of traffic can be supported at Layer 2, and inter-class relative priority (such as RFC
2597 Assured Forwarding Drop Preference markdown) is not supported. On the other hand, Layer 3
DSCP markings allow for up to 64 classes of traffic, which is more than enough for most enterprise
requirements for the foreseeable future.
As the line between enterprises and service providers continues to blur and the need for interoperability
and complementary QoS markings is critical, you should follow standards-based DSCP PHB markings
to ensure interoperability and future expansion. Because the QoS Baseline marking recommendations
are standards-based, enterprises can easily adopt these markings to interface with service provider
classes of service. Network mergers—whether the result of acquisitions, mergers or
strategic-alliances—are also easier to manage when you use standards-based DSCP markings.
Policing and Markdown Principles
There is little reason to forward unwanted traffic only to police and drop it at a subsequent node,
especially when the unwanted traffic is the result of DoS or worm attacks. The overwhelming volume
of traffic that such attacks can create can cause network outages by driving network device processors
to their maximum levels. Therefore, you should police traffic flows as close to their sources as possible.
Enterprise QoS Solution Reference Network Design Guide
1-23