Illustrated TCP/IP Illustrated TCP/IP
by Matthew G. Naugle
Wiley Computer Publishing, John Wiley & Sons, Inc.
ISBN: 0471196568   Pub Date: 11/01/98
  

Previous Table of Contents Next


Chapter 326
Where It Will Be Used

Let’s be up front: RSVP is not designed to provide QoS for the entire Internet. Its original design was to allow QoS for multimedia applications on smaller networks. It is designed to allow applications to choose among multiple, controlled levels of delivery service for their data packets. It reserves network resources along the transmission path of a datastream. It communicates between sending and receiving hosts, but the creation of the reservation is accomplished by the receiving host and only in one direction for data flows. Once the reservation is made, routers between the sender and receiver maintain the reservation. Finally, it is not a replacement for any of the QoS offerings in ATM. Many see it as the migratory step in moving to ATM.

Like ToS in the IP header (IPv4), applications must be RSVP aware. The user application is the one that makes use of RSVP. As of this writing, there are just a few applications that make use of RSVP; for example, WinSock (the API for Windows applications) is QoS aware starting with WinSock 2. Applications that are not RSVP aware may be able to use RSVP tool-kits or dialer programs, which are secondary applications that can make a request for you before starting your application. Applications such as those that are making use of other Internet protocols (such as Real Time Protocol (RTP), and the Real Time Streaming Protocol (RTSP) are better suited to RSVP.

Where It Will Be Used

  RSVP covers the QoS portion of protocols optimized for real-time, streaming, and multimedia issues:
  RTSP: Real-Time Streaming Protocol—App Layer
  RTP: Real-Time Transport Protocols (RFC 1889)
  RTCP: Flow/Control Mechanisms (RFC 1890)
  RSVP: IETF Draft-14 (QoS)


Previous Table of Contents Next