RSVP is a Quality of Service (QoS) setup protocol. Quality of Service is a set of communication characteristics required by an application. RSVP does not send or receive data. Other protocols do the actual transmitting and receiving of data. A 5-tuple (protocol, destination address, destination port, sender address, sender port) defines the data flow for a QoS. RSVP sets up QoS for flow in a single direction. If two programs will be both sending and receiving and need QoS for each direction, QoS for each flow must be reserved independently. Initial implementations of RSVP have been mainly concerned with UDP unicast or UDP multicast, or other IP protocols, such as TCP.
The RSVPD.EXE daemon implements the RSVP protocol. Applications use an API interface (LIBRSVP.DLL) to communicate with the daemon. The associated toolkit contains a header file (RSVPRAPI.H) and the library stub for the DLL (LIBRSVP.LIB).
The sender initiates a session and causes RSVP path messages to go to the receiver. The path messages indicate what flow the sender is willing to send. RSVP daemons between the sender and receiver can also add information about what flows they can support. A reservation is set up when the receiver sends a reservation to the sender of a path message. The receiver can ask for confirmation that the reservation was set up.
Once a flow is established, the daemons along that flow maintain it automatically by periodically resending path packets from the sender daemon and resending reservation packets in the reverse direction from the receiver's daemon.
There are two types of QoS specification: a controlled load flowspec and a guaranteed flowspec.
Generally, requesting a Quality of Service means at least that a specific bandwidth (number of bytes per second) is requested. There are five parameters in a controlled load flowspec. There are implications in these parameters about how much the packets can get "bunched up." For example, if you send a 100K burst of packets once every two seconds, the average data rate is 50K per second. This data flow could be unacceptable, because the sender or receiver (or intervening routers) might only be able to handle 10K bursts every 0.2 seconds, for a much more even flow of data. In the part of the TCP/IP stack that performs QoS processing on the local machine, setting up for a particular reservation usually involves at least two major actions:
Some applications, like audio data for a conversation, where excessive delay can easily become intolerable, require packets to be delivered within a specified time. Such applications should use the guaranteed flowspec. Besides the five parameters of the controlled load flowspec, two other parameters, guaranteed rate and slack term, specify the delay through the network.