In Part One of this topic, we discussed the concept of Per-Hop Behavior (PHB), in which each router in the network independently implements its own QOS settings because no signaling is possible either between neighbors or end to end. Consistency is achieved by applying a QOS configuration on each router in the network that applies the same PHB to traffic belonging to each class of service at each hop along the path that the traffic takes through the network.
In Part One, we also described the classifier tool, which assigns a class of service to each packet. This assignment is a crucial and fundamental step in the QOS realm because identifying traffic is the key factor in knowing the class of service to which it belongs. It is the class of service that determines the PHB that is applied to the traffic.
As previously discussed, the classifier tool has one input and N possible outputs. The input is the packet itself, and the N possible outputs are the number of different classes of service into which the packet can be classified. Classification can be considered to be an operation implemented using a set of IF/THEN rules, applied in the form of "IF (match conditions), THEN (class of service assignment)."
In this topic, we focus on the types of classification processes that are currently commonly used, and we examine the differences between them in terms of the options available for the "IF (match conditions)" set of rules applied by the classifier. We also compare and debate the usage of the different classification processes.
At the end of the topic, we discuss the challenges of classifying traffic across multiple realms and also briefly introduce MPLS DiffServ-TE and its application regarding classification processes.
This topic focuses on three specific realms, Ethernet, IP, and MPLS. In this topic, when a specific realm is mentioned, the realm relates to the level at which the packet is processed by the classifier. For example, in a network in which IP (OSI Layer 3) packets travel over an Ethernet (OSI Layer 2) support, the network is called an Ethernet or an IP realm according to whether the classifier inspects the packet as an Ethernet or as an IP packet.
Packet QOS Markings
Currently, classifier processes based on the packets’ QOS markings are the most straightforward and unquestionably the most popular ones. Each packet contains a field in which the QOS markings are located, although the exact location and length of the field vary according to the technology. However, the key point is that the standard for each technology defines a QOS field, so it is mandatory for that field to always be present.
The classifier inspects the packet, targeting the known location of the QOS marking, reads the bits in that field, and then makes a classification decision. Viewed from the perspective of the IF/THEN set of rules, the classifier takes the generic format of "IF packet QOS marking = X, THEN assign it to the class of service Y."
The packet classification process is straightforward because the classifier knows where in each packet to look for the QOS markings and because all packets always have those markings present at that location, since the location and the length of the packets’ QOS markings are defined as part of the technology standards.
The only drawback of this type of classification process is that the number of bits used in the QOS field is necessarily finite for any given technology, so there is always a maximum number of different possible values available for a packet’s QOS marking.
In the Ethernet realm, a VLAN-tagged Ethernet packet has a standard field called "User Priority" that is three bits long, thus providing up to eight different values for the QOS marking.
Similarly, in the MPLS realm, an MPLS label contains a standard field called EXP (Experimental bits) that is also three bits long, providing up to eight different values for the packets QOS marking just as in the Ethernet realm.
In both Ethernet and MPLS realms, it is also possible to implement stacking, which consists of packets with multiple VLAN tags or MPLS labels, respectively. Using as an example an Ethernet packet with two VLAN tags, the classifier can use as parameters the QOS marking in the outer VLAN tag or in the inner VLAN tag, or both. The exact same logic applies to MPLS packets with multiple labels.
In the IPv4 realm, things are slightly different. Inside each IP packet is a standard field called TOS (type of service) that is eight bits long, as illustrated in Figure 5.1.
Figure 5.1 TOS field in IPv4 packets
The first three bits (zero through two) are called the precedence field, and it is in this field that the QOS marking are placed, thus providing eight different possible QOS markings. Bits three, four, and five define service requirements regarding delay, throughput, and reliability. However, these bits were never properly implemented and are not honored by the majority of the applications in the IP realm, so it’s fair to say that only the first three bits in the TOS field are relevant.
RFC 2474 [1] redefined the TOS field in the IP header as a 6-bit Differentiated Services Code Point (DSCP) field, so bits zero through five are all available for QOS markings, and bits six and seven continue to be reserved. The DSCP field boosts the possible distinct QOS markings from eight in the IP Precedence realm to sixty-four in the IP DSCP. From a conceptual point of view, there are no differences between using classifiers based on the IP Precedence or on the DSCP field; it’s just a question of how many bits of the IP packet the classifier evaluates. However, care should be taken not to mix IP precedence and DSCP classifiers, because bits three to five are irrelevant for IP precedence but are relevant for DSCP. In the IPv6 realm, there is no such distinction: IPv6 packets contain a single field that is used for QOS markings.
Inbound Interface Information
Another parameter that can be used for classifying traffic is the interface on which the packet was received. Note that throughout this topic, the term interface can mean a logical interface (such as an Ethernet VLAN or an MPLS tunnel) or a physical interface (e.g. a Gigabit Ethernet interface).
Being able to use the inbound interface in a standalone fashion translates into very simple classification rules. Thus, all traffic received on a specific interface belongs to a specific class of service. From the perspective of the IF/THEN set of rules, the rules have the generic form "IF traffic is received on interface X, THEN it belongs to class of service Y."
There is an implicit trade-off between simplicity and flexibility, because such types of rules are inadequate for scenarios in which interfaces receive traffic that belongs to multiple classes of service. In fact, it is for this reason that this classification process is not commonly deployed on its own. However, when combined with other classification processes, knowing the inbound interface can improve the granularity of classification, for example, allowing a match on the packets’ QOS markings and also on the interface on which they were received. Let us present an example of this approach by using the scenario in Figure 5.2, which shows two packets with the same QOS marking of X. We wish to signal to our downstream neighbor that each packet should be treated differently.
Router A has two packets numbered 1 and 2, and both of them are classified in the class of service named COS1. However, packet 2 is marked as yellow, a classification that we want to signal to the next downstream router.
Figure 5.2 Classification based on the packets’ QOS markings and input interface
The solution illustrated in Figure 5.2 is to have a classification process on router B that is based on the packets’ QOS markings and also on the interfaces on which the packets are received. This means that a marking of X on the first ingress interface represents a packet that belongs to the class of service COS1 and that is green, while the same marking on the second ingress interface translates into the same class of service but with the color yellow.
So combining the processes for interface and QOS marking classification allows the same packet QOS marking to have a different meaning depending on the interface on which it is received.
However, the price for this is an increase in complexity, because this mechanism requires the use of multiple interfaces to connect the two routers (although the interfaces can simply be different logical interfaces on the same physical interface), and also because interface – specific classifiers must be defined.
In summary, interface – based classification is usually too rigid to be used in a standalone fashion, although when possible it is the simplest classification process possible. When combined with classification based on the packets’ QOS markings, interface-based classification opens a pathway for packets with the same QOS marking to be assigned to different classes of service according to the interface on which they were received, a scenario that we explore later in this topic.
Deep Packet Inspection
Deep packet inspection enters the next level of packet classification, in terms of depth, going beyond the straightforward packet QOS markings and moving from a macroscopic level to a microscopic one. The advantage of the microscopic level is granularity. For example, two packets with the exact same QOS marking can belong to different OSI Layer 4 protocols, or they can belong to the same Layer 4 protocol but have different session attributes, such as using different port numbers. Or going even further, discovering and identifying P2P ( peer- to – peer ) traffic on a network is a difficult task, because even at Layer 4 it is not possible to map this type of traffic to fixed or well-known port numbers. The only visible proof for P2P traffic is the traffic pattern and volume, and so only by inspecting the packet payload can P2P traffic be identified.
Deep packet inspection provides a huge boost in term of the match parameters that can be used in the IF/THEN set of rules implemented by a classifier. However, too much granularity can have a negative impact when it comes to the implementation stage. If the rules use highly granular parameters, then to cover all possible scenarios and all possible combination, it is necessary to have a huge number of rules. Let us give an example of this behavior for a classifier that matches on Layer 4 protocol and on the source port. If a classifier rule is defined to map TCP traffic with a source port of 80 to a certain class of service, it is also necessary to define rules for all other possible combinations of traffic that are not TCP and that do not use source port 80.
The situation illustrated in this example is the reason why deep packet inspection is usually not used as a standalone classification process. Its granularity can lead to the definition of a huge number of rules to cover all possible scenarios.
However, deep packet inspection can be combined with simpler classification processes to help pinpoint certain types of traffic that require a more in depth inspection, while leaving the handling of all possible scenarios to the simpler classification process.
Selecting Classifiers
At the time of writing, classification based on the packets’ QOS markings is unquestionably the most popular and commonly deployed classification process. The main reason is ease of implementation, because each Ethernet, IP, and MPLS packet has a standardized field in which the QOS marking is present. This means that the classifier knows beforehand that a QOS field is present in the packet and knows its exact location.
As previously mentioned, the only drawback is that such fields have a finite length, so they have a maximum number of possible different values. However, in a certain sense, such a limitation has a positive implication in terms of simplicity and scaling, because the maximum number of rules that need to be defined (in the format "IF match marking, THEN …") is also limited.
The two other type of classifiers already discussed, interface-based and deep packet inspection, have their flaws as standalone processes. Interface-based classifiers are often too rigid, and deep packet inspection classifiers can drastically increase granularity but potentially leading to the creation of a large number of classification rules. However, these two classifiers can, without a doubt, become powerful allies for a simpler classification process, such as one based on the packets’ QOS markings, by increasing its granularity or pinpointing specific types of traffic.
When selecting a classification process, one factor to take into account is the lack of signaling inside the network. One result of this limitation is that the only way to signal information between adjacent routers is to change the parameters used by the classifier on the next downstream router. If the classifiers are based on the packets’ QOS markings, this task is achieved by using the rewrite tool, as explained in Part One. This points to another advantage of using the packets’ QOS markings: because the QOS markings are in a standardized field, this field is present in all packets, and changing it is bound to have an effect on the classification process of the next downstream router. Interface- based classifiers obviously do not allow this flexibility, and deep packet inspection has the drawback that rewriting information present at Layer 4 or above can effectively impact the service to which the packet belongs.
For these reasons, this topic always uses classification based on the packets’ QOS markings by default, although scenarios of combining this classification process with others are also explored.
The QOS Network Perspective
From a network perspective, there are several possibilities regarding the classification process, but they all serve the same purpose: assigning packets to a certain class of service. A QOS-enabled network has two or more classes of service, because if there were only one, it would effectively be equivalent to a network without QOS.
When a generic packet named X with a certain QOS marking arrives at a router, the classifier inspects the packet’s markings. Then, according to its set of IF/THEN rules, the router decides to which class of service the packet belongs, which translates into the PHB the router applies to it, as illustrated in Figure 5.3 There is no signaling, so this process is repeated on all the routers that the packet encounters as it crosses the network.
As packet X crosses the network routers, its QOS marking can be changed if any of the routers applies the rewrite tool, or the marking can be left untouched.
This mechanism is the basis of the PHB concept: a packet arrives at a router, and it is classified into a class of service and treated inside the router according to the PHB specified for that class of service. When the packet leaves the router, the previously performed classification is effectively lost and all the classification steps are repeated on the next downstream router.
Figure 5.3 Classification occurs at each hop
Figure 5.4 Possible values of the IP Precedence field
Coherency is achieved by deploying classifiers on each of the routers crossed by the packets that ensure that packets requiring a certain PHB from the network are classified into the appropriate class of service.
As previously discussed, the classifier tool differentiates between different packets by assigning them to different classes of service, which implies that the maximum number of different classes of service that can exist in a network is limited by the parameters used by the classification process. Let us illustrate this by returning to the previous example and adding more detail. Assume an IP realm in which the classifiers used by the routers are solely based on the IP precedence field, which, as previously discussed, is a three-bit field, thus providing a maximum of eight different values, as illustrated in Figure 5.4.
Now, the router classifier looks at the IP Precedence field of the packets it receives and can find a maximum of eight different values. So from a classifier perspective, there are, at most, eight different types of packets, with each type identified by a unique IP Precedence bits combination. These combinations represent the classifier granularity, that is, the number of different packets between which the classifier is able to differentiate. There is a direct relationship between the classifier granularity and the number of different classes of service the classifier can assign packets to.
In Figure 5.5, the maximum number of classes of service the network can implement is eight, because this is the maximum granularity of the classifiers used. However, because of the lack of signaling, any specific requirements regarding differentiating packets belonging to a certain class of service that need to be signaled also use the packets’ QOS markings, because this is the parameter used by the next downstream router. The result is a trade-off between the maximum number of classes of service and having more granularity within some of the classes of service.
Let us illustrate this behavior for an MPLS realm. We are purposely changing realms to illustrate that the PHB concept is indeed independent of the underlying technology. Figure 5.6 shows two MPLS packets crossing several network routers sequentially. The
Figure 5.5 Classifier granularity and limit to the number of classes of service
Figure 5.6 One EXP marking per class of service
EXP field in both packets is zero, which means that they should be placed into the class of service C1, based on the set of rules present in the classifiers that inspect the EXP field.
Now assume that the first router makes a differentiation between the two packets, considering that both belong to the class of service C1 but that the first one is in-contract and the second one is out-of-contract. If the first router desires to share this distinction with the next downstream router, it must change the parameter used by the next downstream router classifier, the EXP field, as illustrated in Figure 5.7.
By having the first router change the EXP value of the second packet to 001 and by properly deploying IF/THEN rules across the other network routers, it is possible to make the entire network aware that the first packet belongs to class of service C1 and is in-contract traffic, while the second packet belongs to the same class of service but represents out-of-contract traffic. Doing so effectively consumes two EXP values (out of eight maximum values) to provide differentiation within class of service C1, leaving six values available for use by other classes of service. Also bear in mind that all the possible EXP markings may not be available to differentiate between a customer’s traffic because some of them may be required to identify network control traffic or other types of internal traffic.
Figure 5.7 Two EXP markings per class of service
In a nutshell, the classification process used by a network places limits both on how many different classes of service can exist in the network and on how information can be signaled to the next downstream router. So if the desire is to implement X number of classes of service in a network, the classification process chosen must be able to provide the necessary granularity while also allowing proper signaling between neighbors, if required.
Returning to the example of having eight different class-of-service values, eight may seem like a small number, but until now, both authors have not yet found a greenfield QOS network deployment that needed to implement more than eight classes of service. While this may sound odd, keep in mind that in a QOS world it ‘ s all about splitting resources across classes of service, so surely we can increase the divisor (number of classes of service), but the dividend (resources) remains constant.
MPLS DiffServ-TE
In Part One of this topic, we highlighted the MPLS-TE capabilities of establishing LSPs with bandwidth reservations end to end and to have traffic follow a path different from the one selected by the routing protocol.
As a quick recap of what has been previously presented, bandwidth reservations limit the resource competition for bandwidth for traffic that is placed inside an LSP, because all other traffic present on the network does not compete for bandwidth access with traffic in the LSP. However, a gatekeeper mechanism at the ingress node is still required to enforce the fact that the bandwidth limit is not exceeded. Also, the ability to specify a path for the LSP different from the one chosen by the routing protocol creates the possibility of having multiple LSPs following different paths from each other, which affects the delay to which traffic inside each LSP is subject.
Although MPLS- TE has all these capabilities, it is blind in terms of the classes of service of the traffic it carries. An MPLS-TE LSP works simply as a tunnel that has the properties explained above. MPLS DiffServ-TE LSPs (defined in RFC 3564 [2]) have all the above properties and are also class- of-service aware.
The goal of MPLS DiffServ-TE is to allow the establishment of LSPs across the network, where each LSP contains traffic belonging to a specific class type ( CT ). A single CT can represent one or more classes of service, but for ease of understanding, let us assume a one-to-one relationship between CTs and classes of service. RFC 3564 defines eight CTs, although it is not mandatory to implement all eight across the network.
Across an MPLS DiffServ-TE network, each router has a traffic – engineering database that specifies how much bandwidth is being consumed and how much is available to be reserved on a per-CT basis.
The classification processes at the ingress node, where the LSP starts, map traffic to a certain class of service based on a set of IF/THEN rules. Then, based on the assumption of a one-to-one relationship between CTs and classes of service, each MPLS DiffServ-TE LSP carries traffic belonging to one class of service. This assumption drastically simplifies the classification task for the transit nodes, because traffic received on one MPLS DiffServ-TE LSP belongs to only one class of service. Thus, in terms of the IF/THEN set of rules, the task on the transit nodes boils down to being able to infer the class of service to which the traffic belongs to, based on simply knowing the LSP on which the traffic was received. If we consider each MPLS DiffServ-TE LSP to be a logical interface, the dynamics are similar to an interface-based classification process, as illustrated in Figure 5.8.
The scenario in Figure 5.8 shows four types of packets. The classifier present on the ingress router classifies the packets into two classes of service, COS1 and COS2. The details of the classification process used by the ingress router are not relevant for this example. Now packets belonging to each class of service are placed inside a specific MPLS DiffServ-TE LSP, which greatly simplifies the task performed by the transit router: the class of service to which traffic belongs to is determined by knowing on which LSP the traffic was receive.
Figure 5.8 Classification in the MPLS DiffServ-TE realm
MPLS DiffServ-TE is a complex topic, and the previous paragraphs are an extremely simple introduction that focuses only on the classification processes. A reader not familiar with MPLS DiffServ- TE or seeking more detail should check out the further reading section at the end of this topic.
