Class Maps | Classification Tools

The primary classification tool within MQC is the class map. Each class map contains one or more match statements, which specify criteria that must be met for traffic identification

Because classmaps can contain multiple match statements, when a class map is defined, a logical operator for the discrete match statements also needs to be defined. Two options exist as follows:

• match-all (a logical AND operator), meaning that all match statements must be true at the same time for the class map condition to be true; match-all is the default operator; it is important not to use mutually exclusive match criteria when a match-all operator is defined within the class map, as this combination can never yield a positive match.
• match-any (a logical OR operator), meaning that any of the match statements might be true for the class map condition to be true.

These match statements specify the criteria for traffic identification. These can include the following:

• Layer 1 parameters: Physical interface, subinterface, PVC, or port
• Layer 2 parameters: MAC address, 802.1Q/p class of service (CoS) bits, Multiprotocol Label Switching (MPLS) Experimental (EXP) bits
• Layer 3 parameters: Differentiated Services Code Points (DSCP), source/destination IP address
• Layer 4 parameters: TCP or UDP ports
• Layer 7 parameters: Application signatures and URLs in packet headers or payload through Network Based Application Recognition (NBAR)

Figure 1 illustrates the Layer 2 to Layer 7 packet classification criteria; however, due to space limitations, the diagram is not to scale, nor are all fields indicated.

 
Figure 1: Layer 2 to Layer 7 packet classification criteria

Classification Tools | Network Quality of Service Technologies

Classification tools serve to identify traffic flows so that specific QoS policies can be applied to specific flows, such as TelePresence media and control flows. Often the termsclassification and marking are used interchangeably (yet incorrectly so); therefore, you need to understand the distinction between classification and marking operations:

• Classification refers to the inspection of one or more fields in a packet (the term packet is used loosely here to include all Layer 2 to Layer 7 fields, not just Layer 3 fields) to identify the type of traffic that the packet is carrying. When identified, the traffic is directed to the applicable policy-enforcement mechanism for that traffic type, where it receives predefined treatment (either preferential or deferential). Such treatment can include marking/remarking, queuing, policing, shaping, or any combination of these (and other) actions.
• Marking, on the other hand, refers to changing a field within the packet to preserve the classification decision that was reached. When a packet has been marked, a trust boundary is established, upon which other QoS tools later depend. Marking is only necessary at the trust boundaries of the network and (as with all other QoS policy actions) cannot be performed without classification. By marking traffic at the trust boundary edge, subsequent nodes do not have to perform the same in-depth classification and analyses to determine how to treat the packet.

MQC performs classification based on the logic defined within the class map structure. Such logic can include matching criteria at the data link, network, or transport Layer (Layers 2 to 4) or even at the application layer (Layer 7)

Modular QoS Command-Line Interface

As the Cisco QoS tools evolved, they became increasingly platform idiosyncratic. Commands that worked on one platform wouldn’t quite work on another, and there were always platform-specific requirements and constraints that had to be kept in mind. These idiosyncrasies made deploying QoS a laborious and often frustrating exercise, especially when deploying networkwide QoS policies, such as required by TelePresence. As an attempt to make QoS more consistent across platforms, Cisco introduced the MQC, which is a consistent, cross-platform command syntax for QoS.

Any QoS policy requires at least three elements:

1. Identification of what traffic the policy is to be applied to
2. What actions should be applied to the identified traffic
3. Where (that is, which interface) should these policies be applied, and in which direction

To correspond to these required elements, MQC has three main parts:

1. One or more class maps that identify what traffic the policies are to be applied to
2. A policy map that details the QoS actions that are to be applied to each class of identified traffic
3. A service policy statement that attaches the policy to specific interfaces and specifies the direction (input or output) that the policy is to be applied

As you see in the examples throughout this chapter, although the syntax of MQC might seem simple enough, it allows for nearly every type of QoS policy to be expressed within it and allows these policies, for the most part, to be portable across platforms.