The Resource Reservation Protocol

Resource reservation techniques for IP networks are specified in RFC 2205,
the Resource Reservation Protocol (RSVP), which is part of the IETF integrated
services suite. It is a protocol that enables resources to be reserved
for a given session or sessions prior to any attempt to exchange media
between the participants. Of the solutions available, it is the most complex,
but is also the solution that comes closest to circuit emulation within the IP
network. It provides strong QoS guarantees, a significant granularity of
resource allocation, and significant feedback to applications and users.
RSVP currently offers two levels of service. The first is guaranteed,
which comes as close as possible to circuit emulation. The second is controlled
load, which is equivalent to the service that would be provided in a
best-effort network under no-load conditions.
Basically, RSVP works as depicted in Figure 8-19. A sender first issues
a PATH message to the far end via a number of routers. The PATH message
contains a traffic specification (TSpec), which provides details of the data that the sender expects to send, in terms of the bandwidth requirement
and packet size. Each RSVP-enabled router along the way establishes
a “path state” that includes the previous source address of the PATH
message (that is, the next hop back towards the sender). The receiver of the
PATH message responds with a reservation request (RESV) that includes
a flowspec. The flowspec includes a Tspec and information about the type
of reservation service requested, such as controlled-load service or guaranteed
service.
The RESV message travels back to the sender along the same route that
the PATH message took (in reverse). At each router, the requested resources
are allocated, assuming that they are available and that the receiver has
the authority to make the request. Finally, the RESV message reaches the
sender with a confirmation that resources have been reserved.
One interesting point about RSVP is that reservations are made by the
receiver, not by the sender of data. This is done in order to accommodate
multicast transports, where there may be large numbers of receivers and
only one sender.
Note that RSVP is a control protocol that does not carry user data. The
user data (e.g. voice) is transported later using RTP. This occurs only after
the reservation procedures have been performed. The reservations that
RSVP makes are soft, which means that they need to be refreshed on a regular
basis by the receivers(s).