Associated with each reservation made at a router'ís interface is a Filterspec describing the packets to which the reservation applies along with an effective Flowspec. Both the Filterspec and effective Flowspec are obtained from a merging process applied to selected Resv messages arriving on the routerís interface. The rules for merging are dependent upon the reservation ``Style'' of each Resv message as described below. In addition the router calculates the Filterspec and Flowspec of Resv messages to be sent to the previous hop(s) upstream by applying Style-dependent merging of stored reservation state. Any changes to stored reservation state that result in changes to the Resv messages to be sent upstream will cause an updated Resv message to be sent upstream immediately. Otherwise Resv messages are created based on stored reservation state and sent upstream periodically. As for path state all reservation state is stored in routers using soft-state and consequently relies on periodic refreshes via Resv messages to prevent state timeout. The periodic Resv message is necessary and sufficient to prevent reservation state timeout. Of course, if a router crashes, a Path message is necessary after reboot so that the Resv can rendezvous with it.
In addition just as a PathTear message exists to explicitly tear down path state, a ResvTear message exists to explicitly tear down reservation state.
Currently three reservation Styles are permissible as described below and illustrated in Figures 2.4 to 2.8 where the convention Style(FilterspecFlowspec) is used to summarise the requests made by the Resv messages. It should be noted that the merging processes described below apply only to packets of the same Session(This is true of any RSVP process). Also merging can only occur between messages with the same reservation style. Details of the reservation styles are as follows where it is assumed that each interface I in Figures 2.4 to 2.6 is routable to each of the router's other interfaces.
The Filterspec of each FF reservation installed at an interface consists of a single sender only. The effective Flowspec of the reservation installed is the maximum of all FF reservation requests received on that interface for that particular sender. In cases where the interface connects to a shared medium LAN Resv messages from multiple next hops may be received.
The Flowspec of the FF Resv message unicast to the previous hop of a particular sender is given by the maximum Flowspec of all reservations installed in the router for that particular sender.
The Filterspec of each WF reservation installed at an interface is wildcard and matches on any sender from upstream. The effective Flowspec installed is the maximum from all WF reservation requests received on that particular interface. The Flowspec of each WF Resv message unicast to a previous hop upstream is given by the maximum Flowspec of all WF reservations installed in the router. More strictly speaking, only WF reservations whose ``Scope'' applies to the interface out of which the Resv message is sent are considered for this second merging process. Scope details are required for WF reservations on non-shared trees to prevent looping. Further details can be found in [#!rsvpv1!#].
The Filterspec of each SE reservation installed at an interface contains a specific set
of senders from upstream and is obtained by taking the union of the individual
Filterspecs from each SE reservation request received on that interface. The effective
Flowspec installed is the maximum from all SE reservation requests received on that
particular interface. The Filterspec of a SE Resv message unicast out of an interface to
a previous hop upstream is the union of all senders whose previous hop is via that
interface and who are contained in the Filterspec of at least one SE reservation in the
router. Likewise the Flowspec of this SE Resv message is given by the maximum
Flowspec of all SE reservations whose Filterspecs contain at least one sender whose
previous hop is via that interface.
SE and WF styles are useful for conferencing applications where only one sender is likely to be active at once in which case reservation requests for say twice the sender bandwidth could be reserved in order to allow an amount of over-speaking. Although RSVP is unaware of which service(Controlled-Load or Guaranteed) reservations refer to, RSVP is able to identify those points in the distribution tree that require reshaping in the event that the reservations are for Guaranteed Service as described in section 2.8.2. Consequently at all such points RSVP informs the traffic control mechanisms within the appropriate router accordingly although such action will only result in reshaping if the reservation is actually for Guaranteed Service.