This chapter is from the book
This chapter is from the book
This chapter is from the book
QoS Service Models
The two QoS architectures used in IP networks when designing a QoS solution are the IntServ and DiffServ models. The QoS service models differ by two characteristics: how the models enable applications to send data, and the way in which networks attempt to deliver the respective data with a specified level of service.
A third method of service is best-effort service, which is essentially the default behavior of the network device without any QoS. In summary, the following list restates these three basic levels of service for QoS:
Best-effort service—The standard form of connectivity without any guarantees. This type of service, in reference to Catalyst switches, uses first-in, first-out (FIFO) queues, which simply transmit packets as they arrive in a queue with no preferential treatment.
Integrated services—IntServ, also known as hard QoS, is an absolute reservation of services. In other words, the IntServ model implies that traffic flows are reserved explicitly by all intermediate systems and resources.
Differentiated services—DiffServ, also known as soft QoS, is class-based, where some classes of traffic receive preferential handling over other traffic classes. Differentiated services uses statistical preferences, not a hard guarantee like integrated services. In other words, DiffServ categorizes traffic and then sorts it into queues of various efficiencies.
Choosing the type of service to use in a multilayer switched network depends on the following factors:
Application support
Technology upgrade speed and path
Cost
The following two subsections discuss the IntServ and DiffServ architectures in more detail.
Integrated Services Architecture
The IntServ model, defined in RFC 1633, guarantees a predictable behavior of the network for applications. IntServ provides multiple services that accommodate multiple QoS requirements. IntServ is implemented through the use of the Resource Reservation Protocol (RSVP), enabled at both the endpoints and the network devices between. The RSVP-enabled application requests a specific kind of service from the RSVP-enabled network before it sends data. Explicit signaling via RSVP makes the request, and the application informs the network of its traffic profile and requests a particular kind of service that can encompass its bandwidth and delay requirements. The application is expected to send data only after it gets a confirmation from the network. The network also expects the application to send data that lies within its described traffic profile.
The RSVP-enabled network performs admission control based on information from the requesting host application and available network resources. It either admits or rejects the application's request for bandwidth. The network commits to meeting the QoS requirements of the application as long as the specific traffic flow for which the request was made remains within the profile specifications. Each flow of traffic must go through the admission control process.
Using Common Open Policy Service (COPS) centralizes admission control at a Policy Decision Point (PDP). COPS provides the following benefits when used with RSVP:
Centralized management of services
Centralized admission control and authorization of RSVP flows
Increased scalability of RSVP-based QoS solutions
Together, RSVP and IntServ offer the following benefits:
Explicit resource admission control (end to end)
Per-request policy admission control (authorization object, policy object)
Signaling of dynamic port numbers
The drawbacks to using RSVP and IntServ are that they are not scalable and they require continuous signaling because of their soft state architecture.
Differentiated Services
The DiffServ model provides multiple levels of service that satisfy differing QoS requirements. However, unlike with the IntServ model, an application that uses DiffServ does not explicitly signal the network devices before sending data. DiffServ is a QoS implementation technique that is tailored for modern networks and their solutions. DiffServ reassigns bits in the type of service (ToS) field of an IP packet header. DiffServ uses differentiated services code points (DSCPs) as the QoS priority descriptor value and supports 64 levels of classification. RFC 2474 defines the use of the ToS byte for DSCP. Catalyst switches' configurations support IP Precedence and DSCP values.
Figure 10-2 illustrates the bits used in packets for classification. Network devices use either Layer 2 class of service (CoS) bits of a frame or Layer 3 IP Precedence or DSCP bits of a packet for classification. All Catalyst switches listed in Table 10-1 support QoS by Layer 3 classification as well as Layer 2 classification. At Layer 2, 3 bits are available in 802.1Q frames and Inter-Switch Link (ISL) frames for classification for up to eight distinct values (levels of service), 0 through 7. These Layer 2 classification bits are referred to as the CoS values. At Layer 3, QoS uses the 6 most significant ToS bits in the IP header for a DSCP field definition. This DSCP field definition allows for up to 64 distinct values (levels of service), 0 through 63, of classification on IP frames. The last two bits represent the Early Congestion Notification (ECN) bits. IP Precedence is only the 3 most significant bits of the ToS field. As a result, IP Precedence maps to DSCP by using IP Precedence as the 3 high-order bits and padding the lower-order bits with 0.
)
Figure
10-2 DiffServ Packet Classification
A practical example of the interoperation between DSCP and IP Precedence is with Cisco IP Phones. Cisco IP Phones mark voice traffic at Layer 3 with a DSCP value of 46 and, consequently, an IP Precedence of 5. Because the first 3 bits of DSCP value 46 in hexadecimal is 101 (5), the IP Precedence is 5. As a result, a network device that is only aware of IP Precedence understands the packet priority similarly to a network device that is able to interpret DSCP. Moreover, Cisco IP Phones mark frames at Layer 2 with a CoS value of 5.
Figure 10-3 illustrates the ToS byte. P2, P1, and P0 make up IP Precedence. T3, T2, T1, and T0 are the ToS bits. When viewing the ToS byte as DSCP, DS5 through DS0 are the DSCP bits. Table 10-2 illustrates the IP Precedence value to precedence designation mapping. For more information about bits in the IP header that determine classification, refer to RFCs 791, 795, and 1349.
)
Figure
10-3 The DiffServ Field
Table 10-2 IP Precedence Bit Mappings
|
Bits (IP Precedence Value) |
IP Precedence |
|
111 (7) |
Network control |
|
110 (6) |
Internetwork control |
|
101 (5) |
CRITIC/ECP |
|
100 (4) |
Flash override |
|
011 (3) |
Flash |
|
010 (2) |
Immediate |
|
001 (1) |
Priority |
|
000 (0) |
Routine |
The CU bit is not used. Using DSCP values for classification of packets is the leading method for classification in all enterprise and service provider multilayer switched networks.
For a differentiated service, the network tries to deliver a particular kind of service based on the QoS descriptor specified in each IP packet header on a per-hop basis, rather than per-traffic flow as in IntServ. You can use the DiffServ model for the same mission-critical applications as IntServ and to provide end-to-end QoS. Network devices forward each according to priorities designated within the packet on a per-device, per-hop basis. Typically, this DiffServ model is the preferable model within the multilayer switched network because of its scalability.
IntServ must maintain state information for every flow in the network. DiffServ overcomes this limitation by assigning different queuing policies, traffic policing, and drop parameters based on classification of packets in order to differentiate (prefer) traffic flows. In addition, DiffServ uses per-class polices instead of per-flow polices as with IntServ, such that flows can be aggregated into a small number of classes. This makes QoS administration and configuration easier than maintaining policies on a per-flow basis. Another advantage in using DiffServ is the ability to support complex traffic classification and conditioning performed at the network edge. As a result, the recommendation is to apply DiffServ QoS features in every submodule of the Enterprise Composite Network Model.
Assured Forwarding and Expedited Forwarding
RFC 2474 introduced DSCP and 64 possible markings on a single packet. IETF decided to standardize the meanings for several codepoint values into per-hop behaviors (PHBs). Two main PHBs exist:
Assured Forwarding (RFC 2597)
Expedited Forwarding (RFC 2598)
Assured Forwarding
Assured Forwarding (AF) defines classes by using DSCP values. AF is important in understanding how to relate DSCP AF terminology to DSCP values. Example 10-1 illustrates the configuration options for DSCP in Cisco IOS.
Example 10-1 DSCP Configuration in Cisco IOS
Switch(config-pmap-c)#set ip dscp ? <0-63> Differentiated services codepoint value af11 Match packets with AF11 dscp (001010) af12 Match packets with AF12 dscp (001100) af13 Match packets with AF13 dscp (001110) af21 Match packets with AF21 dscp (010010) af22 Match packets with AF22 dscp (010100) af23 Match packets with AF23 dscp (010110) af31 Match packets with AF31 dscp (011010) af32 Match packets with AF32 dscp (011100) af33 Match packets with AF33 dscp (011110) af41 Match packets with AF41 dscp (100010) af42 Match packets with AF42 dscp (100100) af43 Match packets with AF43 dscp (100110) cs1 Match packets with CS1(precedence 1) dscp (001000) cs2 Match packets with CS2(precedence 2) dscp (010000) cs3 Match packets with CS3(precedence 3) dscp (011000) cs4 Match packets with CS4(precedence 4) dscp (100000) cs5 Match packets with CS5(precedence 5) dscp (101000) cs6 Match packets with CS6(precedence 6) dscp (110000) cs7 Match packets with CS7(precedence 7) dscp (111000) default Match packets with default dscp (000000) ef Match packets with EF dscp (101110)
AF has four AF classes, AF1x through AF4x, where the AF4 class is considered to have more importance than the AF1 class. Within each class, there are three drop probabilities. Depending on the policy of a given network, you can configure packets for a PHB based on required throughput, delay, jitter, loss, or according to priority of access to network services.
AF PHB defines a method by which traffic classes are given different forwarding assurances. A practical example of dividing a network into classes is as follows:
Gold: 50 percent of the available bandwidth
Silver: 30 percent of the available bandwidth
Bronze: 20 percent of the available bandwidth
Table 10-3 illustrates the DSCP coding to specify the AF class with the drop probability. Bits 0, 1, and 2 define the class; bits 3 and 4 specify the drop probability; bit 5 is always 0.
Table 10-3 Sample DSCP Coding to Specify AF Class
|
|
Class 1 |
Class 2 |
Class 3 |
Class 4 |
|
Low Drop |
001010 AF11 DSCP 10 |
010010 AF21 DSCP 18 |
011010 AF31 DSCP 26 |
100010 AF41 DSCP 34 |
|
Medium Drop |
001100 AF12 DSCP 12 |
010100 AF22 DSCP 20 |
011100 AF32 DSCP 28 |
100100 AF42 DSCP 36 |
|
High Drop |
001110 AF13 DSCP 14 |
010110 AF23 DSCP 22 |
011110 AF33 DSCP 30 |
100110 AF43 DSCP 38 |
Expedited Forwarding
Expedited Forwarding defines the Expedited Forwarding (EF) PHB. Network devices use EF PHB to build a low-loss, low-latency, low-jitter, assured-bandwidth, end-to-end service through DiffServ domains. EF service appears to the endpoints as a point-to-point connection. An example is to apply EF PHBs to VoIP traffic. The remaining sections of this chapter explain the application of DSCP and DiffServ on Catalyst switches.