Assure Forwarding PHB Group

Previous

1.5.- Assure Forwarding PHB Group

Continuing with our method of study let's start again presenting the original specification, this time the RFC 2597 specification, and then doing some comments when required.

This document defines a general use Differentiated Services (DS) [Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). The AF PHB group provides delivery of IP packets in four independently forwarded AF classes. Within each AF class, an IP packet can be assigned one of three different levels of drop precedence. A DS node does not reorder IP packets of the same microflow if they belong to the same AF class.

According to this, the new PHB is going to have four classes to be known as AF classes. We saw somewhere above that Differentiated Service architecture is based on classes of service that are identified by using the 3-leftmost bits of the DS-codepoint. But something very interesting is being proposed here: within each AF class an IP packet can be assigned to one of three different levels of drop precedence. What do we have here? First, IP packets of the same microflow can not be reordered; just common sense to protect the connection behavior. Second, within a class we can have three different treatments, or better yet, three different subclasses. How do we discriminate between subclasses? Just by using something called "drop precedence". Let's continue reading for a better definition.

Within each AF class IP packets are marked (again by the customer or the provider DS domain) with one of three possible drop precedence values. In case of congestion, the drop precedence of a packet determines the relative importance of the packet within the AF class. A congested DS node tries to protect packets with a lower drop precedence value from being lost by preferably discarding packets with a higher drop precedence value.

Very interesting. The drop precedence of a packet is not more than the relative importance of the packet within the class. As higher the drop precedence of a packet is it's going to be higher the probability that this packet can be discarded (dropped) when things go worse and congestion begin to destroy our happy world. Observe here that what they are trying to implement is what we called before a "discriminatory world". We have not only four different classes to classify our packets (citizens); using our criteria we can assign different network resources to each of these classes, but also, within the same class we can extend our hierarchy even more allowing some packets to have a better probability to survive than other, in case of congestion.

Observe that congestion is the devil that fires this last sub-hierarchy. Even when congestion is present or not resource distribution is going to be done between AF classes according to some previously specified rules (policies). This first hierarchy defines primarily a resource distribution. But when congestion appears we fire our second hierarchy control treating some packets better than other according to what is called the "drop precedence". Up to here everything is clear but let's continue reading the specification to see what they are reserved for our knowledge appetite.

In a DS node, the level of forwarding assurance of an IP packet thus depends on (1) how much forwarding resources has been allocated to the AF class that the packet belongs to, (2) what is the current load of the AF class, and, in case of congestion within the class, (3) what is the drop precedence of the packet.

For example, if traffic conditioning actions at the ingress of the provider DS domain make sure that an AF class in the DS nodes is only moderately loaded by packets with the lowest drop precedence value and is not overloaded by packets with the two lowest drop precedence values, then the AF class can offer a high level of forwarding assurance for packets that are within the subscribed profile (i.e., marked with the lowest drop precedence value) and offer up to two lower levels of forwarding assurance for the excess traffic.

Overwhelming. No doubt. These paragraphs show us that we are in presence of one of the most flexible and powerful technology for QoS services with the additional advantage of requiring limited resources to be implemented. Flexible, powerful and scalable. Possibilities are endless. Really an amazing technology.

Assured Forwarding (AF) PHB group provides forwarding of IP packets in N independent AF classes. Within each AF class, an IP packet is assigned one of M different levels of drop precedence. An IP packet that belongs to an AF class i and has drop precedence j is marked with the AF codepoint AFij, where 1 <= i <= N and 1 <= j <= M. Currently, four classes (N=4) with three levels of drop precedence in each class (M=3) are defined for general use. More AF classes or levels of drop precedence MAY be defined for local use.

A DS node SHOULD implement all four general use AF classes. Packets in one AF class MUST be forwarded independently from packets in another AF class, i.e., a DS node MUST NOT aggregate two or more AF classes together.

A DS node MUST allocate a configurable, minimum amount of forwarding resources (buffer space and bandwidth) to each implemented AF class. Each class SHOULD be serviced in a manner to achieve the configured service rate (bandwidth) over both small and large time scales.

An AF class MAY also be configurable to receive more forwarding resources than the minimum when excess resources are available either from other AF classes or from other PHB groups. This memo does not specify how the excess resources should be allocated, but implementations MUST specify what algorithms are actually supported and how they can be parameterized.

Here authors begin to refine the PHB Group specification. We can have up to N classes and up to M levels of drop precedence within each class. Initially four classes and three level of drop precedence are defined for general use. However, more AF classes and levels of drop precedence can be defined for local use. Each node should implement all four AF classes and for each class a minimum amount of forwarding resources has to be allocated. These resources are the minimum guaranteed to each class but when more resources are available they have to be shared between the AF classes being implemented.

It is also very important to note how the different subclasses are named; an IP packet that belong to an AF class i having drop precedence j is marked with the AF codepoint AFij. Having four classes and three drop precedences the twelve subclasses would be named: AF11..AF13; AF21..AF23; AF31..AF33; and AF41..AF43.

Within an AF class, a DS node MUST NOT forward an IP packet with smaller probability if it contains a drop precedence value p than if it contains a drop precedence value q when p < q. Note that this requirement can be fulfilled without needing to dequeue and discard already-queued packets.

Within each AF class, a DS node MUST accept all three drop precedence codepoints and they MUST yield at least two different levels of loss probability. In some networks, particularly in enterprise networks, where transient congestion is a rare and brief occurrence, it may be reasonable for a DS node to implement only two different levels of loss probability per AF class. While this may suffice for some networks, three different levels of loss probability SHOULD be supported in DS domains where congestion is a common occurrence.

If a DS node only implements two different levels of loss probability for an AF class x, the codepoint AFx1 MUST yield the lower loss probability and the codepoints AFx2 and AFx3 MUST yield the higher loss probability.

A DS node MUST NOT reorder AF packets of the same microflow when they belong to the same AF class regardless of their drop precedence. There are no quantifiable timing requirements (delay or delay variation) associated with the forwarding of AF packets.

The probability of any packet to be forwarded is higher as its drop precedence is lower; in any circumstances when a packet need to be dropped those of them having higher drop precedence will have also the higher probability to be selected for dropping. A DS node must accept packets with all three drop precedence codepoint and must implement at least two level of loss probability when transient congestion is rare, and all three levels of loss probability when congestion is a common occurrence. In those cases where only two levels of loss probability are implemented, packets belonging to classes having codepoint AFx1 will be subjugated to the lower loss probability, and those belonging to classes having codepoint AFx2 and AFx3 will be subjugated to the higher loss probability.

Observe also that the definition of Assure Forwarding PHB Group does not establish any quantifiable requirement to the delay or delay variation (jitter) that a packet could be suffering during the forwarding process.

A DS domain MAY at the edge of a domain control the amount of AF traffic that enters or exits the domain at various levels of drop precedence. Such traffic conditioning actions MAY include traffic shaping, discarding of packets, increasing or decreasing the drop precedence of packets, and reassigning of packets to other AF classes. However, the traffic conditioning actions MUST NOT cause reordering of packets of the same microflow.

Okay. Nothing really new. Observe, however, that remarking allow to change the class or subclass assigned to a packet. Conditioning must respect the packet ordering of the same microflow.

An AF implementation MUST attempt to minimize long-term congestion within each class, while allowing short-term congestion resulting from bursts. This requires an active queue management algorithm. An example of such an algorithm is Random Early Drop (RED) [Floyd]. This memo does not specify the use of a particular algorithm, but does require that several properties hold.

An AF implementation MUST detect and respond to long-term congestion within each class by dropping packets, while handling short-term congestion (packet bursts) by queueing packets. This implies the presence of a smoothing or filtering function that monitors the instantaneous congestion level and computes a smoothed congestion level. The dropping algorithm uses this smoothed congestion level to determine when packets should be discarded.

The dropping algorithm MUST be insensitive to the short-term traffic characteristics of the microflows using an AF class. That is, flows with different short-term burst shapes but identical longer-term packet rates should have packets discarded with essentially equal probability. One way to achieve this is to use randomness within the dropping function.

The dropping algorithm MUST treat all packets within a single class and precedence level identically. This implies that for any given smoothed congestion level, the discard rate of a particular microflow's packets within a single precedence level will be proportional to that flow's percentage of the total amount of traffic passing through that precedence level.

The congestion indication feedback to the end nodes, and thus the level of packet discard at each drop precedence in relation to congestion, MUST be gradual rather than abrupt, to allow the overall system to reach a stable operating point. One way to do this (RED) uses two (configurable) smoothed congestion level thresholds. When the smoothed congestion level is below the first threshold, no packets of the relevant precedence are discarded. When the smoothed congestion level is between the first and the second threshold, packets are discarded with linearly increasing probability, ranging from zero to a configurable value reached just prior to the second threshold. When the smoothed congestion level is above the second threshold, packets of the relevant precedence are discarded with 100% probability.

I took all this part of the specification in a block because they are shouting here that you have to use RED queuing discipline to implement Assure Forwarding PHB Group. The specification calls for not specifying the use of a particular algorithm, but what they are really specifying here is not more than the RED queuing discipline behavior. RED gateways were studied by various authors but finally, in 1993, Floyd and Jacobson presented a very complete study in their paper "Random Early Detection Gateways for Congestion Avoidance" [13]. Later below, when studying tools for implementing Differentiated Service, we are going to talk a little long about RED queuing discipline. Because of this we will postpone additional comments to a better ocassion.

Recommended codepoints for the four general use AF classes are given below. These codepoints do not overlap with any other general use PHB groups.

The RECOMMENDED values of the AF codepoints are as follows:

AF11 = '001010', AF12 = '001100', AF13 = '001110',
AF21 = '010010', AF22 = '010100', AF23 = '010110',
AF31 = '011010', AF32 = '011100', AF33 = '011110',
AF41 = '100010', AF42 = '100100', AF43 = '100110'.

The table below summarizes the recommended AF codepoint values.

Finally we have the recommended values of the AF codepoints. Four classes and three subclasses (drop precedence) for each of them. But let's stop a little here to have a look to codepoints. They are six bits long as RFC 2474 specification calls. Remember also that the class should be defined using the 3-leftmost bits. Taking these we have a simple way to remember the class part of the codepoints:

001 = 1 = class 1
010 = 2 = class 2
011 = 3 = class 3
100 = 4 = class 4

Next let's do something similar with the 3-rightmost bits that are used to specify the drop precedence or subclass:

010 = 2 = low drop precedence
100 = 4 = medium drop precedence
110 = 6 = high drop precedence

Okay. The rule is very simple. Classes are defined with the first 3-bits and they are just 1-2-3-4. Subclasses are defined with the last 3-bits and they are just 2-4-6.

You must be thinking why I'm bother you with all this explanation about classes, subclasses and bits. However, when trying to implement differentiated services it is absolutely necessary to have a clear understanding of how to compose the codepoint of a class. For example, how to compose the codepoint of class AF32?

Very easy. The class is 3 then the 3-leftmost bits are 011. The drop precedence is 2 (medium); because low-medium-high correspond to 2-4-6, medium drop precedence is 4, then the 3-rightmost bits are 100. Then AF32 is 011100. Try now yourself to find the codepoint for class AF43 as an exercise. Next check above with values taken directly from the specification.

To end the theme about codepoint you may be asking: numbering classes as 1-2-3-4 is really nice, but, why are drop precedence identified by 2-4-6 instead of 1-2-3? Reason is that they are trying to preserve the rightmost bit (bit number six) to indicate another condition. Do you remember what we talked before about in-profile and out-of-profile traffic? Let's refresh what we studied. A flow is entering our domain but we have established what is called a threshold for this kind of traffic. A throughput up to 1.5 Mbps (just as an example) is considered as in-profile traffic because our TCA calls for fullfil this condition. Above this level (our threshold) the traffic is considered out-of-profile traffic. Well, having an absolute independence of the final class where this traffic is going to be located (class 1, 2, 3 or 4), or even the drop precedence (subclass 2, 4 or 6), we can extend even more our already two level hierarchy, marking out-of-profile packets by setting the rightmost bit of the DS-codepoint. Let's suppose that packets belonging to this traffic are going to be assigned to class AF23. What the codepoints are going to be?

For in-profile traffic the codepoint will be 010110 (have a look to the table above or even better use your aid rule to get the code). For out-of-profile traffic we simply set the rightmost bit. Then codepoint for these packets will be 010111. Really nice!!.

Let's step ahead a little more. Let's imagine how to create a PHB for these packets. Again, as an example, we could say: traffic whose packets belong to this class (class 2), are going to be reserved 12% of the available resources at our router; being its drop precedence high (subclass 3), they are going to be subjugated to a drop probability of 4% (for every 100 packets 4 of them, in case of congestion, are probably killed). Up to a throughput of 1.5 Mbps these packets are considered in-profile and treated as was indicated (12% of share - 4% of drop probability). Above this rate traffic is considered out-of-profile and we can change our treatment. How? Well, as you decide; it's a matter of the domain manager responsibility (and the agreements, of course). You could decide or have a deal that out-of-profile traffic is simply not admitted and discarded before entering. Or perhaps a somewhat less strict policy, for example, they could be accepted but being subjugated to a drop policy of 100% in case of congestion.

Have a look to this table:

This is just an example from my exhausted mind. Do you catch the endless possibilities? The DS architecture allows you a broad room of conditioning for packet forwarding. It's really a very flexible and powerful technology requiring only, as we are going to see later, limited resources to be implemented. Continuing with RFC 2597 we have:

The AF codepoint mappings recommended above do not interfere with the local use spaces nor the Class Selector codepoints recommended in [Nichols]. The PHBs selected by those Class Selector codepoints may thus coexist with the AF PHB group and retain the forwarding behavior and relationships that was defined for them. In particular, the Default PHB codepoint of '000000' may remain to be used for conventional best effort traffic. Similarly, the codepoints '11x000' may remain to be used for network control traffic.

It's just a matter to respect our similar. We must coexist with some other technologies. The Default PHB codepoint of '000000', where we do not touch the packet header, should remain being used as an indicator of best effort traffic; the PHB that everybody know and use just now.

And finally, to finish with RFC 2597, let's copy here an example taken from the Appendix's specification. I'm not going to make comments about it. Reach yourself your own conclusions. Next we are going to study "Expedited Forwarding PHB" outlined in RFC 2598 specification.

The AF PHB group could be used to implement, for example, the so-called Olympic service, which consists of three service classes: bronze, silver, and gold. Packets are assigned to these three classes so that packets in the gold class experience lighter load (and thus have greater probability for timely forwarding) than packets assigned to the silver class. Same kind of relationship exists between the silver class and the bronze class. If desired, packets within each class may be further separated by giving them either low, medium, or high drop precedence.

The bronze, silver, and gold service classes could in the network be mapped to the AF classes 1, 2, and 3. Similarly, low, medium, and high drop precedence may be mapped to AF drop precedence levels 1, 2, or 3.

The drop precedence level of a packet could be assigned, for example, by using a leaky bucket traffic policer, which has as its parameters a rate and a size, which is the sum of two burst values: a committed burst size and an excess burst size. A packet is assigned low drop precedence if the number of tokens in the bucket is greater than the excess burst size, medium drop precedence if the number of tokens in the bucket is greater than zero, but at most the excess burst size, and high drop precedence if the bucket is empty. It may also be necessary to set an upper limit to the amount of high drop precedence traffic from a customer DS domain in order to avoid the situation where an avalanche of undeliverable high drop precedence packets from one customer DS domain can deny service to possibly deliverable high drop precedence packets from other domains.

Another way to assign the drop precedence level of a packet could be to limit the user traffic of an Olympic service class to a given peak rate and distribute it evenly across each level of drop precedence. This would yield a proportional bandwidth service, which equally apportions available capacity during times of congestion under the assumption that customers with high bandwidth microflows have subscribed to higher peak rates than customers with low bandwidth microflows.

The AF PHB group could also be used to implement a loss and low latency service using an over provisioned AF class, if the maximum arrival rate to that class is known a priori in each DS node. Specification of the required admission control services, however, is beyond the scope of this document. If low loss is not an objective, a low latency service could be implemented without over provisioning by setting a low maximum limit to the buffer space available for an AF class.

Previous

Content

Next