Resource reservation can occur at two points: at the receivers and at the network switches. Since failure to make adequate resource reservations at the receiver, as required by the sender's traffic profile, simply leads to receiver overflow, such reservations are not a direct concern of the network service. However, in this case flow control mechanisms may have to be employed, which are difficult to scale for multicasting, and even more so when continuous media is concerned. We would expect then the receivers to allocate sufficient resources in advance in order to avoid or minimize flow control problems.
On the other hand, resource reservations at the network switches will be needed if any service guarantees are to be provided. The exact nature of these reservations will differ according to the required service guarantees and the approach taken towards satisfying them[23], so resource reservation along transmission paths could be viewed as a subset of general switch state establishment mechanisms[17]. These mechanisms are employed before connection establishment along with admission control to check for admissibility, and if possible, set up a transmission path. They could also be reused during transmission to alter a connection's reservations. We are narrowing this general problem to resource reservations here, since for the high bandwidth and low delay needs of continuous media, transmission speed, switch capacity and buffer memory will probably all be in short supply. Even though adaptive schemes have been proposed to be used in place of resource reservations[18] to solve the congestion problems that occasionally arise from statistical multiplexing in a packet network, they should be viewed as either supplementary solutions to resource reservations, used to increase efficiency by requesting more relaxed guarantees[16], or as interim solutions for current networks that do not support resource reservations yet.
The first component of resource reservation schemes is a specification model for describing the flow characteristics[67], which depends heavily on the model of service guarantees supported by the network. Then, an appropriate protocol is required to communicate these specifications to the receivers and reserve resources on the transmission path so that the service parameters requested can be supported[68][17]. The simple unicast approaches to resource reservations are source based. A set-up message containing the flow specification is sent to the destination with the intermediate nodes committing adequate resources for the connection, if available. Resources are normally overallocated early on in the path, so that even if following switches are short of resources, the connection can be set up. After the set-up message reaches its destination, assuming the connection can be admitted, a response message is returned on the reverse path (allowing the intermediate switches to relax commitments in some cases).
Similarly, for multicasting, there must be a way for senders to notify receivers of their properties, so that appropriate reservations can be made. In a perfectly homogeneous environment, the reservations will be made once on each outgoing link of a switch, for all downstream receivers, so that resource usage can be minimized. However, receiver and network heterogeneity prohibits use of this simplistic scheme, since each receiver and path may be able, or willing, to commit different amounts of resources. One approach is to allocate resources as before during the first message's trip and then have all receivers send back their relaxation messages. Each switch that acts as a junction will only propagate towards the source the most restrictive relaxation among all those received. However, since paths from such junctions towards receivers may have committed more resources than are now needed, additional passes will be required for convergence. This approach deals with all receivers in a uniform manner, and does not support heterogeneity in any explicit way. Additionally, it is hard to see how it can be extended for groups with dynamic membership without excessive overhead during membership change.
A more flexible approach is to abandon reservations during the sender's multicast set-up message and instead reserve resources based on the modified specifications with which the receivers respond to the initial message[17]. Again, resource reservations will be merged on junction points, but since the (now upstream) requests are expected to be heterogeneous, each junction will reserve adequate resources for the most demanding receivers and reuse them to support the less demanding ones. Even though it is still unclear how aggregation of reservations should be performed, this approach has the potential to support both heterogeneous requests and resource conservation, without ever overcommiting resources, as in the previous schemes, thus maximizing the possibility for a new session to be admitted. Support for dynamic groups can be added by periodically refreshing the reservation status in the switches. This is a viable approach since the mechanism converges in one rather than in multiple passes. Note that such a scheme easily supports heterogeneous users using subsets of hierarchically coded streams.
The interaction of routing and resource reservations (and therefore, admission control) further complicates matters. Even in the simple case of static routing, success in building a multicast tree depends on the adequacy of resources on each switch. We would like to construct the tree using the switches that pass the admissibility tests, thus favoring the sender initiated reservation approach. On the other hand, we do not want the construction to fail due to overallocation, so receiver initiated reservations are preferable because they do not overcommit resources and converge in one pass. Now however, the tree constructed by the routing algorithm may be inadequate to support the reservations, again rejecting a session that could in principle be set-up. We will see later that such problems are even more pronounced when routing is not static, as in many wide area internetworks.