QoS Baseline Expansion

4/5 Class Model

8 Class Model




1 Call Signaling ■


Call Signaling

Critical Data


Network Control

i ^


Bulk Data

Best Effort

Best Effort



Network Management Mission-Critical Data Transactional Data

QoS Baseline Model Voice

Interactive-Video Streaming Video Call Signaling

IP Routing

Network Management Mission-Critical Data Transactional Data

Bulk Data

Best Effort


The number of traffic classes used by enterprises has increased over the past few years, from 4 classes, to 5-7 classes. The reason for this increase is that enterprises are using more and more applications and want increasingly more granularity in QoS differentiation among applications. The Cisco QoS baseline has suggested an 11-class model. This 11-class model is not mandatory, but merely an example of traffic classification based on various types of applications in use and their QoS requirements from an enterprise perspective. Some enterprises have plans to move to a 10- or 11-class model in the future. The Cisco AutoQoS Enterprise feature can automatically classify traffic into 10 of these 11 classes (the only class that the Cisco AutoQoS Enterprise feature does not automatically provision for is the "Mission Critical Data" class, as this class is defined by subjective business requirements).

Critical Data Routing

Voice 5 EF 46 5

Video Conferencing 4 AF41 34 4

Streaming Video 4 CS4 32 4

Mission-Critical Data 3 AF31* 26 3

Call Signaling 3 CS3* 24 3

Transactional Data 2 AF21 18 2

Network Management 2 CS2 16 2

Bulk Data 1 AF11 10 1

Scavenger 1 CS1 8 1

Although there are several sources of information that can be used as guidelines for determining a QoS policy, none of them can determine exactly what is proper for a specific network. Each network presents its own unique challenges and administrative policies. To properly implement QoS, measurable goals must be declared, then a plan for achieving these goals must be formulated and implemented.

QoS must be implemented consistently across the entire network. It is not so important whether Call Signaling is marked as DSCP 34 or 26, but rather that DSCP 34 and 26 are treated in a manner that is necessary to accomplish the QoS policy. It is also important that data marked DSCP 34 is treated consistently across the network. If data travels over even a small portion of a network where different policies are applied (or no policies are applied), the entire QoS policy is nullified. Whether the data is crossing slow WAN links or Gigabit Ethernet, being switched by a Layer 2 switch or routed in a Layer 3 router, the policies must be consistently implemented to satisfy the policy requirements.

Originally, Cisco marked call signaling traffic as AF31; call signaling traffic was originally marked by Cisco IP Telephony equipment to DSCP AF31. However, the Assured Forwarding classes, as defined in RFC 2597, were intended for flows that could be subject to markdown and, subsequently, the aggressive dropping of marked-down values. Marking down and aggressively dropping call signaling could result in noticeable delay-to-dial-tone (DDT) and lengthy call setup times, both of which generally translate to poor user experiences.

The Cisco QoS Baseline changed the marking recommendation for call signaling traffic to DSCP CS3 because Class Selector code points, as defined in RFC 2474, were not subject to markdown/aggressive dropping.

This topic describes the concept of trust boundaries and how they are used with classification and marking.

Trust Boundaries Classify Where?

Cisco QoS model assumes that the CoS carried in a frame may or may not be trusted by the network device.

For scalability, classification should be done as close to the edge as possible.

End hosts can not be trusted to tag a packet priority correctly.

The outermost trusted devices represent the trust boundary.

1 and 2 are optimal, 3 is acceptable (if access switch cannot perform classification).

Systems, Inc. All rights reserved.

The concept of trust is important and integral to deploying QoS. After the end devices have set CoS or ToS values, the switch has the option of trusting them. If the switch trusts the values, it does not need to reclassify; if the switch does not trust the values, it must perform reclassification for the appropriate QoS.

The notion of trusting or not trusting forms the basis for the trust boundary. Ideally, classification should be done as close to the source as possible. If the end device is capable of performing this function, the trust boundary for the network is at the end device. If the device is not capable of performing this function, or the wiring closet switch does not trust the classification done by the end device, the trust boundary might shift.

How this shift happens depends on the capabilities of the switch in the wiring closet. If the switch can reclassify the packets, the trust boundary is in the wiring closet. If the switch cannot reclassify the packets, the task falls to other devices in the network, going toward the backbone. In this case, one good rule is to perform reclassification at the distribution layer, which means that the trust boundary shifts to the distribution layer. It is likely that there is a high-end switch in the distribution layer with features to support the reclassification function. If possible, try to avoid performing the reclassification function in the core of the network.

Was this article helpful?

0 -1

Post a comment