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.

Fixed Filter (FF)

(distinct reservation and explicit sender selection)

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.

Figure 2.4:
Fixed Filter Reservation Example.

Wildcard Filter (WF)

(shared reservation and wildcard sender selection)

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!#].

Figure 2.5:
Wildcard Filter Reservation Example.

Shared Explicit (SE)

(shared reservation and explicit sender selection)

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.

Figure 2.6:
Shared Explicit Reservation Example.

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.