Differentiated services are used to control quality of service (QoS), but little is standardized to define or tag IP packets. Where QoS behavior is not controlled by open standards is where vendors make their own QoS classes, which don't necessarily meet the needs of an organization. In order for enterprise IT to deliver application traffic reliably, it's important for wide area network (WAN) managers to map business-critical applications to their own QoS priority levels. Here are instructions on how to develop your own QoS prioritization strategy to help you match your network needs to your vendors' abilities.
Developing a QoS class map for better WAN performance
The idea of trying to control quality of service (QoS) using differentiated services (or “DiffServ”) is the core of what we mean when we talk about QoS. At the WAN and Internet level, where QoS is governed by Differentiated Services Code Point (DSCP) tagging of IP packets, little is standardized about how to define or handle tags. The DSCP uses 6 bits, allowing for up to 64 QoS classes! And, of course, vendor proprietary schemes can create more than that.
Wherever QoS behavior is not dictated strictly by open standards, vendors do their own thing. Whether it is core equipment vendors such as Juniper and Cisco, or WAN service providers such as AT&T and Verizon, the number and meaning of QoS classes available varies. You might get five, seven or even 11 QoS classes! In some cases, a single vendor will implement several distinct QoS schemes in different offerings.
It is therefore highly beneficial that all organizations develop their own QoS prioritization schemes and map them onto vendors' schemes as needed. This gives them a layer of abstraction between their needs and their vendors' abilities, making it easier to add or swap vendors and technologies.
Understand your WAN application needs
Start by establishing a QoS prioritization scheme for application traffic based on four key criteria:
- The importance of specific applications to the business.
- The volume of traffic each creates.
- The behavior of that traffic, i.e., is the traffic smooth, chatty, bursty?
- The resilience of the application, i.e., how well it can deal with network problems.
You may want to add other criteria, such as location or user criticality.
Establish a simple grouping on each criterion. For example, each might get a 1 to 5 scale:
- Importance: 1 (recreational) through 5 (mission critical).
- Volume: 1 (very low, i.e., TN3270 or IM) through 5 (very high, i.e., telepresence).
- Behavior: 1 (intermittent and bursty, showing wild variation in packet average sizes and rates over time) through 5 (smooth and evenly sized packet streams, like video conferencing).
- Resilience: 1 (extremely sensitive to packet loss, errors, latency and jitter) to 5 (insensitive to such network issues).
Establish QoS classes based on these criteria. Start with just a few categories, such as the following:
- Sensitive/critical: traffic with a value >4, resilience <2, with any volume or behavior.
- Important: traffic with a value >3, resilience <=3, with any volume or behavior.
- Reliable: traffic with a value >2, volume <3, behavior >2, with any resilience.
- Allowed: all other traffic types.
Understand your application portfolio and user community
Now map your applications’ network traffic to these criteria.
VoIP is the first application on many networks that drives IT to implement QoS. It would be classified as sensitive/critical. Network performance monitoring might go into important or reliable, while network management traffic (which is used to change switch or router settings to enable or disable a connection) would go into important. Web traffic to and from a SaaS provider might get reliable, while end users visiting the company’s 401k management portal might get allowable. If four QoS classes don’t seem enough, add more by dividing one or more existing classes. Adapt your classification scheme to meet your exact needs and environment.
Fit QoS prioritization into your environment
Lastly, map your QoS classes onto your vendors’ classes. This mapping is going to be different for every vendor, but the nice thing is that each time you add a vendor, you map classes once -- instead of each time mapping all your applications to the new class scheme.
The mapping may be something your carrier does for you, or it may be something you do in-house. For example, on a Cisco router, you would do the following:
- Establish access groups associated with specific applications (such as VoIP voice data or call signaling).
- Map the access groups to traffic classes.
- Create a QoS policy map to assign classes to required levels of service (types of service levels a class gets mapped to include minimum or maximum traffic rates or prioritization levels).
- Apply the policy map to a network connection or a partition on a connection.
Whatever the specifics, by beginning with a clear understanding of what you need QoS to deliver, as embodied in your classification scheme, and by keeping everything vendor-independent as long as possible, you set yourself up to get the most out of every QoS option available to you.