20 Chapter 1: Quality of Service: An Overview
Traffic Conditioning
Traffic conditioning contains two major components:
• Policers—Policers perform traffic policing, which means dropping packets that
exceed a defined rate to control the rate at which traffic passes through the policer.
Examples of policers implemented by Cisco are the committed access rate (CAR)
policer and the class-based policer. The goal of policing is to rate limit traffic; an
example of a practical application for a policer is to limit the amount of FTP traffic
allowed to go out of a given interface to 1 Mbps. Traffic that exceeds this 1-Mbps rate
limit is dropped. TCP retransmits dropped packets, UDP does not, which is a
consideration when deciding whether a policer is right for a given situation.
• Shapers—Shapers perform traffic shaping, which, in Cisco equipment, takes many
forms; generic traffic shaping (GTS), Frame Relay Traffic shaping (FRTS), class-
based traffic shaping, and so on. The specific shaper that is used is not of consequence,
because the concept is the same for all of them. The goal of the shaper is to limit the
rate at which packets pass through the shaper by buffering packets that exceed a
defined rate and sending those packets later. The goal is that, over time, the rate of
transmission will be smoothed out to the defined rate. This is in contrast to the
operation of a policer, where traffic is dropped if the defined rate is exceeded. Both
policers and shapers have benefits and drawbacks, and each situation must be
evaluated to determine which mechanism is best. For example, FTP traffic (which is
TCP based and very tolerant of packet drops) can be policed without negatively
impacting the usability of the application. Because FTP doesn’t mind some delay in
the transmission of its packets, in many cases FTP can also be shaped without any
negative impact to the application. VoIP traffic, on the other hand, does not tolerate
delay very well at all, so it is desirable to drop (police) a VoIP packet rather than delay
(shape) it.
Differentiated Services: A Standards Approach
As you have just seen, many components comprise the DiffServ architecture, and those
components can be used in many different ways. Of course, there are also different imple-
mentations of these mechanisms, which have been given different names by different
vendors. The key to the DiffServ architecture’s successful implementation in a multivendor
environment, however, is that the entire architecture is standards-based. Regardless of what
name each vendor uses to market a given feature, all the features that comprise the DiffServ
architecture are standardized and should, therefore, interoperate between vendors with very
predictable results. The idea of being able to provide predictable service to packets through
the network is fundamental to being able to provide good QoS. This is especially critical
when dealing with real-time interactive traffic, such as VoIP, but is also important for
consistent data handling across multiple network nodes.
Differentiated Services: A Standards Approach 21
RFC 2475: Terminology and Concepts
The treatment given to a packet at each of these nodes, or hops, is called a per-hop behavior
(PHB). PHBs are defined by RFC 2475 as “the externally observable forwarding behavior
applied at a DS-compliant node to a DS behavior aggregate.” For clarification, RFC 2475
also defines a DS behavior aggregate (or BA, which isn’t nearly as complicated as it
sounds) as, “a collection of packets with the same DS codepoint crossing a link in a
particular direction.” This concept was introduced earlier in this chapter, but RFC 2475
basically says that all packets with the same DSCP marking must be treated the same when
passing through a given interface, in a given direction. It is possible to define a BA based
on multiple criteria. Although not explicitly defined in the terminology of RFC 2475, the
permissibility of such a BA definition can be inferred from the definition of the multifield
(MF) classifier, “which selects packets based on the content of some arbitrary number of
header fields; typically some combination of source address, destination address, DS field,
protocol ID, source port and destination port.” In other words, it is possible to group packets
together, to receive a PHB, based on criteria other than the DSCP marking of those packets.
The question that naturally follows the definitions given by RFC 2475 is “what is a
’forwarding behavior?’” RFC 2475 states the following:
“Forwarding behavior” is a general concept in this context. For example, in the event that only one behavior
aggregate occupies a link, the observable forwarding behavior (i.e., loss, delay, jitter) will often depend only
on the relative loading of the link (i.e., in the event that the behavior assumes a work-conserving scheduling
discipline). Useful behavioral distinctions are mainly observed when multiple behavior aggregates compete
for buffer and bandwidth resources on a node. The PHB is the means by which a node allocates resources
to behavior aggregates, and it is on top of this basic hop-by-hop resource allocation mechanism that useful
differentiated services may be constructed.
Simply stated, it’s something that you can distinctly measure (that is, bandwidth, delay,
jitter, loss), and observing different forwarding behaviors is typically only possible when
multiple traffic types compete for resources on a congested link. Further, this basic ability
to provide different resource allocations to behavior aggregates on a hop-by-hop basis is the
foundation for DiffServ.
RFC 2475 also gives a great example:
The most simple example of a PHB is one which guarantees a minimal bandwidth allocation of X% of a
link (over some reasonable time interval) to a behavior aggregate. This PHB can be fairly easily measured
under a variety of competing traffic conditions. A slightly more complex PHB would guarantee a minimal
bandwidth allocation of X% of a link, with proportional fair sharing of any excess link capacity.
RFC 2474: Terminology and Concepts
As previously discussed, traffic can be grouped into behavior aggregates only by DSCP, or
based on multiple fields (for example, DSCP and source IP address). As you read this
section, keep in mind that the DiffServ RFCs focus mainly on the classification by DS
behavior aggregate.
22 Chapter 1: Quality of Service: An Overview
RFC 2475 states the following:
Nodes within the DS domain select the forwarding behavior for packets based on their DS codepoint,
mapping that value to one of the supported PHBs using either the recommended codepoint PHB
mapping or a locally customized mapping [DSFIELD].
In more basic terms, a networking device decides which PHB to give a packet based on the
DSCP value assigned to the packet. This value can either be one that is mapped to a PHB
as defined by an RFC, or it can be a marking that is not standardized but has local signifi-
cance. For example, DSCP value 26 (decimal) is mapped to a standardized PHB (called
AF31, which is discussed later in this chapter), but DSCP value 27 (decimal) is not mapped
to any standardized PHB. Therefore, when a network device receives packets marked with
DSCP 26, certain assumptions can be made about the expected forwarding behavior. On the
other hand, no assumptions can be made about the expected forwarding behavior for
packets marked with DSCP 27, because that codepoint has no standardized PHB.
Because codepoint markings are very important in the DiffServ architecture, it seems
prudent to discuss the origins of the DSCP values: RFC 2474. RFC 2474 obsoletes RFC
791, which defined the IPv4 type of service (ToS) octet, more commonly discussed as IP
precedence. The Abstract section of RFC 2474 states the purpose of the document:
This document defines the IP header field, called the DS (for differentiated services) field. In IPv4, it defines
the layout of the TOS octet; in IPv6, the Traffic Class octet. In addition, a base set of packet forwarding
treatments, or per-hop behaviors, is defined.
Figure 1-7 shows the DS field format.
Figure 1-7 DS Field Format
IPv4 ToS
DS Field
IP Precedence
"ToS bits"
U
DSCP ECN
Differentiated Services: A Standards Approach 23
The addition of explicit congestion notification (ECN) to IP (RFC 2481) has since redefined
bits 6 and 7 for use; however, a discussion of ECN is beyond the scope of this text.
RFC 2474 goes on to require that codepoint-to-PHB mappings must be configurable and
that the default configuration should include recommended codepoint-to-PHB mappings.
The exception to the requirement that codepoint-to-PHB mappings be configurable is for
codepoints xxx000, because these codepoints, called class selector codepoints, are reserved
for backward compatibility with IP precedence. The specifics of this backward compati-
bility are beyond the scope of this text, but the concept is that when bits 3, 4, and 5 of this
byte are set to 0, and any of the first 3 bits of the byte (which were previously used for IP
precedence) are not 0, the packet is handled as if it is marked with IP precedence. In other
words, 001000 and 010000 are treated as if they are IP precedence 1 and IP precedence 2,
respectively. No attempt is made in RFC 2474 to maintain any backward compatibility with
bits 3 through 6 or 7 (previously used as the ToS bits and the must be zero [MBZ] bit,
respectively).
Note as well that RFC 2474 documents the use of the codepoint 000000, which is the
codepoint for BE treatment. BE is the treatment that packets get when no QoS is enabled
in a network, and essentially means that the networking devices make every effort possible
to get the packet to the destination, but ultimately there are absolutely no guarantees with
regard to delay, jitter, packet loss, or bandwidth. In fact, there is no guarantee that the packet
will even be transmitted. For example, a router might have three classes of traffic, each
guaranteed 1/3 of the total link bandwidth. If all three classes are sending traffic equal to 1/3
of the total link bandwidth, the link is going to be totally congested. In a situation like this,
BE traffic, which by definition is not classified into one of these three classes, has either
very limited resources or none at all (depending on the implementation specifics). This
situation could lead to significant delay and, ultimately, packet loss.
Assured Forwarding Versus Expedited Forwarding
Assured forwarding (AF, RFC 2597), and expedited forwarding (EF, RFC 2598) are PHBs
that have recommended codepoints. EF has only 1 recommended codepoint, whereas AF
has 12 recommended codepoints.
RFCs 2597 and 2598 both describe PHBs; beyond that, they are not specifically related, but
the discussion of each has been combined in this section to contrast the two functions. The
point of contrasting these two PHBs is to demonstrate how the DiffServ architecture allows
for a great deal of flexibility in the PHBs that fall under the DiffServ umbrella. No relation
or interdependency exists between AF and EF, but because the EF PHB is the easier of the
two to understand, it is covered first.
24 Chapter 1: Quality of Service: An Overview
RFC 2598, “An Expedited Forwarding PHB”
RFC 2598 defines “An Expedited Forwarding PHB” and states the following:
The EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end service
through DS domains.
This means that when a network node receives a packet, it should be transmitted as soon as
possible (adding as little delay as possible). This sounds a lot like voice service, right?
Although RFC 2598 doesn’t explicitly discuss the intended use of this PHB, it can probably
be safely assumed that the primary intention for this PHB is real-time traffic, including voice
and, in some cases, interactive video. That’s not, of course, to say that this PHB isn’t ever used
for any other kind of traffic. I suppose that’s one of the great things about the DiffServ archi-
tecture implementation in Cisco equipment; it is very flexible and entirely user configurable.
When I teach QoS classes, my joke is that Cisco enables users to configure QoS any way they
want to … even if it’s wrong. RFC 2598 is actually one of the few things in the DiffServ archi-
tecture that provides an opportunity to get into real trouble with misconfiguration.
Consider the fact that the EF PHB’s main purpose is to provide a forwarding behavior that
introduces as little delay and jitter as possible. If more traffic is received for transmission
than an interface can transmit, a queue begins to form. When a device queues traffic, by
definition it introduces delay. As such, it can be inferred that building a queue is undesirable
when implementing the EF PHB.
Said another way, if a device queues traffic, it introduces delay; so to provide the EF PHB,
a device should not queue (or queue very little) traffic. Because this requirement means that
the EF traffic will be given strict priority for transmission (to minimize delay), there is a
risk that the receipt of too much EF traffic could cause starvation for other traffic on the link.
One might envision a situation in which there is a steady stream of EF traffic, received at
the line rate of the egress interface, and a stream of other traffic, received at the line rate of
the egress interface. In this situation, without a mechanism to prevent starvation, the strict
priority of the EF traffic on that link means that all the EF traffic is transmitted and none of
the other traffic is transmitted. That may very well be the intent of a particular user, but to prevent
this situation from unintentionally occurring, RFC 2598 calls for a measure of protection.
The measure that is called for to prevent the starvation of other traffic, just because a device
receives too much EF traffic, is the following provision:
The departure rate of the aggregate’s packets from any DiffServ node must equal or exceed a configurable rate.
This behavior can be represented by stating that the rate of arrival must be less than or equal
to the rate of departure, for packets receiving the EF PHB. To ensure that this is the case,
the RFC suggests that a policer be used to rate limit the EF traffic, which is what is used in
most Cisco devices. Specifically, if the configuration requires EF for all packets marked
DSCP 46, and if 128 kbps is the configured egress rate for traffic receiving the EF PHB, and
129 kbps of traffic marked DSCP 46 is offered, 1k of traffic marked DSCP 46 is dropped to
ensure that the rate of arrival into the EF queue does not exceed the rate of departure. This
example, by the way, assumes link congestion is present. When no congestion exists, queuing
does not become active and, therefore, the policing mechanism would also not become active.
Stated another way, when there is no congestion, there is no policing of traffic that would, in
the event of congestion, be placed in the priority queue for strict priority scheduling.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.