Skip to main content

Staged Refresh Timers for RSVP

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Dr. Roch Guerin , Henning Schulzrinne , Ping Pan
Last updated 1997-12-03
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


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.


Dr. Roch Guerin
Henning Schulzrinne
Ping Pan

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