As seen in the introduction, RSVP is used to request qualities of service from the network. Those reservations are made for simplex flows, and can be dynamically changed.
RSVP operates on top of IP (IPv4 or IPv6) occupying the place of a transport protocol in the protocol stack (but it does not transport any application data). The RSVP traffic is UDP2.3 encapsulated, which means that it is unreliable. The packets sent use UDP port number 46.
A session is defined as a data flow with a particular destination and transport-layer protocol. Each session can be either a unicast or a multicast session.
The reservations are described by a flow descriptor, which is composed of a flowspec, specifying the requested quality of service and describing the data flow, and a filter spec, which enables the packets to be filtered.
The receiver of a data flow is made responsible for the reservation, in order to handle dynamic group membership easily: the sender sends an RSVP message to a host telling that it is willing to send information to it, and then the receiver of the message requests a reservation (as shown in figure ![[*]](crossref.png)
).
The RSVP process does two basic operations:
The request is analysed. If the changes requested are possible, the state is updated.
The message can be modified by the RSVP process.
An RSVP implementation has two decision modules. Admission control determines whether the node can supply the requested quality of service and policy control is responsible for checking administrative permissions for a particular reservation, as shown in figure . Both checks must succeed in order to make the reservation.
It is noticeable that the RSVP process needs to know where to forward the message. As RSVP is not a routing protocol, it has to consult the local routing tables to get this information. Therefore an implementation needs an interface with the routing mechanisms of the node.
