In Part One of this book, 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 chapter, 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 chapter, we discuss the challenges of classifying traffic across multiple realms and also briefly introduce MPLS DiffServ-TE and its application regarding classification processes.

This book focuses on three specific realms, Ethernet, IP, and MPLS. In this chapter, 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.

5.1 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 experimental bits (EXP) 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 there is a standard field called type of service (TOS) that is eight bits long, as illustrated in Figure 5.1.

The first three bits (zero through two) are called the Precedence field, and it is in this field that the QOS markings 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 8 in the IP Precedence realm to 64 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.

5.2 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 chapter, 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. Previously in Chapter 2, we solved this problem by using the rewrite tool on router A.

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.

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 chapter.

5.3 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.

5.4 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 types 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 book always uses classification based on the packets’ QOS markings by default, although scenarios of combining this classification process with others are also explored.

5.5 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.

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 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.

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.

As previously discussed in Chapter 3, the aim should always be to create the fewest possible number of classes of service.

5.6 MPLS DiffServ-TE

In Part One of this book, 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 previously. MPLS DiffServ-TE LSPs (defined in RFC 3564 [2]) have all the previous 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.

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 chapter.

5.7 Mixing Different QOS Realms

So far, we have discussed scenarios consisting of a single realm in which the same technology is used from the source to the destination. Single-realm networks make things easier from the perspective of classifying traffic. However, in the real world, it is common to have a mix of technologies between the traffic flow end points. For example, the end points can be located in IP realms that are connected by MPLS networks.

Conceptually speaking, from a traffic flow perspective, we can have a source network, one or more transit networks, and a destination network. The challenge with such scenarios is that when a change of realm results in a change in the granularity of the classifiers, lack of the number of classes of service and the associated PHBs that are available at each network may occur.

There are two distinct real-life scenarios. In the first, the middle network belongs to a service provider that offers a set of standard services from which customers choose to use to interconnect its sites or networks. In this scenario, there is not much room for discussion because the customer picks services from a fixed set of available options.

The second scenario is one in which the middle network belongs to the same administrative domain as the source and destination networks. Because all three network segments are in the same domain, the classes of service and associated PHBs that are available on the middle network can be tuned to achieve the desired end-to-end consistency.

Let us start with an example of two IP realms (called A and B) and an MPLS realm in the middle. Routers belonging to each domain use the packets QOS markings as the classification parameter. This is illustrated in Figure 5.9.

Routers RA and RB are present at the border between the IP and MPLS realms. Traffic sourced in IP realm A travels to RA, where it is classified as an IP packet and then encapsulated into an MPLS tunnel. The traffic travels inside this tunnel to router RB, which classifies it as an MPLS packet, then decapsulates it, and sends it into the IP realm B as an IP packet.

The two IP realms use the packets’ DSCP markings as the classification parameter, which provides a granularity of up to 64 distinct QOS markings per packet. On the MPLS network (through which the IP traffic travels encapsulated), the classification parameter used is the EXP field, which provides up to eight different QOS markings. So this seems to be a problem, because two realms in which the classifier granularity is 64 are being connected by a realm in which the classifier granularity is eight.

In this situation, the first thing to bear in mind is that what matters is not the maximum granularity of the classifiers, which directly limits how many different classes of service can exist. The key point is not the maximum value but how many different classes of service must be implemented. That is, just because the DSCP field allows differentiating between 64 different types of packets, there is no obligation to implement 64 different classes of service in the network. The question should be how many classes of service are necessary rather than how to implement the maximum number.

Returning to the example in Figure 5.9, assume that IP realms A and B implement four different classes of service and packets belonging to each class of service are identified by their DSCP marking, as illustrated in Table 5.1.

The MPLS realm uses classification based on the EXP markings, which also allows a way to differentiate between four different types of packets. So consistency between the two realms is achieved by implementing four classes of service in the MPLS realm that are associated with the same PHBs as the four classes of service used in the IP realms, as illustrated in Table 5.2.

To make this example clearer, let us focus on a packet generated by the source that has the DSCP marking of 000 010. The packet arrives at router RA with this DSCP marking. The classifier inspects the packet’s QOS field, finds the DSCP value, and based on the rules shown in Table 5.1, classifies it into the COS3 class of service. RA is the router sitting at the border between the IP A and MPLS realms, so it receives the packet as an IP packet but sends it toward RB with an MPLS label on top of it. So when the packet leaves RA toward RB, it is tagged by RA with an MPLS label that contains an EXP value of 010, as illustrated in Figure 5.10.

Router RB receives the packet with an EXP marking of 010, and following the rules in Table 5.2, it classifies it into the class of service COS3 and applies PHB3. Because RB is the router connecting the MPLS realm and the IP realm B, it removes the MPLS label before injecting the packet into IP realm B.

As long as on routers RA and RB the PHB applied to packets belonging to COS3 is the same (it should be PHB3, according to Tables 5.1 and 5.2), consistency is achieved from the source to the destination.

The integration illustrated in Figure 5.10 is straightforward, because the classifiers present in the MPLS realm have enough granularity to differentiate traffic into the four different classes of service that are implemented in the IP realms.

The same scenario becomes more interesting if the IP realms implement more than 8 classes of services. Table 5.3 illustrates a case with 10 classes of service.

Having 10 classes of service exhausts the granularity of the classifiers present in the MPLS realm, as illustrated in Figure 5.11.

If an IP packet arrives at router RA with an DSCP marking of 001 000, it is classified into the class of service COS9. However, all the EXP markings inside the MPLS realm are already being used to identify traffic belonging to the classes of service from COS1 to COS8, so no more EXP values are available to identify traffic belonging to the class of service COS9, or, for that matter, to COS10.

As with many things in the QOS realm, there are several possible ways to solve this problem. We present one solution based on increasing the classifier granularity by using the information regarding the inbound interface on which traffic is received.

The physical interface that connects routers RA and RB is split into two logical interfaces. Two MPLS tunnels (named L1 and L2) are created between RA and RB, and L1 is established across the first logical interface and L2 over the second. At RA, rules are implemented so that the selection of the tunnel to reach RB (either L1 or L2) is done according to the packet’s QOS marking. This is accomplished with the help of routing policies, as illustrated in Figure 5.12.

The result of this split is that router RB receives traffic from two separate MPLS tunnels on two separate logical interfaces. When this tunnel arrangement is combined with classifiers that look at the packets’ QOS marking and that are specific for each logical interface, the desired 10 classes of service inside the MPLS realm can be implemented, as illustrated in Table 5.4.

Table 5.4 shows an overlap in that the same EXP marking is used to identify packets belonging to different classes of service. However, there is no ambiguity, because the value of the EXP field is used together with the information regarding the MPLS tunnel from which was the packet received. Returning to the network topology we used previously, Figure 5.13 illustrates the implementation of such a scheme.

This scheme does work and accomplishes the desired goal, but it is achieved at the expense of increasing the complexity of the network. The solution requires the creation of multiple tunnels between the source and the destination, the usage of logical interfaces, the introduction of routing policies, and the definition of classifiers on a per-interface basis. For a scenario with only two routers in the middle network, the task is easily doable. However, it is not quite the same with routers of the order of tens or hundreds.

5.8 Conclusion

Currently, classification based on packet QOS markings is without a doubt the most popular and widely deployed method, because of its simplicity in terms of using fields standardized for each technology and its ease of implementation. The other two types of classifiers presented in this chapter, interface-based and deep packet inspection, are commonly used as auxiliaries when it is necessary to increase granularity.

The maximum number of classes of service that can exist inside a QOS realm is limited by the classifier granularity. In addition, the required classifier granularity needs to be considered if there is a requirement to signal information between routers.

Mixing QOS realms may raise some challenges if there are differences between the granularity of the classifiers used in the different realms, as discussed in this chapter. The solution is typically to increase the granularity by combining the packets’ QOS markings with other classification processes.

References

1. [1] Nichols, K., Blake, S., Baker, F. and Black, D. (1998) RFC2474, Definition of the Differentiated Services Field, December 1998. https://www.rfc-editor.org/rfc/rfc2474.txt (accessed September 8, 2015).
2. [2] Le Faucheur, F. and Lai, W. (2003) RFC3564, Requirements for Support of Differentiated Services-Aware MPLS Traffic Engineering, July 2003. https://www.ietf.org/rfc/rfc3564.txt (accessed August 19, 2015).