Per-Hop Behaviors 53
Figure 2-3 illustrates the ToS byte with IP precedence and the redefined ToS byte with
DiffServ:
Figure 2-3 ToS Byte: With IP Precedence and Differentiated Services
Per-Hop Behaviors
With the introduction of the DSCP markings, there were significantly more possible
markings for packets (0–63 are the possible markings for packets). Because there were so
many more possible markings, the IETF decided to standardize what some of the
codepoints meant. In part, this is to provide backward compatibility to IP precedence and,
in part, this is to facilitate certain types of behaviors that were seen as fundamental to the
DiffServ architecture.
The following definition of a per-hop behavior is taken from Section 2.4 of RFC 2475:
A per-hop behavior (PHB) is a description of the externally observable forwarding behavior of a DS node
applied to a particular DS behavior aggregate … In general, the observable behavior of a PHB may depend
on certain constraints on the traffic characteristics of the associated behavior aggregate, or the
characteristics of other behavior aggregates.
For a definition of forwarding behavior, refer to Chapter 1.
For the purpose of backward compatibility, it is important to note that a router that under-
stands IP precedence, but is not DiffServ-aware, looks only at the 3 most significant bits
(left-most bits) in the ToS field, whereas a DiffServ-capable router looks at the 6 most
significant bits. Therefore, the marking 000000 is defined in RFC 2474 as Best Effort. This
means that a router that only understands IP precedence would read that field as 000, which
is the definition of Best Effort in an IP precedence environment. Similarly, all markings in
the format xxx000 are reserved by RFC 2474 to provide backward compatibility with IP
precedence values, as shown in Table 2-6.
Table 2-6 Backward Compatibility with IP Precedence Values
Bits Precedence
001000 Class selector 1; read as 001 by a non-DiffServ node and treated like IP precedence 1.
010000 Class selector 2; read as 010 by a non-DiffServ node and treated like IP precedence 2.
011000 Class selector 3; read as 011 by a non-DiffServ node and treated like IP precedence 3.
100000 Class selector 4; read as 100 by a non-DiffServ node and treated like IP precedence 4.
IP Precedence "ToS bits" U
DSCP ECN
IPv4 ToS
DS Field
continues
54 Chapter 2: End-to-End QoS: Quality of Service at Layer 3 and Layer 2
These backward-compatible markings were necessary to not break networks while the
conversion from IP precedence to DiffServ was taking place.
RFC 2597: The Assured Forwarding PHB
Other than those defined in RFC 2474, there are two main PHBs, RFC 2597 defines the first
of these. It is called the assured forwarding (AF) PHB, and the concept behind the PHB is
to provide a level of assurance as to a given packet’s probability of being forwarded during
congestion.
RFC 2597 defines four classes, and each class is completely independent of the other
classes. In addition, each class has three level of “drop precedence” to which packets of that
class can be assigned.
From a high level, the concept is that you can have four different classes of traffic and,
within those classes, you can have three different levels of probability that a packet will be
dropped if that class becomes congested. Table 2-7 shows the code point markings for the
AF PHB and the decimal values associated with each.
To understand a possible use for the AF PHB, assume that you have four branch offices
aggregating into a single router. Each branch has been told that they should not send more
Bits Precedence
101000 Class selector 5; read as 101 by a non-DiffServ node and treated like IP precedence 5.
110000 Class selector 6; read as 110 by a non-DiffServ node and treated like IP precedence 6.
111000 Class selector 1; read as 111 by a non-DiffServ node and treated like IP precedence 7.
Table 2-7 Codepoint Markings for the AF PHB
Drop Precedence Class 1 Class 2 Class 3 Class 4
Low AF11
(001010)
10
AF21
(010010)
18
AF31
(011010)
26
AF41
(100010)
34
Medium AF12
(001100)
12
AF22
(010100)
20
AF32
(011100)
28
AF42
(100100)
36
High AF13
(001110)
14
AF23
(010110)
22
AF33
(011110)
30
AF43
(100110)
38
Table 2-6 Backward Compatibility with IP Precedence Values (Continued)
Per-Hop Behaviors 55
than 256 kbps of FTP traffic, but sometimes they do anyway. In fact, sometimes they send
more than 1 Mbps of FTP traffic. The problem is that when one branch sends a lot of FTP
traffic, it sometimes interferes with another branch’s FTP traffic, even if they are sending at
or below the 256-kbps limit. A possible solution for this problem can be found by using the
AF PHB, as illustrated in Figure 2-4.
Figure 2-4 An Example of the AF PHB
In Cisco devices, this PHB is implemented on egress interfaces using a combination of
CBWFQ and DSCP-based class-based WRED. Each site has contracted for 256 kbps of
FTP traffic, so the bandwidth statement reflects a minimum reservation of 1024 kbps. The
entire configuration of the egress interface seen in Figure 2-4 would be entered as shown in
Example 2-4.
Each ingress interface has a
policer, which checks the rate of
inbound FTP traffic.
If the rate is 256 kbps or less, the
packets are marked AF11.
If the rate is between 256 kbps and
1 Mbps, the packets exceeding
256 kbps are maked AF12.
If the rate is above 1 Mbps, the
packets exceeding 1 Mbps are
marked AF13.
In Class AF1, on the egress
interface, DSCP-based
Weighted RED is enabled.
WRED will drop packets in
this class, as needed, based
on their DSCP marking.
AF13 packets will be
dropped first, the AF12
packets and AF11
packets will only be dropped
as a last resort.
56 Chapter 2: End-to-End QoS: Quality of Service at Layer 3 and Layer 2
The running-config for this would then appear as in Example 2-5.
When attached to an interface, the functionality of this policy can be verified with the show
policy-map interface command.
RFC 2598: The Expedited Forwarding PHB
The expedited forwarding (EF) PHB is designed to build a low-loss, low-latency, and low-
jitter, assured bandwidth class. If all of those characteristics sound a bit like how you would
want to treat VoIP traffic, you are already well on your way to understanding the purpose
of this PHB.
Although RFC 2598 does not specifically say that this PHB should be used only for voice,
this is the likely service for which this PHB would be used. Other types of interactive traffic
could no doubt benefit from this type of treatment, however.
The idea behind the EF PHB is that traffic of this class should be forwarded with strict
priority, as soon as that traffic is received. Note that the EF PHB should not normally be
used for TCP traffic, due to the bursty nature of TCP. The reason behind this recommen-
Example 2-4 Configuring CBWFQ and Class-based WRED
Router(config)#class-map match-any FTP
Router(config-cmap)#match ip dscp af11
Router(config-cmap)#match ip dscp af12
Router(config-cmap)#match ip dscp af13
Router(config-cmap)#exit
Router(config)#policy-map AF-PHB
Router(config-pmap)#class FTP
Router(config-pmap-c)#bandwidth 1024
Router(config-pmap-c)#random-detect dscp-based
Router(config-pmap-c)#exit
Router(config-pmap)#exit
Router(config)#exit
Router#
Example 2-5 Verifying the Configuration of CBWFQ and Class-based WRED
!
class-map match-any FTP
match ip dscp af11
match ip dscp af12
match ip dscp af13
!
!
policy-map AF-PHB
class FTP
bandwidth 1024
random-detect dscp-based
Per-Hop Behaviors 57
dation is that the EF PHB, in order not to starve other traffic classes of bandwidth, imple-
ments a policing function. This policing function ensure that the EF class receives all the
bandwidth to which it is entitled, but is limited in the total amount of bandwidth that it can
consume.
The EF PHB is implemented in Cisco devices as LLQ. Note that prior to Cisco IOS version
12.2, the policing function was implemented differently for different media types and, in
some cases, the policing function happened regardless of congestion. In newer versions of
Cisco IOS, however, this inconsistency has been resolved and the policing function of the
LLQ only happens in the event of congestion on the interface.
If added to the configuration already shown for the AF PHB, the configuration for the EF
PHB would be as shown in Example 2-6.
Notice that, in this example, the policy map is still named AF-PHB. Because this name was
already being used for the interface, the EF configuration was just added to this policy. Of
course, the name of the policy doesn’t really matter.
The running-config for the entire policy would now appear as shown in Example 2-7.
Example 2-6 Configuring LLQ (EF PHB)
Router(config)#class-map VOICE
Router(config-cmap)#match ip dscp ef
Router(config-cmap)#exit
Router(config)#policy-map AF-PHB
Router(config-pmap)#class VOICE
Router(config-pmap-c)#priority 56
Router(config-pmap-c)#exit
Router(config-pmap)#exit
Router(config)#exit
Router#
Example 2-7 Verifying the Configuration of LLQ and WRED
class-map match-any FTP
match ip dscp af11
match ip dscp af12
match ip dscp af13
class-map match-all VOICE
match ip dscp ef
!
!
policy-map AF-PHB
class FTP
bandwidth 1024
random-detect dscp-based
class VOICE
priority 56
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.