g a specific QoS (RSVP93). RSVP's weakness lies in the fact that receivers tend to grant the highest QoS to every application that they use. The RSVP protocol carries the user's request to all the routers and hosts along the reverse data path to the data source, as far as the router from which the receiver's data path joins the multicast distribution tree. RSVP Classes of Service RSVP has four service classes, although only two are aimed at Real-Time multimedia. The two most common are Guaranteed Delay and Controlled Load. As the name implies, guaranteed delivery specifies the maximum allowable transmission delay. Controlled load allows priorities to be associated with different streams of data and, in response to those priorities, tries to provide consistent service, even if network usage increases. For applications that can tolerate the late arrival of some packets, two additional RSVP classes, Controlled Delay and Predictive Service are offered. They allow for specified bounds on delay. Deploying RSVP on the Client RSVP sits on top of IP in the protocol stack. Client applications will have to add it to use the services of RSVP network devices. Early implementations of RSVP shipped as middleware (Precept Software has a well-publicized one) but RSVP soon became an inherent part of the desktop operating system (e.g., Windows 98 and Windows 2000). RSVP's Impact on Network Infrastructure While RSVP does not require a wholesale overhaul of network infrastructure, it does require support by the switches and/or routers that make up a transmission path. If any device along the path fails to support RSVP, it can circumvent the efforts of the rest that do. For switches and routers to become RSVP-enabled, they must be able to provide multiple queues. These queues buffer lower-priority data when higher-priority data is being transmitted. Most modern routers offer multiple queuing capabilities. Consequently, they must deal with traffic on a first-in, first-out (FIFO) basis. Here, RSVP faces a challenge. The frame format of 