unt of bandwidth for a particular data stream, and to receive a confirmation or denial of that request. This protocol is the one necessary for guaranteeing QoS (quality of service) on the Internet. RSVP requests the bandwidth needed for a session; it does not have the authority to command that bandwidth and, therefore, cannot guarantee that resource availability. Standards Approval RSVP was first outlined in 1994 in IETF RFC 1633, "Proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real- time as well as the current non-Real-Time service of IP." It was approved as an IETF standard in October of 1996, and was revised again in 1997 as RFC 2205. Several key concerns remain even after the first version was approved. How RSVP Works RSVP includes two components-a client and a network device. The RSVP client is built into the video communication application, which relies on it to request service priority levels from the RSVP network devices that support the transmission infrastructure. These network devices must, in return, recognize and respond to client requests. Upon receiving a request, an RSVP-enabled device considers network conditions and other factors to determine whether the request can be granted. If the situation looks promising, the router signals the application that it can proceed with its transmission. RSVP requests theoretically result in resources being reserved in each node along the data path, but only in one direction (two-way traffic requires two RSVP flows). RSVP operates on top of IP, as a transport protocol in the protocol stack. Like ICMP, IGMP, or routing protocols, RSVP is a control protocol and does not transport Video Communications: The Whole Picture application data. RSVP is designed to operate with current and future unicast and multicast routing protocols and is not a routing protocol. Routing protocols determine where packets go, and RSVP attempts to ensure the QoS of those packets. RSVP makes receivers responsible for requestin