A reservation request includes a set of options that are collectively called the reservation "style".
One reservation option concerns the treatment of reservations for different senders within the same session: establish a "distinct" reservation for each upstream sender, or else make a single reservation that is "shared" among all packets of selected senders.
Another reservation option controls the selection of senders; it may be an "explicit" list of all selected senders, or a "wildcard" that implicitly selects all the senders to the session. In an explicit sender-selection reservation, each filter spec must match exactly one sender, while in a wildcard sender-selection no filter spec is needed.
Sender || Reservations:
Selection || Distinct | Shared
_________||__________________|____________________
|| | |
Explicit || Fixed-Filter | Shared-Explicit |
|| (FF) style | (SE) Style |
__________||__________________|____________________|
|| | |
Wildcard || (None defined) | Wildcard-Filter |
|| | (WF) Style |
__________||__________________|____________________|
Figure 3: Reservation Attributes and Styles
The following styles are currently defined (see Figure 3):
The WF style implies the options: "shared" reservation and "wildcard" sender selection. Thus, a WF-style reservation creates a single reservation shared by flows from all upstream senders. This reservation may be thought of as a shared "pipe", whose "size" is the largest of the resource requests from all receivers, independent of the number of senders using it. A WF-style reservation is propagated upstream towards all sender hosts, and it automatically extends to new senders as they appear.
Symbolically, we can represent a WF-style reservation request by:
WF( * {Q})
where the asterisk represents wildcard sender selection and Q represents the flowspec.
The FF style implies the options: "distinct" reservations and "explicit" sender selection. Thus, an elementary FF-style reservation request creates a distinct reservation for data packets from a particular sender, not sharing them with other senders' packets for the same session. Symbolically, we can represent an elementary FF reservation request by:
FF( S{Q})
where S is the selected sender and Q is the corresponding flowspec; the pair forms a flow descriptor. RSVP allows multiple elementary FF-style reservations to be requested at the same time, using a list of flow descriptors:
FF( S1{Q1}, S2{Q2}, ...)
The total reservation on a link for a given session is the `sum' of Q1, Q2, ... for all requested senders.
The SE style implies the options: "shared" reservation and "explicit" sender selection. Thus, an SE-style reservation creates a single reservation shared by selected upstream senders. Unlike the WF style, the SE style allows a receiver to explicitly specify the set of senders to be included.
We can represent an SE reservation request containing a flowspec Q and a list of senders S1, S2, ... by:
SE( (S1,S2,...){Q} )
The RSVP rules disallow merging of shared reservations with distinct reservations, since these modes are fundamentally incompatible. They also disallow merging explicit sender selection with wildcard sender selection, since this might produce an unexpected service for a receiver that specified explicit selection. As a result of these prohibitions, WF, SE, and FF styles are all mutually incompatible. It would seem possible to simulate the effect of a WF reservation using the SE style. When an application asked for WF, the RSVP process on the receiver host could use local state to create an equivalent SE reservation that explicitly listed all senders. However, an SE reservation forces the packet classifier in each node to explicitly select each sender in the list, while a WF allows the packet classifier to simply "wild card" the sender address and port. When there is a large list of senders, a WF style reservation can therefore result in considerably less overhead than an equivalent SE style reservation. For this reason, both SE and WF are included in the protocol.
Other reservation options and styles may be defined in the future.