Staged Refresh Timers for RSVP

Document Type Expired Internet-Draft (individual)
Authors Roch Guerin  , Henning Schulzrinne  , Ping Pan 
Last updated 1997-12-03
Stream (None)
Expired & archived
plain text pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at


The current resource Reservation Protocol (RSVP) design has no reliability mechanism for the delivery of control messages. Instead, RSVP relies on periodic refresh between routers to maintain reservation states. This approach has several problems in a congested network. End systems send Path and Resv messages to set up RSVP connections. If the first Path or Resv message from an end system is accidentally lost in the network, a copy of the message will not be retransmitted until the end of a refresh interval, causing a delay of 30 seconds or more until a reservation is established. If a congested link causes a tear-down message (PathTear or ResvTear) to be dropped, the corresponding reservation will not be removed from the routers until the RSVP cleanup timer expires.


Roch Guerin (
Henning Schulzrinne (
Ping Pan (

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)