Recently I’ve been spending a lot of time dealing with Quality of Service (QoS) for voice, so this article will be an introduction to the topic.
QoS involves giving better treatment to some traffic at the expense of others. It’s not going to make any more data fit on the pipe, it just tries to make all the applications happy. Take for instance VoIP and FTP. VoIP needs only a bit of bandwidth (<100Kbit/sec for a G.711 call), but if there is jitter (variation in latency) the call suffers. FTP doesn't care about delay or latency, it'll take as much of the pipe as it can handle (or is constrained because of TCP windowing). Here, the goal of QoS would be to make sure the voice gets the jitter control it needs. If we added in another application such as a CRM tool, we might give bandwidth guarantees to it such that voice gets the priority treatment, CRM gets enough bandwidth to do what it needs, and FTP gets the rest. We could also limito FTP. Such are the decisions necessary when designing QoS policies.
There are many ways of doing QoS in IOS, but the currently favoured method uses the Modular QoS CLI (MQC). The three phases are
- Classify the packet
- Mark the packet
- Apply a treatment (also known as Per Hop Behaviour (PHB)) to the packet
(Technically, I suppose marking could be a treatment, but it’s usually considered separately.) Here, I’ll cover the classification step.
Classification
Classification involves mapping a packet to a series of classes. In QoS design, we generally don’t make a class specific to an application, we make it specific to a treatment. When taking the Cisco QoS course, we were told to keep the number of classes to 6 or fewer.
Classification criteria depends on the hardware, some of the things that are available are:
- Access-lists
- Layer 3 QoS (DSCP values)
- Layer 2 QoS (CoS bits)
- NBAR
This is done through the class-map command. The syntax is
Router(config)#class-map ?
WORD class-map name
match-all Logical-AND all matching statements under this classmap
match-any Logical-OR all matching statements under this classmap
This creates the class map, and puts you in class-map configuration mode. The match-all and match-any specify whether all the match conditions that you enter in class-map configuration mode are required, or only one. The default is all.
Once configuring the class-map, you have to match things:
Router(config-cmap)#match ?
access-group Access group
any Any packets
class-map Class map
cos IEEE 802.1Q/ISL class of service/user priority values
destination-address Destination address
fr-de Match on Frame-relay DE bit
input-interface Select an input interface to match
ip IP specific values
mpls Multi Protocol Label Switching specific values
not Negate this match result
protocol Protocol
qos-group Qos-group
source-address Source address
An example of a class-map that matches voice traffic by looking for the DSCP tag in the IP header is:
class-map match-all voice-traffic
match ip dscp 46
Layer 2 and 3 QoS Marking
It’s inefficient for a router to figure out what a packet is based on layer 4-7 criteria. It is far better to have the packet marked at the edge of the network and have the network look at that marking. At layer 2 this is called the Class of Service (COS), at layer 3 this is called the Differentiated Services Code Point (DSCP).
COS bits are the p part of 802.1p/q, and as such, are only carried in trunked packets. Note that in a .1q trunk, the native vlan isn’t tagged by default, so it can’t carry the COS bits. Within the 802.1q header are two bytes. 12 bits of this forms the VLAN tag, and 3 bits are used for the 802.1p priority.
3 bits doesn’t tell you much, and dealing with headers at layer 2 is a pain (since the headers get rewritten at every switch hop). The IP header also had 3 bits (called TOS), which was later expanded to 6 to form the DSCP value. DSCP is defined in RFC 2474, and tries to give more meaning to the value than simply a priority between 0 and 63. RFC 2474 actually defines a full byte for the DSCP header with the DSCP value taking the high order 6 bits and the two low order bits unused. RFC 3168 uses these values to implement Explicit Congestion Notification, sort of like BECN/FECN for IP.
Differentiated Services Field Codepoints is a good document on the suggested classifications, culled from various RFCs, with some of my comments:
Name Space Reference ---- ----- --------- CS0 000000 [RFC2474] CS* is used for compatibility with the old TOS bits CS1 001000 [RFC2474] so only the top 3 bits are used CS2 010000 [RFC2474] CS3 011000 [RFC2474] CS4 100000 [RFC2474] CS5 101000 [RFC2474] CS6 110000 [RFC2474] CS7 111000 [RFC2474] AF11 001010 [RFC2597] Assured Forwarding classes AF12 001100 [RFC2597] AF13 001110 [RFC2597] AF21 010010 [RFC2597] AF22 010100 [RFC2597] AF23 010110 [RFC2597] AF31 011010 [RFC2597] AF32 011100 [RFC2597] AF33 011110 [RFC2597] AF41 100010 [RFC2597] AF42 100100 [RFC2597] AF43 100110 [RFC2597] EF PHB 101110 [RFC3246] Expedited Forwarding, this should be priority queued ie for voice.
The CS tags are for compatibility with the older TOS. From RFC 2597, the definition of the AF class is:
The AF PHB group provides delivery of IP packets in four
independently forwarded AF classes. Within each AF class, an IP
packet can be assigned one of three different levels of drop
precedence.
The drop predence is tied to a QoS mechanism called Random Early Detection, which will be looked at in another article.
Though we’re getting out of the topic of classification, DSCP values don’t necessarily follow a strict order. For instance, I’ve seen documents suggesting that normal traffic be set with CS0, and defined “bad” traffic to have CS1.
That’s about it for classifying traffic until I start doing some examples. Once you have built your class-maps, you tie them to a behaviour using policy-maps, and then assign those to interfaces using service-policies. All in a future article!
No user commented in " QoS classification in a nutshell "
Follow-up comment rss or Leave a TrackbackLeave A Reply