As with any technology, as QOS matures and evolves, new developments always occur and features are always being added. However, before diving deeply into the specifics and all possible variations and evolutions of each QOS tool, the first step is to understand the basic structure of each tool. This topic presents a high-level view of the fundamental QOS tools. The complexities and specifics of these tools are explained in Part Two of this topic.
In a general sense, a QOS tool is simply a building block. It receives input, processes it, and produces specific output. The relationship between the input and output depends on the internal mechanisms of the QOS tools.
Examining each QOS building block separately, focusing on the results each one delivers, allows us to determine how to combine them to achieve the desired behavior.
To explain the QOS building blocks, this topic focuses on a single router that is part of a network in which QOS is implemented. The router has an ingress interface on which traffic arrives at the router, and an egress interface from which traffic departs the router. It is between these two interfaces that QOS tools are applied to the traffic.
Classifiers and Classes of Service
Classifiers perform a task that is somewhat analogous to an "identification" process. They inspect the incoming traffic, identify it, and then decide to which class of service it belongs.
The basis of QOS is traffic differentiation, and the concept of a class of service (CoS) is fundamental to the operation of QOS. Assigning traffic to different classes of service provides the necessary differentiation. From the point of view of a router, the class of service assigned to a packet defines how the router behaves towards it. The concept of traffic differentiation is present in every QOS tool, and as a result, classes of service are present across the entire QOS design.
A classifier has one input, the incoming packet, and it has N possible outputs, where N is the number of possible classes of service into which the packet can be classified. By definition, a classified packet is a packet assigned to a class of service.
Figure 2.1 The classifier operation
The decision made by the classifier regarding which class of service a packet belongs to can be seen as a set of IF/THEN rules, where the IF statement specifies the match conditions and, if those conditions are met, the THEN statement specifies the class of service into which the packet is classified, as illustrated in Figure 2.1.
Several possibilities exist for what can be used in the match conditions of the IF statements. The classifier can simply look at the ingress interface on which the packet has arrived and assign all traffic received on that interface to a certain class of service, based on a specific rule. Or, as another example, the classifier can use information that was placed in the packet headers by previous routers specifically for the purpose of telling downstream neighbors about a previous classification decision.
Coming back to the analogy of the routing and forwarding world, when an IP packet arrives at a router, a route lookup is performed to decide where the packet is destined. The classifier concept is similar: the classifier inspects the packet and makes a decision regarding the class of service to which it belongs.
The classifier tool can also be used in a chain fashion. In a scenario of N chain classifiers, the next-in-chain classifier receives packets that have already been classified, meaning that a class of service has already been assigned. This previous classification provides one extra input to be used in the match conditions of the IF/THEN set of rules.
Assuming for ease of understanding a scenario in which N = 2, a packet crosses the first classifier and exits with a class of service assigned to it. Then it reaches the second classifier, which has three possible choices regarding the previously assigned class of service: (1) to accept it as is; (2) to increase the granularity (for example, by splitting "Business" into "Business in contract" and "Business out of contract"); or (3) to change it completely. (A complete change is a somewhat awkward decision and is usually reserved only when correcting a previous classification error.)
Metering and Coloring – CIR/PIR Model
We discussed parameters such as delay and jitter that allow differentiation between different traffic types. However, one further step can be taken in terms of granularity, which is to differentiate first between traffic types and then, within a traffic type, to differentiate even further. Returning to the road metaphor, this is akin to differentiating first between trucks and ambulances, and then, for only ambulances, differentiating between whether the siren is on or off.
The metering tool provides this second level of granularity. It measures the traffic arrival rate and assigns colors to traffic according to that rate.
So looking at the classifier and metering tools together, the classifier assigns traffic to classes of service, which each have assigned resources, and the metering tool allows traffic inside a single class of service to be differentiated according to its arrival rate.
To achieve proper metering, we first present here a well- established model in the industry, the CIR/PIR (CIR, or committed information rate, and PIR, or peak information rate) model, which is inherited from the Frame Relay realm. However, it is first worth pointing out that this model is not part of any mandatory standard whose use is enforced. CIR/PIR is just a well – known model used in the networking world. One of the many references that can be found for it is RFC 2698 [1].
The foundations of this model are the definition of two traffic rates, CIR and PIR. CIR can be defined as the guaranteed rate, and PIR is the peak rate in terms of the maximum admissible traffic rate.
The CIR/PIR model has three traffic input rate intervals, where each has an associated color, as illustrated in Figure 2.2.
Traffic below the CIR is colored green (also commonly called -n-contract traffic), traffic that falls in the interval between the CIR and PIR is colored yellow (also commonly called out-of-contract traffic), and traffic above the PIR is colored red.
So following the CIR/PIR model, the metering tool has one input, the traffic arrival rate, and three possible outputs, green, yellow, or red, as illustrated in Figure 2.3.
Figure 2.3 The metering tool
Generally speaking, green traffic should have assured bandwidth across the network while yellow traffic should not, because it can be admitted into the network but it has no strict guarantee or assurance. Red traffic should, in principle, be discarded because it is above the peak rate.
Services that allow yellow traffic are popular and commonly deployed, following the logic that if bandwidth is available, it can be used under the assumption that this bandwidth usage does not impact other traffic types.
Commonly, metering is not a standalone tool. Rather, it is usually the sub-block of the policing tool that is responsible for measuring the traffic input rate. The policing building block as a whole applies predefined actions to each different color.
The Policer Tool
The policer tool is responsible for ensuring that traffic conforms to a defined rate called the bandwidth limit. The output of the policer tool is the traffic that was present at input, but that has been limited based on the bandwidth-limit parameter, with excess traffic being discarded, as illustrated in Figure 2.4.
The behavior of discarding excess traffic is also called hard policing. However, several other actions are possible. For example, the excess traffic can be accepted, but marked differently so it can be differentiated inside the router, a behavior commonly called soft policing.
The metering tool is commonly coupled with the policer as a way to increase the polic-er’s granularity. In this scenario, the metering tool measures the traffic arrival rate and splits the traffic into the three-color scheme previously presented. The policer is responsible for applying actions to the traffic according to its color, as illustrated in Figure 2.5.
Figure 2.5 Combining the policer and the metering tools
The policer can take one of several decisions regarding the traffic: (1) to transmit the traffic; (2) to discard it; or (3) to mark it differently and then transmit it.
Another capability associated with the policer tool is burst absorption.
In a scenario of linked meter and policer tools, the only difference is that the next step in the chain of meter and policer tool receives a packet that is already colored. This color provides an extra input parameter. The color previously assigned can be maintained, raised (e.g. from green to yellow), or lowered.
The Shaper Function
The shaper function causes a traffic flow to conform to a bandwidth value referred to as the shaping rate. Excess traffic beyond the shaping rate is stored inside the shaper and transmitted only when doing so does not violate the defined shaping rate. When traffic is graphed, you see that the format of the input traffic flow is shaped to conform to the defined shaping rate.
Let us illustrate this behavior using the example shown in Figure 2.6 . Here, an input traffic flow exceeds the defined shaping rate (represented as a dotted line) in the time interval between t0 and t1, and packet X (represented as a gray ball) is the last packet in the input traffic flow between t0 and t1.
Comparing the input and output traffic flow graphs, the most striking difference is the height of each. The height of the output traffic flow is lower, which is a consequence of complying with the shaping rate. The other difference between the two is the width. The output traffic flow is wider, because the traffic flows for a longer time, as a consequence of how the shaper deals with excess traffic.
Let us now focus on packet X, represented by the gray ball. At input, packet X is present at t1. However, it is also part of excess traffic, so transmitting it at t1 violates the shaping rate. Here, the shaper retains the excess traffic by storing it and transmits packet X only when doing so does not violate the shaping rate. The result is that packet X is transmitted at time t2.
Figure 2.6 The shaper tool
Effectively, the information present at the input and output is the same. The difference is its format, because the input traffic flow format was shaped to conform to the shaping rate parameter.
As Figure 2.6 also shows, the storage of excess traffic introduces delay into its transmission. For packet X, the delay introduced is the difference between t2 and t1.
As highlighted in topic some traffic types are more sensitive to the delay parameter, so the fact that the shaping tool inherently introduces delay to sustain excess traffic can make it inappropriate for these traffic types.
Also, the shaper’s ability to store excess traffic is not infinite. There is a maximum amount of excess traffic that can be retained inside the shaper before running out of resources. Once this point is reached, excess traffic is discarded, with the result that the amount of information present at the output is less than that present at input.
As with many other QOS tools, the shaper can also be applied in a hierarchical fashion, something we explore in the VPLS case study in this topic.
Comparing Policing and Shaping
A common point of confusion is the difference between policing and shaping. This confusion is usually increased by the fact that traffic leaving the policer conforms to the bandwidth limit value and traffic leaving the shaper conforms to the shaping rate, so at a first glance the two may seem similar. However, they are quite different.
Consider Figure 2.7 , in which the policer bandwidth limit and the shaping rate of the shaper are set to the same value, X, represented as a dotted line. The input traffic flow that crosses both tools is also equal, and between times t0 and t1 it goes above the dotted line.
The difference between the policed and the shaped flows is visible by comparing the two graphs. The main difference is how each tool deal with excess traffic. The policer discards it, while the shaper stores it, to be transmitted later, whenever doing so does not violate the defined shaping rate.
Figure 2.7 Comparing the policer and the shaper tools
The result of these two different behaviors is that the policed flow contains less information than the input flow graph because excess traffic is discarded, whereas the shaped output flow contains the same information as the input traffic flow but in a different format, because excess traffic was delayed inside the shaper.
Another point of confusion is that the command-line interface (CLI) on most routers allows you to configure a burst size limit parameter inside the policer definition.
The use of shaping to store excess traffic instead of dropping it has earned it the nickname of "TCP friendly," because for connection-oriented protocols such as TCP it is usually better to delay than to drop packets.
