Reservation Protocol
(RSVP) is a signaling protocol that allows applications to request and reserve
network resources, usually bandwidth. The core protocol is defined in RFC 2205.
It is important to remember that RSVP is used only for requesting and managing
network resources. RSVP does not carry user application data. Once the network
has allocated the required resources, the application marks the packets for
special treatment by setting the DSCP field to the EF value,
101110.
The process starts when an end device sends an RSVP PATH
request into the network. The destination address of this request is the far end
device that it wants to communicate with. The request packet includes
information about the application's source and destination addresses, protocol
and port numbers, as well as its QoS requirements. It could specify a minimum
required bandwidth, and perhaps also delay parameters. Each router along the
path picks up this packet and figures out the best path to the destination.
Each router receiving an RSVP PATH request replaces the source
address in the packet with its own, and forwards the packet to the next router
along the path. So the QoS parameters are requested separately on each
router-to-router hop. If a router is able to accommodate the request, it sends
back an RSVP RESV message to the requester. For all but the first router on the
path, the requester is the previous router. If a router receives one of these
RESV packets, it knows that everything upstream from it is able to comply with
the request. If it also has the resources to accommodate the requested QoS
parameters, it sets aside the resources and sends an RESV packet to its
downstream neighbor. It also sends an RSVP CONFIRM message upstream to
acknowledge that the request will be honored. The routers periodically pass
PATH, RESV, and CONFIRM packets to one another to ensure that the resources
remain available.
If a router is not able to set aside the requested resources
for whatever reason, it rejects the reservation. This may result in the entire
path being rejected, but it can also just mean that the network will reserve the
resources everywhere except on this one router-to-router link.
It would clearly be counterproductive if every device on the
network could request as much bandwidth as they wanted, whenever they wanted.
This would leave few network resources for routine applications. So usually when
you configure a router for RSVP, you just set aside a relatively small fraction
of the total bandwidth on a link for reservation. Further, you will often want
to restrict which source addresses are permitted to make RSVP requests.
Because RSVP makes its reservation requests separately on each
link, it can easily accommodate multicast flows. In this case, you have to be
careful that the periodic updates happen quickly so that any new multicast group
members won't have to wait long before they start to receive data.
RSVP is an extremely useful technique for reserving network
resources for real-time applications such as Voice over IP (VoIP). However,
because it forces the routers to keep detailed information on individual data
flows, it doesn't scale well in large networks. RSVP is most useful at the edges
of a large network, where you can reserve bandwidth entering the core. However,
you probably don't want it running through the core of your network.