Advanced QoS Overview Solutions in this chapter: ■ Using the Resource Reservation Protocol ■ Using Class-Based Weighted Fair Queuing ■ Using Low Latency Queuing ■ Using Weighted Random Early Detection ■ Using Generic Traffic Shaping and Frame Relay Traffic Shaping ■ Running in Distributed Mode ■ Using Link Fragmentation and Interleaving ■ Understanding RTP Header Compression Chapter 8 271 110_QoS_08 2/13/01 11:49 AM Page 271 272 Chapter 8 • Advanced QoS Overview Introduction This chapter outlines some of the more cutting edge QoS mechanisms available at press time. Some of these technologies are just beginning to be widely deployed on production networks, and, though Quality of Service is constantly being improved and modified, these technologies will undoubtedly remain a sig- nificant factor in the Quality of Service marketplace for some time to come. Several of these technologies, such as RSVP and LLQ, are currently being used mostly for voice applications, and you will find that these more advanced mechanisms are often used in conjunction with each other, rather than indepen- dently.These mechanisms, although powerful and useful in their own right, gain power and functionality when used along with other mechanisms. Some of the benefits of more advanced queuing mechanisms are increased granular control of traffic behavior, and the ability to be far more specific when classifying and queuing or dropping traffic. However, this presents a potential problem.There is a trade-off between granular control and flexibility of use. LLQ, for example, is a very specific mechanism with a very specific purpose, but it not well suited for many things other than that purpose. It is particularly important in this chapter to pay attention to recommendations about where the deployment of these technologies is appropriate. Using the Resource Reservation Protocol (RSVP) The Resource Reservation Protocol (RSVP) is the first attempt at an industry standard implementation of the Internet Integrated Services (Intserv) model of QoS. Researchers at the Information Sciences Institute (ISI) at the University of Southern California (USC) and the Xerox Palo Alto Research Center first con- ceived of RSVP. NOTE In 1993, the Internet Engineering Task Force (IETF) started working toward standardization through an RSVP working group. Version 1 of this protocol is currently defined by RFC 2205. Interested readers may find the IETF Applicability Statement (RFC 2208) helpful in pointing out both the uses and current issues with an RSVP deployment. This chapter will illustrate both of these briefly. www.syngress.com 110_QoS_08 2/13/01 11:49 AM Page 272 www.syngress.com The Intserv model is characterized by applications or end stations reserving resources across a network to guarantee a particular level of service. RSVP is a protocol that implements this signaling. RSVP is independent of, yet complimentary to, Intserv.Whereas Intserv spec- ifies the set of classes of service and the parameters to deliver QoS, RSVP requests this service level from network nodes and, in some cases, carries the Intserv parameters. RSVP does not provide QoS directly to applications, but instead, coordinates an overall service level by making reservation requests with as many nodes as pos- sible across the network. It is up to other QoS mechanisms to actually prevent and control congestion, provide efficient use of links, and classify and police traffic. A successful implementation of RSVP requires that it work in conjunction with these other mechanisms. RSVP’s popularity lies in its capacity to give guaranteed QoS to real-time applications that have either constant bandwidth requirements or low latency requirements.This is why its primary use today on networks is to deliver multi- media streams such as voice and video. What Is RSVP? RSVP is a signaling protocol that makes reservations of resources for client appli- cations to guarantee a certain QoS. It is considered a signaling protocol because these reservations are negotiated by communication between end stations. Furthermore, it is an out-of-band signaling protocol. RSVP packets are not used to transmit bulk data; they coexist on the network with other packets and are used to reserve resources for typical IP packets or, more specifically, the IP packets that make up the flows that are to get specialized QoS. RSVP makes reservations of resources for data flows across a network.These reserved flows are usually referred to as sessions. A session is defined as packets having the same destination address (unicast or multicast), IP protocol ID, and destination port. Resources could be considered such things as allocated band- width, CPU cycles, or queuing priority. Clients use RSVP to request a guarantee of QoS across the network. Routers participate in RSVP by allocating resources to particular flows, or denying resources if there are none available, and by for- warding RSVP information to other routers. Advanced QoS Overview • Chapter 8 273 110_QoS_08 2/13/01 11:49 AM Page 273 274 Chapter 8 • Advanced QoS Overview NOTE A signaling protocol can be either in-band or out-of-band, depending on whether the signaling data flows over the same medium as the bulk data. In the telephony world, ISDN would be considered an out-of-band signaling protocol, because all information for setting up a call passes over a separate D- channel (data), whereas the actual telephone conver- sation flows over the Bchannels -(bearer). In a way, RSVP could be con- sidered an in-band signaling protocol, since it flows over the same physical media, the same data-link layer, and even the same network as the bulk data. However, it is usually referred to as out-of-band because the packets are separate from the bulk data. A flow that was set up by RSVP would have nothing in its packets to indicate that it is participating in RSVP. The state of active reservations is stored in each routed node. RSVP is an Internet Control Protocol that resides at Layer 4 of the OSI model, the transport layer. It is similar to other control protocols, such as Internet Control Message Protocol (ICMP) and Internet Group Management Protocol (IGMP). It is fully compliant with Internet Protocol version 4 (IPv4) and the emerging Internet Protocol version 6 (IPv6). It is not a routing protocol.The path that it takes across the network is the same as other IP packets and is deter- mined by the underlying routing protocol (OSPF, EIGRP, BGP, and so forth) Besides interoperating with routing protocols, RSVP also works with QoS implementation mechanisms.These are the mechanisms that provide QoS directly, such as weighted fair queuing (WFQ), weighted random early detection (WRED), and the like.What implementation mechanisms are used is not the direct concern of RSVP. It is up to the routers to determine how QoS will be implemented, based on their own particular capabilities. RSVP only makes the request and leaves it up to the intermediary nodes to deliver QoS. Both unicast and multicast traffic are supported by RSVP. Support for multi- cast is fortuitous, since RSVP is currently used the most prevalently for voice and video traffic, much of which is characterized by multicast flows.We will see later how RSVP interoperates with the Internet Group Management Protocol (IGMP) and Protocol Independent Multicast (PIM) to reserve resources for mul- ticast flows. www.syngress.com 110_QoS_08 2/13/01 11:49 AM Page 274 Advanced QoS Overview • Chapter 8 275 NOTE It is not mandatory that RSVP be enabled everywhere on a network in order for a reservation to be made. RSVP has the built-in capability to tunnel over non-RSVP aware nodes (see the discussion later on the setup process). Though a guaranteed QoS may not be possible in this case, if the non-RSVP network has sufficient bandwidth, for example, tunneling over a Gigabit Ethernet or ATM core, it might be feasible for most applications. In addition, it is not even necessary for the clients to be RSVP capable. Cisco routers provide RSVP functionality for VoIP dial peers. In the next chapter, we configure RSVP in a test environment using RSVP proxy—a function that emulates clients sending RSVP Path and Resv messages. What RSVP Is Not RSVP is not a routing protocol. It relies on typical IP routing protocols to for- ward the RSVP packets.The next section shows how RSVP uses the routed path to create the setup messages that make the actual reservations. Because of its protocol-based nature, RSVP does not monitor reservations. It is, therefore, not a resource manager. It is worth reiterating that it is simply a sig- naling protocol—client talking to client, router talking to router. It does not actu- ally control what kinds of resources are reserved, either.That is up to the routers and their particular capabilities.You can imagine the benefit to a network admin- istrator of knowing at any given moment how many reservations are made across the network.This would help for bandwidth planning and provisioning.Although it is possible to see what reservations are active in the routers, as we will see in chapter 9, the Resource Reservation Protocol has no capability of providing this information directly. Although RSVP is an important QoS mechanism, it is not an implementa- tion mechanism. It could be better thought of as a mechanism that requests QoS from other mechanisms. It is not a packet scheduler, link-efficiency mechanism, or traffic classifier. It does, however, necessarily work with these mechanisms. Otherwise, there would be no actual QoS—just a reservation! How Does RSVP Work? Now that we have a basic understanding of what RSVP is and is not, let us look at the mechanics of setting up a RSVP session.We leave the specifics of config- uring RSVP for the next chapter and concentrate for now on the overall strategy. www.syngress.com 110_QoS_08 2/13/01 11:49 AM Page 275 276 Chapter 8 • Advanced QoS Overview Session Startup RSVP is often set up between two clients in a point-to-point situation, or between multiple senders and multiple recipients (multicast). It is even possible for RSVP to negotiate a multipoint to single-point transmission. In any case, the RSVP session startup process reserves resources in a single direction only.To have full-duplex QoS guarantees, it is necessary for the session startup process to be performed twice, once in each direction. For example, in the case of setting up a VoIP call between two telephone users, it would usually be necessary to set up two reservations, one each way, to guarantee good QoS for both callers. On the other hand, a video stream would necessitate only a one-way reservation. Let us step through the process of a RSVP session startup. In Figure 8.1 we have two clients across a RSVP-enabled network.At the top we have Client A, which we will designate as the sender, and at the bottom we have Client B, which we will consider the receiver.Thus, after the reservation is set up, the bulk data, whether it is voice, video, or something else, will flow from Client A to Client B in a downstream manner. www.syngress.com Figure 8.1 RSVP Session Startup, Path Messages Client A (Sender) Client B (Receiver) Path Path Path Path 110_QoS_08 2/13/01 11:49 AM Page 276 Advanced QoS Overview • Chapter 8 277 The first step is for Client A, the sender, to transmit a RSVP Path message to Client B, the receiver.This Path message travels across the network according to the underlying routing protocol. At each hop through the network, the Path mes- sage is modified to include the current hop. In this way, a history of the route taken across the network is built and passed to the receiver, Client B. Now that Client B has the complete route from the Path message, a reserva- tion (Resv) message is constructed and sent to Client A along the exact reverse path, as shown in Figure 8.2. At each hop, the router determines if the reservation can be made, based on available bandwidth, CPU cycles, and so on. If the reser- vation is possible, resources in the router are allocated, and the Resv packet is for- warded upstream to the previous hop, based on the information in the Resv packet. www.syngress.com Figure 8.2 RSVP Session Startup, Resv Messages Client A (Sender) Client B (Receiver) Resv Resv Resv Resv 110_QoS_08 2/13/01 11:49 AM Page 277 278 Chapter 8 • Advanced QoS Overview NOTE In both the Path and Resv messages, the upstream hop is usually referred to as the previous hop, and the downstream hop is called the next hop. This terminology is derived from the reference point of the bulk data moving in a downstream direction, from sender to receiver. If the reservation is declined, an error message is sent to the receiver, Client B, and the Resv packet is not forwarded. Only when Client A receives a Resv packet does it know that it can start sending data and guarantee a particular QoS to the downstream receiver, Client B. You may think it is odd for the entire RSVP process to begin with the sender building the Path message to the receiver.This might be analogous to a television network deciding that it is time for you to watch your favorite show and automatically turning on the TV. However, there is usually some kind of non-RSVP request originating from the receiver to set up this flow.This might be an H.323 conversation between IP telephony applications, or an IGMP request to join a multicast group to watch a video clip. NOTE Though it is necessary for the sender to first transmit the Path message before the receiver can transmit the Resv message, RSVP is still consid- ered receiver-oriented. That is, the receiver of the data flow initiates and maintains the actual resource reservation used for that flow. Session Maintenance and Tear-Down After a session is initiated, it is maintained on the routers as a “soft state.”With a soft state session, the path connecting two end stations can be renegotiated without consultation with those end stations.This contrasts with a circuit- switched network, where the connection between two end stations is a hard con- nection, and when a failure occurs, the connection is broken. This soft state session must be refreshed by periodic Path and Resv messages; otherwise, it will be terminated after a “cleanup timeout” interval. RSVP’s default interval for this “cleanup timeout” is some multiple of the period of the Path and www.syngress.com 110_QoS_08 2/13/01 11:49 AM Page 278 Advanced QoS Overview • Chapter 8 279 Resv messages.Therefore, if the router misses a single Path or Resv refresh, it will not terminate the session.This kind of tolerance is necessary, since there is no preferential QoS treatment for RSVP messages inherent to the protocol.These messages are sent as best effort unless some provision has been made otherwise, such as DiffServ. These “soft states” are dynamic in response to route changes in the network, changes in senders or receivers, or changes in the requested QoS.There is no real difference between the process of initiating a new reservation and refreshing an old one. In both cases, the Path message is built with the previous hop and next hop information, and the Resv statement is adjusted with any new QoS requirements. NOTE The refresh interval presents a potential problem when the routing changes across an IP network. If a route change causes any change to the shortest path for an active flow, packets will be forwarded over the new route as best effort until Path and Resv messages are sent along this new path. When this occurs, it is possible that there may not be the nec- essary resources to complete the RSVP session. In this case, it is up to the application to decide whether to terminate the session or continue best- effort delivery. Therefore, RSVP may not give the desired results in a net- work with unstable route paths. Good implementations of RSVP will issue tear-down messages when the reservation is no longer needed, instead of waiting for the “cleanup timeout” to remove the session.There are two types of tear-down messages: PathTear and ResvTear. PathTear messages, like Path messages, flow in the downstream direc- tion, whereas ResvTear messages, like Resv messages, flow upstream. In addition to clients issuing immediate requests for tear-downs, routers detecting a session timeout or a loss of resources will send their own tear-down messages to upstream (ResvTear) and downstream (PathTear) neighbors. What Kind of QoS Can I Request with RSVP? The types of QoS that can be reserved by RSVP are consistent with the Internet Integrated Services Model.These types are controlled-load and guaranteed-rate. According to the Intserv definition, controlled-load gives applications service as if they were traversing an unloaded network. Applications requesting controlled- www.syngress.com 110_QoS_08 2/13/01 11:49 AM Page 279 280 Chapter 8 • Advanced QoS Overview load can expect low latency and a low number of packet drops.These applica- tions are usually considered tolerant real-time applications. An example could be an adaptive real-time application like the playback of a recorded conference call. On Cisco routers, controlled-load services are implemented primarily with weighted random early detection (WRED).We will discuss WRED later in this chapter. RSVP can also request guaranteed-rate services. According to the Intserv def- inition, guaranteed-rate delivers assured bandwidth with constant delay. Applications that require this service to function well are usually considered intol- erant real-time applications.An example would be delay-sensitive applications like Voice over IP (VoIP). On Cisco routers, guaranteed-rate services are imple- mented primarily with weighted fair queuing (WFQ). NOTE AlthoughWFQ can provide guaranteed-rate services to applications, it alone may not be sufficient to assure low latency to delay-sensitive appli- cations such as VoIP during periods of congestion. IOS version 12.1(3)T provides support for low latency queuing (LLQ) to RSVP. Reservation Styles and Merging Flows When a reservation is made, a set of options can be chosen that is collectively called the reservation “style.” RSVP supports two classes of reservations, shared and distinct, and two scopes of reservations, explicit and wildcard.A shared reserva- tion is a single reservation made for all packets from multiple upstream senders. A distinct reservation establishes a reservation for each sender. For the scope, an explicit list can be chosen for the senders, in which each sender is enumerated. The other scope option is to use a wildcard that implicitly selects all the senders. These options give rise to three possible reservation styles (see Table 8.1).The combination of a distinct reservation with a wildcard scope is disallowed and is therefore not defined. Table 8.1 RSVP Reservation Styles Scope Reservations Distinct Shared Explicit fixed-filter (FF) style shared-explicit (SE) style Wildcard not defined wildcard-filter (WF) style www.syngress.com 110_QoS_08 2/13/01 11:49 AM Page 280 [...]... guarantee QoS to real-time applications such as voice and video RSVP-aware clients can make a reservation and be guaranteed a good QoS across the network for the length of the reservation www.syngress.com 110 _QoS_ 08 2/13/01 11:49 AM Page 283 Advanced QoS Overview • Chapter 8 Because RSVP takes the Intserv approach to QoS, all traffic in the network does not need to be classified in order to give proper QoS. .. incompatible www.syngress.com 281 110 _QoS_ 08 282 2/13/01 11:49 AM Page 282 Chapter 8 • Advanced QoS Overview Subnetwork Bandwidth Manager We have seen that RSVP is largely independent of the media it is running on with respect to the QoS mechanisms used to implement a particular reservation With serial links, WFQ and WRED can be used to provide either a controlled-load or a guaranteed-rate to an application... until the reservation has been completed www.syngress.com 283 110 _QoS_ 08 284 2/13/01 11:49 AM Page 284 Chapter 8 • Advanced QoS Overview Using Class-Based Weighted Fair Queuing (CBWFQ) We saw in Chapter 6 that priority queuing and custom queuing can be used to give certain types of traffic preferential treatment when congestion occurs on a low-speed serial link.We also saw that weighted fair queuing... CBWFQ can subsequently give specialized bandwidth guarantees.The typical application of this is to mark traffic at the edge with IP precedence, and then let mechanisms like CBWFQ give differential www.syngress.com 287 110 _QoS_ 08 288 2/13/01 11:49 AM Page 288 Chapter 8 • Advanced QoS Overview treatment throughout the entire network according to the service levels defined By placing important applications... www.syngress.com 297 110 _QoS_ 08 2 98 2/13/01 11:49 AM Page 2 98 Chapter 8 • Advanced QoS Overview average = (old_average * ( 1-2 -n)) + (current_queue_size * 2 -n) In this equation, n is the exponential weighting constant that affects how rapidly the average changes with respect to the current queue size By changing this constant,WRED can be configured to be more or less adaptive to bursts in traffic Cisco recommends... this case, caution must be exercised to ensure that you allow enough remaining bandwidth to support Layer 2 overhead, routing traffic, and best-effort traffic www.syngress.com 285 110 _QoS_ 08 286 2/13/01 11:49 AM Page 286 Chapter 8 • Advanced QoS Overview Each user-defined class is guaranteed a certain bandwidth, but classes that exceed that bandwidth are not necessarily dropped.Traffic in excess of the class’s... traffic.This may cause problems if most of your important traffic is something other than IP. The case for QoS may encourage you to advocate transforming your network into a strictly IP network www.syngress.com 110 _QoS_ 08 2/13/01 11:49 AM Page 299 Advanced QoS Overview • Chapter 8 Flow-based Random Early Detection Flow-based RED (FRED) is an extension to WRED that ensures that no single flow can monopolize... www.syngress.com 295 110 _QoS_ 08 296 2/13/01 11:49 AM Page 296 Chapter 8 • Advanced QoS Overview Figure 8. 3 Weighted Random Early Detection (WRED) Classify Discard Test Incoming Packets Buffers Bit Bucket Outgoing Packets WRED and IP Precedence Weighted random early detection (WRED) is the Cisco implementation of RED that combines the capabilities of the RED algorithm with IP precedence to provide lower... the extension of the weighting model by using IP precedence, flow-based fair queuing is still just that—fair.There are www.syngress.com 110 _QoS_ 08 2/13/01 11:49 AM Page 287 Advanced QoS Overview • Chapter 8 times when the fair slice of the bandwidth pie is less than you require for certain applications, or when you require more granular control over the QoS provided to your traffic.When you want a guaranteed... how it will be serviced The limitation of flow-based WFQ is that the flows are automatically determined, and each flow gets a fair share of the bandwidth.This “fair share” of the www.syngress.com 110 _QoS_ 08 2/13/01 11:49 AM Page 285 Advanced QoS Overview • Chapter 8 bandwidth is determined by the size of the flow and moderated by IP precedence Packets with IP precedences set to values other than the default . Shared Explicit fixed-filter (FF) style shared-explicit (SE) style Wildcard not defined wildcard-filter (WF) style www.syngress.com 110 _QoS_ 08 2/13/01 11:49 AM Page 280 Advanced QoS Overview • Chapter 8 281 These. routers. Advanced QoS Overview • Chapter 8 273 110 _QoS_ 08 2/13/01 11:49 AM Page 273 274 Chapter 8 • Advanced QoS Overview NOTE A signaling protocol can be either in-band or out-of-band, depending on whether. Header Compression Chapter 8 271 110 _QoS_ 08 2/13/01 11:49 AM Page 271 272 Chapter 8 • Advanced QoS Overview Introduction This chapter outlines some of the more cutting edge QoS mechanisms available at