Trust Borders
When traffic arrives at a router, in terms of QOS, the router can trust it or not. The term trust can be seen from two different perspectives. The first is whether the information present in the packets is valid input for the classifier deciding the class of service to which the packets belong. The concern is assuring that the classifier is not fooled by any misinformation present in the packets, which could lead to traffic being placed in an incorrect class of service.
The second perspective is whether an agreement has been established between both parties regarding the amount of resources that should be used at the interconnection point. The question here is whether the router can trust the other side to keep its part of the agreement, or whether the router needs to enforce it.
If two routers belong to the same network, it is expected that the downstream router can trust the traffic it receives from its neighbor, and also that the neighbor is complying with any agreement that has been established. However, this is not the case at the border between networks that belong to different entities.
A trust border is a point where traffic changes hands, moving from using the resources of one network to using those of another network. The term "different" should be seen from a control perspective, not from a topology perspective, because it is perfectly possible for the same entity to own two different networks and hence to be able to trust the information they receive from each other at the interconnection points.
An agreement regarding resources usage usually is in place at trust borders. However, the network that receives the traffic cannot just assume that the other side is keeping its part of the agreement; it needs to be sure of it. So two conditions need to imposed: first, any traffic that should not be allowed in the network because it violates the agreement should get no farther, and, second, traffic needs to be trusted before being delivered to the next downstream router, effectively before entering the network trust zone.
Let us illustrate the points in the previous paragraphs with a practical example. Assume that the service contracted by a customer from the network is a total bandwidth of 10 Mbps (megabits per second) and that two classes of service have been hired, voice and Internet, where voice packets are identified by having the marking X. Bandwidth in the voice class is more expensive because of assurances of lower delay and jitter, so from the total aggregate rate of 10 Mbps hired, the customer has bought only 2 Mbps of voice traffic.
Figure 3.18 The border between trust zones
Let us assume that the customer is violating the agreement by sending 20 Mbps of traffic and all packets are marked X, a situation which, if left unchecked, can lead to the usage of network resources that are not part of the agreement (see Figure 3.18).
Before allowing traffic that is arriving from the customer to enter the network trust zone, the border router needs to make it conform to the agreement made by limiting it to 10 Mbps and by changing the markings of packets above the rate hired for voice traffic.
The change of the packets markings is necessary because, following the PHB concept, the next downstream router applies the classifier tool, and packets with the wrong marking inside the trust zone have the potential of fooling the classifier and jumping to a class of service to which they should not have access. Another possible option is for the border router to simply drop the packets that contain an incorrect marking.
An interesting scenario is the one of a layered network, for example, MPLS VPNs, in which traffic is received from the customer as Ethernet or IP and transits through the network encapsulated inside MPLS packets. Here, the information contained in the Ethernet or IP packets header is not relevant inside the network, because the routers inspect only the MPLS header. We explore such a scenario in the case studies in Part Three of this topic.
Granularity Levels
Routers inside a network fall into two main groups: routers that are placed at the edge of the network, commonly named PE (provider edge), and core routers, commonly named P (provider). From a QOS perspective, the key differentiation factor between PE and P routers is not their position in the network topology but the types of interfaces they have. A PE router has two types of interfaces, customer and core facing, while P routers only have the second type.
A core-facing interface is where the connection between two network routers is made, and a customer-facing interface is where the service end points are located. A core or customer-facing interface is not required to be a physical interface. It can also be a logical interface such as, for example, a specific VLAN in a physical Ethernet interface.
Figure 3.19 Customer and core – facing interfaces
The division between interface types is interesting because of the granularity levels that need to be considered at each stage. Let us start by considering the example in Figure 3.19 . which shows three customers, numbered 1 through 3, connected to the PE router, on two physical customer-facing interfaces (P1 and P2), and where traffic flows to or from the other network router via a core-facing interface.
Customer 1 uses service A and customer 2 uses service B, and both services are classified into COS1. Customer 3 uses service C, which is classified into COS2. The physical interface P1 has two logical interfaces, L1 and L2, on which the service end points for customers 1 and 2, respectively, are located. The interest in differentiating between types of interfaces is being able to define the required granularity levels.
All traffic present in the network should always be classified to ensure that there is never any doubt regarding the behavior that should be applied to it. As such, the lowest level of granularity that can exist is to simply identify traffic as belonging to one class of service, which encompasses all customer services and any other network traffic mapped to that class of service. A higher level of granularity would be to identify traffic as belonging to a certain class of service and also to a specific customer.
A core-facing interface has no service end points because it operates as a transit point, where traffic belonging to multiple classes of service flows through it. As such, the granularity level required is usually the lowest one. A core-facing interface does not need to know which particular customer the traffic belongs to. Returning to Figure 3.19, the core interface has no need to be concerned if the traffic mapped into COS1 that crosses it belongs to service A or B, or to customer 1 or 2. All it should be aware of is the class of service to which the traffic belongs, because, in principle, traffic from two customers mapped to the same class of service should receive the same behavior from the network. However, the core interface always needs to be able to differentiate between the different classes of service, COS1 and COS2, to be able to apply different behaviors to each.
As for customer-facing interfaces, the granularity level required is usually the highest. In Figure 3.19, two service end points are located on physical interface 1, so just knowing the class of service is not enough. It is also necessary to know the specific customer to which the traffic belongs. An interesting scenario is that of customer 3, who possesses the only service end point located on physical interface 2. For this particular scenario of a single service end point on one physical interface, the interface itself identifies the customer so the granularity level required can be the lowest.
It is important to identify the necessary granularity levels at each interface because this has a direct bearing on how granular the QOS tools need to be. In Figure 3.19, in the core interface traffic belonging to the class of service COS1 can all be queued together. However, on the customer-facing interface 1, queuing should be done on a per-customer basis, because the same interface has multiple service end points.
In a nutshell, core-facing interfaces typically should have the lowest granularity level (that is, these interfaces should be aware only of class of service) and customer-facing interfaces should have the highest granularity level (that is, these interfaces should be aware of both the customer and the class of service). However, exceptions can exist, as highlighted for customer 3.
When designing the network and deciding which tools to apply on each interface, the required granularity levels make a difference when selecting which QOS tools are necessary and how granular they need to be. These choices are typically closely tied with the hardware requirements for each type of interface.
Control Traffic
So far, we have focused the discussion on QOS on customer traffic that transits the network between service end points. But there is also another type of traffic present, the network’s own control traffic.
There are two major differences between control and customer traffic. The first is that control traffic results from the network operation and protocol signaling, and provides the baseline for the connectivity between service end points on top of which customer traffic rides. In other words, control traffic is what keeps the network alive and breathing. The second difference is that the source of control traffic is internal. It is generated inside the network, while the customer traffic that transits the network between the service end points comes from outside the network.
As a traffic group, control traffic encompasses several and different types of traffic, for example, that for routing protocols and management sessions.
Let us provide a practical example, illustrated in Figure 3.20. Here, customer traffic crosses the network, and router A issues a telnet packet destined to router B.
Figure 3.20 Control traffic in the network
Also because a routing protocol is running between the two routers, hello packets are present.
The two routers have different perspectives regarding the control packets. Router A has no ingress interface for them, because they are locally generated control packets. As for router B, the control packets arrive on a core-facing interface together with any other traffic that is being transmitted between the two routers.
Starting by looking at router A, how it deals with locally generated control traffic is highly vendor- specific. Each vendor has its implementation regarding the priorities assigned to the traffic, the QOS markings of such packets, and which egress queues are used.
For router B, the classifier has to account for the presence of control traffic so that it can be identified and differentiated from the customer traffic. This is just like what happens with any traffic that belongs to a specific class of service.
It is good practice to keep the network control traffic isolated in a separate class of service and not to mix it with any other types of traffic due to its importance and unique character. Even if the behavioral requirements of control traffic are similar to those for other types of traffic, this is the only situation in which the similarities should be ignored, and a separate class of service should be reserved for control traffic.
Trust, Granularity, and Control Traffic
We have been discussing several of the challenges that exist in a QOS network, including the trust borders between a network and its neighbors, the different granularity levels to be considered, and the presence of control traffic. Now we bring these three elements together and present a generic high-level view of a traffic flow across two routers.
In Figure 3.21. a unidirectional traffic stream (for ease of understanding) flows from customer site number 1 to site number 2. Packets belonging to this stream are represented as white packets, and the service is supported by two routers, named R1 and R2.
The first point encountered by the customer traffic flow is the service end point at the customer-facing interface on R1. This is the border between the customer and the service and, being a service end point, its granularity level is the highest so it should be customer aware.
Figure 3.21 Traffic flow across two network routers
Traffic originating from the customer is, in principle, considered untrustworthy, so the first step is to classify the customer traffic by assigning it to a class of service and to enforce any service agreements made with the customer, usually by applying the metering and policing functionalities or even more refined filtering based on other parameters that can go beyond the input rate of the traffic or its QOS markings.
Although traffic can be assigned to multiple classes of service, we assume in this example that it is all assigned to the same class of service.
The next interface is the core-facing interface that connects routers 1 and 2, which the customer traffic is crossing in the outbound direction. As with any core-facing interface, it should be class- of- service aware, not customer aware, in terms of granularity. The customer traffic is grouped with all other traffic that belongs to the same class of service, and queued and scheduled together with it. Because it is a core-facing interface, in addition to customer traffic, network control traffic is also present, so the queuing and scheduling rules need to account for it. Optionally at this point, rewrite rules can be applied, if necessary, to signal to the next downstream router any desired packets differentiation or to correct any incorrect markings present in the packets received from the customer. This particular step is illustrated in Figure 3.22 . Triangular packets represent control traffic packets that exist on any core-facing interface. White and black packets are mixed in the same queue because they belong to the same class of service, with white packets belonging to this particular customer and black packets representing any other traffic that belongs to the same class of service.
Now moving to the core interface of router 2. The first step is classification; that is, inspecting the packets’ QOS markings and deciding the class of service to which they should be assigned. Being a core-facing interface, the classifier also needs to account for the presence of network control traffic. All the traffic received is considered to be trusted, because it was sent from another router inside the network, so usually there is no need for metering and policing or any other similar mechanisms.
The final point to consider is the customer-facing interface, where traffic exits via the service end point towards the customer. Being a service end point, it is typically customer and class-of-service aware in terms of granularity. At this point, besides the queuing and scheduling, other QOS tools such as shaping can be applied, depending on the service characteristics. This example can be seen as the typical scenario but, as always, exceptions can exist.
Figure 3.22 Queuing on a core facing interface
Conclusion
Throughout this topic, we have focused on the challenges that the reader will find in the vast majority of QOS deployments. The definition of classes of service is a crucial first step, identifying how many different behaviors are required in the network and avoiding an approach of "the more, the better."
Another key point that now starts to become visible is that a QOS deployment cannot be set up in isolation. Rather, it depends closely on other network parameters and processes. The network physical interfaces speeds and physical media used to interconnect the routers have inherent delay factors associated with them. Also, the network routing process may selectively allow different types of traffic to cross certain network hops, which translates into different traffic types being subject to different delay factors. So how the QOS deployment interacts with the existing network processes may limit or expand its potential results.
