There are two time parameters relevant to each element of RSVP
path or reservation state in a node: the refresh period R between
generation of successive refreshes for the state by the neighbor
node, and the local state's lifetime L. Each RSVP Resv or Path
message may contain a TIME_VALUES object specifying the R value
that was used to generate this (refresh) message. This R value is
then used to determine the value for L when the state is received
and stored. The values for R and L may vary from hop to hop.
- Floyd and Jacobson [FJ94] have shown that periodic messages
generated by independent network nodes can become
synchronized. This can lead to disruption in network
services as the periodic messages contend with other network
traffic for link and forwarding resources. Since RSVP sends
periodic refresh messages, it must avoid message
synchronization and ensure that any synchronization that may
occur is not stable.
For this reason, the refresh timer should be randomly set to
a value in the range [0.5R, 1.5R].
- To avoid premature loss of state, L must satisfy L >= (K +
0.5)*1.5*R, where K is a small integer. Then in the worst
case, K-1 successive messages may be lost without state being
deleted. To compute a lifetime L for a collection of state
with different R values R0, R1, ..., replace R by max(Ri).
Currently K = 3 is suggested as the default. However, it may
be necessary to set a larger K value for hops with high loss
rate. K may be set either by manual configuration per
interface, or by some adaptive technique that has not yet
been specified.
- Each Path or Resv message carries a TIME_VALUES object
containing the refresh time R used to generate refreshes.
The recipient node uses this R to determine the lifetime L of
the stored state created or refreshed by the message.
- The refresh time R is chosen locally by each node. If the
node does not implement local repair of reservations
disrupted by route changes, a smaller R speeds up adaptation
to routing changes, while increasing the RSVP overhead. With
local repair, a router can be more relaxed about R since the
periodic refresh becomes only a backstop robustness
mechanism. A node may therefore adjust the effective R
dynamically to control the amount of overhead due to refresh
messages.
The current suggested default for R is 30 seconds. However,
the default value Rdef should be configurable per interface.
- When R is changed dynamically, there is a limit on how fast
it may increase. Specifically, the ratio of two successive
values R2/R1 must not exceed 1 + Slew.Max.
Currently, Slew.Max is 0.30. With K = 3, one packet may be
lost without state timeout while R is increasing 30 percent
per refresh cycle.
- To improve robustness, a node may temporarily send refreshes
more often than R after a state change (including initial
state establishment).
- The values of Rdef, K, and Slew.Max used in an implementation
should be easily modifiable per interface, as experience may
lead to different values. The possibility of dynamically
adapting K and/or Slew.Max in response to measured loss rates
is for future study.