QoS Part I: Classification and Marking

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 <policy-map-name>” 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 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 <all physical user interfaces>
mls qos vlan-based

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


2 comments:

Most Popular Posts