RSS

QoS Part I: Classification and Marking

Share this page:

QoS Part I: Classification and Marking

Quality of Service (QoS) is the ability to provide different levels of performance for individual applications and services that run over the networks. Different application attributes such as constant vs. burst bandwidth consumption, jitter, perceived latency, error rate, availability and admission control can be controlled by the proper implementation and deployment of QoS.

The need for QoS has become increasingly necessary, especially within the backbone network where the real time applications like VoIP and Cisco TelePresence needs to be prioritized. QoS has become crucial for the everyday business needs due to the ever changing traffic load on the network from Internet browsing, streaming media, file transfers, data replication etc. The critical applications should take advantage of QoS and be prioritized, in order to get more preference over non-critical applications.

This is how the switch treats frames by default after the QoS is enabled:

- A frame enters the switch port and it does not have the frame tagged (it means the port is access port and the frame enters the switch does not have ISL or dot1q encapsulation).

- The switch encapsulates the frame with the dot1q (ignore ISL because dot1q is the default on all the new switches).

- Inside the dot1q frame tag, there are three bits called 802.1p priority bits available, which are also called CoS (Class of Service bits). These bits are set to 0 by default.

- The switch calculates DSCP value based on the CoS-DSCP map table. As per the table, the switch sets the DSCP value to 0. DSCP value is located at the IP header of the packet.

Unlike the routers, the QoS classification and marking acts differently in Cisco Catalyst switches. In Cisco routers, you can classify the packets using MQC either based on the incoming packet DSCP value or based on the access control list (ACL). This depends on whether you trust the QoS label of the incoming packet or not. In the Cisco Catalyst 3750 Switch, you can classify the frames either based on the incoming CoS/DSCP values or based on the ACL.

The configuration based on the incoming CoS/DSCP value is achieved in three different ways:

- Port based configuration using the mls qos interface based commands

- MQC based configuration using class-map and policy-map

- VLAN based configuration

You can use either one of these three methods. You cannot use more than one method in a port. For example, you have configured the mls qos trust cos command on a port. When you configure the port with the

“service-policy input ” command, it removes the

“mls qos trust cos” command automatically.

You could have as many classes of traffic as you wish, but be sure to adjust it to your networks needs. For the purposes of explaining the QoS I took the 5 most typical classes of services to be implemented within end-to-end from campus network to the backbone network:

- VOICE Class, for VoIP telephony traffic (Marked with CS5, DSCP: EF). Low Latency queue is recommended for this class (more details in Part II of this document)

- VIDEO Class, for Video Conference and Cisco TelePresence traffic (Marked with CS4, DSCP: AF41)

- Critical Data Class (D3), High importance Data Traffic, Critical Applications (Marked with CS3, DSCP: AF31)

- Business Data Class (D2), Medium importance and Default Data Traffic (Marked with CS2 and CS0, DSCP: AF21 and AF0)

- Scavanger (D1), Low importance Data Traffic(Marked with CS1, DSCP: AF11)

Classes 6 and 7 (CS6 and CS7) are NOT to be marked manually as they are reserved for synchronization for a group of critical network protocols (BGP, EIGRP, DNS and etc.) and assigned CS6 and priority by the pak_priority mechanism. They are to be matched though by the traffic treatment policies.

LLQ is ideal for Voice and Video traffic because it provides a guaranteed minimal amount of delay and jitter through the router. Cisco recommends applying the LLQ on up to 33% of the traffic.

You can attach a service policy to either the physical interface or to the switched virtual interface (SVI or VLAN interface). If you attach a service policy to a VLAN interface, the only ports that use this service policy are ports that belong to that VLAN and are configured for VLAN-based QoS. If the port is not set for VLAN-based QoS, the port still uses the default port-based QoS and only looks at the service policy that is attached to the physical interface.

If you are using QoS of both, Layer 3 (DSCP Values) and Layer 3 (CS Values), be sure to define how the values are mapped using the following command from the Global Configuration mode:

mls qos map cos-dscp 0 10 18 26 34 46 48 56

MQC Method, Step 1: Define the traffic using the Access Lists

You must tell the router which traffic you want to give QoS, which you can accomplish using an access control list (ACL). In the following example you will see how the VoIP and Video traffic is marked:

VOICE_TRAFFIC__: (EF)

ip access-list extended VOICE\_TRAFFIC

remark *VOICE: Strict Priority Traffic,10%,DSCP:EF*

 permit udp any any range 32512 32768

permit udp any range 32512 32768 any


  

_**VIDEO\_TRAFFIC**__: (AF41)_

ip access-list extended VIDEO_TRAFFIC

remark \*VIDEO: Priority Traffic,**35%,DSCP:AF41**\*

remark —- Video Conference server —-

 permit udp any range 50000 59999 any

permit udp any any range 50000 59999

remark ---- Cisco **TelePresence** ----

permit udp any eq 16388 any

 permit udp any any eq 16388

remark —- Polycom Video —-

 permit udp any any range 3220 3247

permit udp any range 3220 3247 any

remark ---- **Tandberg** Video ----

permit udp any any range 2326 2485

 permit udp any range 2326 2485 any
```

  

  

**MQC Method, Step 2: _Create the CLASS MAPS and correlate with the ACLs_**  

  

A class-map defines the traffic into groups. For example, you could create a class-map called _VoIP traffic_ and put all VoIP protocols under it using the previously defined Access List:  
  

class-map match-any CLASS\_VOIP

 match access-group name ACL\_VOIP

```
Here are the steps to create the class map based on the already configured Access Lists:
```

```
class-map match-any VOICE\_CLASS

match access-group name VOICE_TRAFFIC

class-map match-any VIDEO\_CLASS

match access-group name VIDEO_TRAFFIC

class-map match-any CRITICAL\_CLASS

match access-group name CRITICAL_DATA

class-map match-any BUSINESS\_CLASS

match access-group name BUSINESS_DATA

class-map match-any OTHER\_DATA\_CLASS

match access-group name OTHER_DATA


**MQC Method, Step 3: _Create POLICY MAP and set the traffic marking_**

The DSCP can be set to a desired value at the Trust Boundary of the network in order to make it easy for core devices to classify the packet and provide a suitable level of service. [Class-Based Packet Marking](http://www.cisco.com/en/US/docs/ios/12_1t/12_1t5/feature/guide/cbpmark2.html) can be used to set the DSCP value.  
  
The policy maps are an actual step where the DSCP value is assigned to a certain traffic group. First the concepts of DSCP/CoS/ToS need to be explained.  
  
There are 8 DSCP values compatible with each IP precedence binary value:  
  

**DSCP Class Selector**

**DSCP Binary Value**

**Precedence Value**

**Range of DSCP values**

Default

000000

0

0-7

CS1

001000

1

8-15

CS2

010000

2

16-23

CS3

011000

3

24-31

CS4

100000

4

32-39

CS5

101000

5

40-47 (46 = EF)

CS6

110000

6

48-55

CS7

111000

7

56-63

  
**Assured forwarding (AF)** per-hop behavior allows for up to 4 different classes of queuing purposes, each with 3 levels of drop probability that can be implied. To mark these packets, 12 DSCP values are needed, with the names of these values starting with "AF". Assured forwarding on each PHB actually involved to different QoS functions. These are usually done using different QoS tools. The first is queuing, where each router classifies the packets into 4 different classes, and packets from each class are placed in a separate queue. The second function is congestion avoidance, where routers drop packets before tail drop is required. Assured forwarding does not mean that an individual packet is assured of making it across the network, just that attempts will be made to assure that queuing tools provide enough bandwidth, and when congestion does occur, less important will be discarded first.  

  

**Low Drop Probability**

**Medium Drop Probability**

**High Drop Probability**

Class 1

001010

AF11

DSCP 10 

001100

AF12

DSCP 12

001110

AF13

DSCP 14

Class 2

010010

AF21

DSCP 18

010100

AF22

DSCP 20

010110

AF23

DSCP 22

Class 3

011010

AF31

DSCP 26

011100

AF32

DSCP 28

011110

AF33

DSCP 30 

Class 4

100010

AF41

DSCP 34

100100

AF42

DSCP 36

100110

AF43

DSCP 38

  
Use the following formula if you need to convert AF (Assured Forwarding) values to DSCP:  

**_Decimal from AFxy = (8\*x) + (2\*y)_**

  
Examples:  
  

AF13 = (8\*1) + (2\*3) = DSCP 14

AF31 = (8\*3) + (2\*1) = DSCP 26

AF43 = (8\*4) + (2\*3) = DSCP 38

  

It can be done by remembering how many bits the different markings use. For example CoS uses three bits to mark. DiffServ uses 6. ToS is 6 bit DSCP + 2 bits for ECN. Example:

  
CoS :  0 , 1 , 2 , 3 , 4 , 5 , 6 , 7  
DSCP :  0 , 8 , 16, 24 , 32 , 46 , 48 , 56

  

When you specify the ip dscp value in the class map command, you have these:    

L3Switch(config)# **class-map match-all VOIP**

L3Switch(config-cmap)# **match ip dscp ?**

   <0-63>   Differentiated services codepoint value

 af11 Match packets with AF11 dscp (001010)

 af12 Match packets with AF12 dscp (001100)

 af13 Match packets with AF13 dscp (001110)

 af21 Match packets with AF21 dscp (010010)

 af22 Match packets with AF22 dscp (010100)

 af23 Match packets with AF23 dscp (010110)

 af31 Match packets with AF31 dscp (011010)

 af32 Match packets with AF32 dscp (011100)

 af33 Match packets with AF33 dscp (011110)

 af41 Match packets with AF41 dscp (100010)

 af42 Match packets with AF42 dscp (100100)

 af43 Match packets with AF43 dscp (100110)

 cs1 Match packets with CS1(precedence 1) dscp (001000)

 cs2 Match packets with CS2(precedence 2) dscp (010000)

 cs3 Match packets with CS3(precedence 3) dscp (011000)

 cs4 Match packets with CS4(precedence 4) dscp (100000)

 cs5 Match packets with CS5(precedence 5) dscp (101000)

 cs6 Match packets with CS6(precedence 6) dscp (110000)

 cs7 Match packets with CS7(precedence 7) dscp (111000)

 default Match packets with default dscp (000000)

 ef Match packets with EF dscp (101110)

  
Finally this is how the Policy Map **TRAFFIC-CLASSIFICATION** needs to be configured in order to correlate with the previously defined Class Maps:  

policy-map TRAFFIC-CLASSIFICATION

 class VOICE\_CLASS

set ip dscp ef

 class VIDEO\_CLASS

set ip dscp af41

 class CRITICAL\_CLASS

set ip dscp af31

 class OTHER\_DATA\_CLASS

set ip dscp af11

 class BUSINESS\_CLASS

set ip dscp af21

  
**MQC Method, Step 4: _Apply policy maps to the Access-Switch input interface/s_**  
  
Like an ACL, you must apply the policy-map to the specific interface you want it to affect. You can apply the policy-map in either output or input mode. Here's the command to use:  

service-policy output|input {name of policy-map}


There are 3 options to apply the policy map:


Option 1 Mark on USER INTERFACES (is the Access Switch can handle the load)

interface range <all physical user interfaces>

service-policy input TRAFFIC-CLASSIFICATION


Option 2 Mark on the Egress of the Access SWs (not allowed on some models)

interface range GigabitEthernet <all uplinks to Distribution switches>

service-policy output TRAFFIC-CLASSIFICATION


_\*PFC QoS supports the output keyword only with PFC3 and only on Layer 3 interfaces (either LAN ports configured as Layer 3 interfaces or VLAN interfaces). With PFC3, you can attach both an input and an output policy map to a Layer 3 interface._

_\*_  _On the Cisco Catalyst 3750 Switch, policing can only be configured on the ingress port. Policing can only be configured through MQC. This means there is no interface specific command to police the traffic. You can configure policing in the policy-map and you can apply the policy-map using only the service-policy input <policy-name> command. You cannot apply any policy-map to the output side of an interface._

  

Option 3 Mark on VLAN INTERFACES is the one to be implemented

(vlan-based QoS, following the current policy)
interface vlan XXX

service-policy input TRAFFIC-CLASSIFICATION


interface range

mls qos vlan-based

_\*The other option would be creating separate access lists and policy maps, and applying them only to the corresponding VLANs._