Differentiated Services: A Standards Approach 25
RFC 2597, “Assured Forwarding PHB Group”
In part, the Abstract of RFC 2597 states the following:
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.
Until now, this text has only discussed single PHBs, so new terminology needs to be
clarified before discussing AF in detail. The original RFC (2597) calls AF, as a whole, a
PHB group. RFC 3260 later clarifies this definition and states that AF is actually a type of
PHB group, which actually contains four separate PHB groups.
If you understand the implications of that correction, great! If you’re scratching your head
at the moment, don’t despair. Before you finish reading this section, you’ll understand the
distinction and its importance.
RFC 2597 defines 12 DSCPs, which correspond to 4 AF classes, each class having 3 levels
of “drop precedence.” Visualize four totally separate buckets, each having three compart-
ments, and you have the general idea. Each AF class (referred to as AF1x, AF2x, AF3x, and
AF4x) is completely independent of the other classes. Within each class, however, there are
three levels of drop precedence (for example, AF1x contains AF11, AF12, and AF13).
These drop precedence levels, within each class, have relativity to the other drop prece-
dence values in their class, but no relativity at all to the other classes. Note that the first
number is always the AF class to which the packets belong, and the second number is
always the packet’s drop precedence value. For clarification, there is no such thing as AF10
or AF14; there are only three levels of drop precedence per AF class.
Stated more directly, each AF class is totally independent of the other three and no assump-
tions can be made regarding the treatment of packets belonging to one class when compared
with the treatment of packets belonging to another class. Within a class, however, assumptions
may be made regarding the treatment of packets with different drop precedence values.
All the classes and their drop precedence values are represented by the DSCP markings that
are given to packets. Table 1-2 lists the 12 recommended codepoints defined by RFC.
Table 1-2 Codepoints Recommended by RFC 2597
Class
Low Drop
Precedence
Medium Drop
Precedence
High Drop
Precedence
AF1 001010 (AF11) 001100 (AF12) 001110 (AF13)
AF2 010010 (AF21) 010100 (AF22) 010110 (AF23)
AF3 011010 (AF31) 011100 (AF32) 011110 (AF33)
AF4 100010 (AF41) 100100 (AF42) 100110 (AF43)
26 Chapter 1: Quality of Service: An Overview
RFC 2597 dictates that packets with a low drop preference must be dropped with a proba-
bility less than or equal to the probability with which medium drop precedence packets
would be dropped and that packets with a medium drop precedence must be dropped with
a probability less than or equal to the probability with which high drop precedence packets
would be dropped. The “or equal to” part allows for the equal treatment of all packets
within an AF class but, assuming that the drop precedence is going to be used to treat
packets differently, high drop precedence packets are going to be dropped first in an AF
class. Again, there can be no assumptions made about the probability of a packet from AF1x
being dropped, with respect to the probability of a packet from AF2x being dropped.
Recall, from the beginning of this section, the seemingly pointless clarification of the AF
PHB standard as one that defines multiple PHB groups, rather than one large PHB group?
The reason that distinction is so critical is that a PHB group has components that are
somehow relative to each other. With the redefinition of the AF standard as one that defines
four distinct PHB groups, the point is now very clear that AF1x is a PHB group by itself
and is, therefore, totally separate from the other AF classes. This total separation makes
sure that everyone implementing the AF standard knows that absolutely no relativity exists
between the drop probabilities of packets in different AF classes.
RFC 2597 and RFC 2598: Practical Application in a Cisco Network
All the RFCs in the world don’t do anyone any good until they are actually implemented in
a network, so it seems prudent to look at the Cisco implementation of these two RFCs.
Cisco routers provide EF or AF treatment to implement these RFCs. Later chapters detail the
implementation specifics on the various Catalyst platforms, but it’s important to first under-
stand these RFCs as they are implemented on Cisco routers so that you can use the Catalyst
information provided later to develop an end-to-end QoS strategy for your network.
EF Treatment
First, the EF PHB recommends DSCP 46 (101110) be used to mark packets that should
received EF treatment. The mechanism for performing this marking is beyond the scope of
RFC 2598, but many mechanisms can be used to perform this task, as the list that follows
demonstrates:
• CAR
• Policy-based routing
• Dial peers
• Class-based marking
• Class-based policer
In almost every case, class-based marking and class-based policer are the recommended
methods for performing packet marking in Cisco routers.
Differentiated Services: A Standards Approach 27
The mechanism in Cisco routers that actually provides the EF treatment to packets is called
Low Latency Queuing (LLQ). A lengthy discussion of LLQ’s operation is beyond the scope
of this text, but the basic configuration defines a rate of departure for packets classified into
the LLQ for EF treatment. This definition of the rate of departure activates a policer for the
rate of arrival for packets into the LLQ. As such, a definition of 128 kbps of bandwidth with
LLQ treatment means that, if 129 kbps of traffic is marked for EF, and offered to the LLQ,
1 kbps will be dropped. LLQ extends the CBWFQ model by introducing a single, strict
priority queue.
AF Treatment
With regard to the same packet marking tools previously discussed, 12 codepoints are
recommended for use with AF. These 12 codepoints, listed earlier in the chapter, are divided
into 4 classes, each with 3 codepoints.
Figure 1-8 shows a possible implementation of AF.
Figure 1-8 Possible Implementation of Assured Forwarding
In this example
• A class called Customer-A will get AF11, AF12, and AF13 traffic.
• A class called Customer-B will get AF21, AF22, and AF23 traffic.
• A class called Customer-C will get AF31, AF32, and AF33 traffic.
Classes with DSCP-
Based WRED
Created on This
Interface
Connection to
Other Regions
Ingress Policer on
Each Customer's
Connection
Provider Regional
Aggregation
Customer D Customer A
Customer BCustomer C
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.