RSVP
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 Expedited Forwarding (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 quality of service 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 upstream
neighbor. And it sends an RSVP CONFIRM message downstream to acknowledge that
the request will be honored. The routers pass PATH, RESV, and CONFIRM packets to
one another periodically 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.
Clearly it would be counterproductive if every device on the
network could request as much bandwidth as the 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 sufficiently quickly that any new
multicast group members won't have to wait long before they start to receive
data. Please refer to Chapter 23 for more
detailed discussion of multicast services.
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 through the core of your network.
In large networks, it is common to use RSVP only at the edges
of the network, with more conventional DSCP-based methods controlling QoS
requirements in the core.
Sections
Comments (0 posted)
Syndication
