Home > Network Design, QoS > Cisco QoS Baseline (interim)

Cisco QoS Baseline (interim)

April 19th, 2010

Deciding upon a QoS Classification and Marking strategy can be a difficult task. Cisco have provided certain recommendations which may be implemented as a baseline QoS strategy and then altered over time:
Classification and Marking Recommendations:


Layer 3 Classification

Layer 2




IP Routing 6 CS6 48 6
Voice 5 EF 46 5
Interactive Video 4 AF41 34 4
Streaming-Video 4 CS4 32 4
Locally-Defined Mission-Critical Data (see note below) 3 25 3
(see note below)
3 AF31/CS3 26/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
Best Effort 0 0 0 0

Note The QoS Baseline recommends marking Call-Signaling to CS3. However, currently most Cisco IP Telephony products mark Call-Signalling to AF31. A marking migration from AF31 to CS3 is under way within Cisco, but in the interim it is recommended that both AF31 and CS3 be reserved for Call-Signalling and that Locally-Defined Mission-Critical Data applications be marked to a temporary placeholder non-standard DSCP, such as 25. Upon completion of the migration, the QoS Baseline marking recommendations of CS3 for Call-Signalling and AF31 for Locally-Defined Mission-Critical Data applications should be used. These marking recommendations are more in line with RFC 2474 and RFC 2597.


Enterprises do not need to deploy all 11 classes of the QoS Baseline model. This model is intended to be a forward-looking guide that considers as many classes of traffic with unique QoS requirements as possible. Familiarity with this model can assist in the smooth expansion of QoS policies to support additional applications as future requirements arise. However, at the time of QoS deployment, the enterprise needs to clearly define their organizational objectives, which will correspondingly determine how many traffic classes will be required.

This consideration should be tempered with the determination of how many application classes the networking administration team feels comfortable with deploying and supporting. Platform-specific constraints or service-provider constraints may also affect the number of classes of service. At this point you should also consider a migration strategy to allow the number of classes to be smoothly expanded as future needs arise, as shown in Figure 1-5.

This schematic shows an example strategy for Expanding the Number of Classes of Service over Time:

(Example Strategy for Expanding the Number of Classes of Service over Time)

(Example Strategy for Expanding the Number of Classes of Service over Time)

Categories: Network Design, QoS Tags:
Comments are closed.