Content Summary
RSVP is a modular reservation protocol that sits on top of existing
routing and transport protocols (e.g. TCP). Its unique contributions
include separation of packet filtering from reservation; maintenance of
soft (easily reconstructible after disruption) state at intermediate
switching nodes that helps avoid redundant reservation; and periodic
refresh of path information along a reservation path which if timed out
results in freeing of orphaned resources. (This last feature is
supposed to use adaptive timeout, NYI.) The authors suggest that path
maintenance is essentially an inverse routing table and this service
could therefore be provided by the underlying routing service. As
a reservation protocol, RSVP provides a reservation mechanism but makes
no policy decisions; in particular, it does not schedule packets or
select routes, asking for only a single accept/reject decision from each
intermediate switch. One open issue is whether the interface for doing
this admits the use of sophisticated reservation scheduling such as the
scheme proposed by Ferrari et al.
Main points
- Being implemented in commodity products. Reserves "any" kind of
resources.
- Receiver-oriented, since it's receiver who sees results of
network behavior and knows its own limitations.
- Can reserve for multiple flows (senders) at once, dynamically "filter"
which senders you're listening to (allocate bandwidth among
active set only)
- Reservation messages: "recursion" not iteration. Upstream
routers send reservation messages decoupled from downstream
links. E.g. if a router has already satisified Delay<100 for
some client, a requst from another client on same link asking for
Delay<200 can be trivially satisfied and need not be
propagated.
