A number of establishment protocols for internetworks have been proposed in the literature. Some representative approaches are described below.
ST-2 [16] is the successor of ST [11], which in turn was designed to support voice conferencing and is capable of making both unicast and multicast resource reservations. ST reserves resources over a single, duplex distribution tree that is created by merging the paths of multiple unicast routes; this was done with the assumptions that the routes are reversible and the application data traffic travels in both directions. However ST requires a centralized Access Controller to coordinate among all the participants and to manage the tree establishment.
The ST-2 protocol continues to create its own multicast trees by blending the paths from unicast routing; however, ST-2 establishes multiple simplex reservations to eliminate the Access Controller. Each data source makes a resource reservation along a multicast tree that is rooted at the source and reaches out to the receivers; the reservation made along the tree uses a single flowspec, therefore ST-2 cannot accommodate heterogeneous receivers. Because each data source makes its reservation independently, a single pipe is reserved from every source to every receiver in the same multicast application group. Thus, neither ST nor ST-2 provide a robust and efficient solution to the multicast resource reservation problem.
In RSVP [17], the traffic specification is forwarded from the sender along the multicast tree inform of path message. Receivers establish connections by sending reservation request in the reverse(i.e. upstream) along the multicast tree. The nodes along the way reserve the necessary resources to accommodate the new request. If the reservation is rejected at any intermediate server, the RSVP reject message will be sent back to the receiver, and the reservation message is discarded. Otherwise, the message is propagated upstream. The reservation request messages are sent periodically to adapt to change dynamically.
This scheme can satisfy the per-link services but does not allow end-to-end delay or jitter bounds, because the network cannot tell whether the cumulative delay resulting from the reservation meets the desired end-to-end delay. However, this scheme supports multicast very well by combining IP multicast and a receiver-initiated connection establishment scheme.
In One-Path-With-Advertisement (OPWA) [15], the basic RSVP scheme is extended to give receivers and nodes along routes enough information so that they know the effect of local resource allocations on the end-to-end QoS guarantees. This is done by so-called "advertising" (ADV) control message that are sent from the sources to all receivers. ADV message "advertise" the end-to-end QoS guarantees provided with given local resource allocations at the nodes on the route. Nodes on the route evaluate the end-to-end delay resulting from per-link service requests, and choose the desired level of service.
Tenet Suite 2 [4, 13] uses a two-pass allocation scheme patterned after Tenet Suite 1 [8, 10], which is extended by providing support for multiparty. Suite 2 uses target sets as receiver abstraction, and provides extensive functionality needed for multiparty, such as sender-initiated, and receiver-initiated establishment, dynamic membership in target sets, resource sharing among connections, third-party operations, and advance reservation.
Similarity to Suite 1, the establishment backbone of the protocol is provided by the Real-Time Channel Administration Protocol (RCAP) [13]. The establishment of a real-time multiparty channel happens as follows: First, RCAP gets a possible route for the channel from the routing subsystem. The server then issues a reservation message which contains the traffic specification for the channel. This message follows the given route, replicating itself at each branch node it encounters on its path, and sending a copy of the message down each of the branches of that subtree. Each node on the path reserves resources for the new channel. Given the amount of resources it allocates and the local scheduling policy, it determines arrival of the local delay bound for the channel, and passes the cumulative delay to the next node downstream. Upon arrival of the message at the receiver, the cumulative delay is compared with the end-to-end delay required by the QoS specification of the receiver. If the cumulative delay exceeds the end-to-end delay, the receiver issues a reject message, and the connection is denied. Otherwise, a relax message is issued and sent back upstream. Upon receiving this relax message, each node adjusts the tentative resource allocations made earlier according to the information received from each accepting destination. The process of adjusting the resource requirements and reducing them to satisfy the needs of accepting destinations is called resource relaxation. At the end of this process, the source receives the results of the request in a single return message, and transmits them to the client for evaluation and further action. The newly established channel remains in existence until it is torn down by the client.
In case of unicast channels, the two-pass resource allocation procedure is enough to relax the tentative resource allocation. However, such a scheme cannot be used for multicast real-time channels because the interdependence between a branch node and its descendents effectively introduces interdependence relations between resource allocations across the subtrees. To solve these problems, we suggest a Three-Pass Establishment Protocol, which will be described in Section 3.
Dynamic Resource Migration (DRM) [5] is a gradient-based dynamic resource reservation protocol using a one-pass establishment protocol. During the establishment, no attempt is made to relax resource allocations; that is, local resource managers allocate resources at will in the attempt to meet the end-to-end requirements. After the connection establishment, resources are dynamically reallocated to balance the load on nodes. In particular, excessive slack detected at the receivers can be ``traded'' against relaxation of resources at intermediate nodes. This reallocation must be done without affecting the QoS guarantees. The scheme has been proved to effectively relax resource allocations after establishments and to quickly adapt to changes in the network load.