Design Principles

Sender Reservations

Selection Distinct Shared

Explicit Fixed-Filter Shared-Explicit

(FF) Style (SE) Style

Wildcard (None defined) Wildcard-Filter

(WF) Style Table 2.3: RSVP Reservation Styles

The FF style forces a “distinct” reservation for each individual sender, while SE and WF styles allow the sharing of a single reservation among all packets of the selected senders. The SE style allows the receiver to explicitly specify the set of senders to be included, whereas a WF shares a single reservation with the flows of all upstream senders.

2.3.1.4 Design Principles

In order to meet the design goals presented in section 2.3.1.1, RSVP exploits six basic design principles that are briefly described in this section. These design principles are often used to classify RSVP among other reservation mechanisms and to compare it with other protocols. The principles are described here, and their advantages and disadvantages for resource reservation in the Internet are discussed.

Receiver-Initiated Reservation: In contrast to most other reservation mechanisms, RSVP deploys a receiver-initiated reservation mechanism. Thus, receivers choose the level of resources and decide when to set up and tear down reservations. Since RSVP provides service for multicast applications, senders would have to maintain a reservation for each receiver of the multicast group. This, of course, would not scale for large multicast groups. Thus, RSVP is designed such that the sender does not necessarily need to know the number of receivers and their network characteristics. Furthermore, if network charging is deployed in future networks, the receiver is likely to be the party paying for the requested QoS. Thus, a receiver-initiated reservation mechanism is advantageous.

Receiver-based reservation, however, has two critical aspects. First, in order to allow re- ceivers to reserve resources along the transmission path, which is not known by the receiver due to the lack of routing information, RSVP must deploy the PATH-RESV mechanism de- scribed earlier (or some equivalent approach). Second, receivers can mistakenly reserve less bandwidth than the actual data stream requires. The result is that the sender pushes more data into the network than the network can cope with. The consequences are congestion, leading to uncontrolled packet drop, and wasted bandwidth.

Separation of Reservations from Packet Filtering: Unlike most other reservation protocols, RSVP is designed to make a clear distinction between the resource reservation and the filters determining the packets that can use the resources. The packet classifier is responsible for determining the packets that can use the reserved resources. Both, the packet filter parameters and the reservations are set up by means of RSVP.

The main benefit of this separation is that the packet filters can be dynamically changed within a session without changing (and running the risk of loosing) reservations. Thus, the implementation of channel (i.e. sender or speaker) switching becomes simple.

Supporting Different Reservation Styles: Providing reservation styles that support distinct and shared reservations for explicitly selected or all senders of a session offers a flexible reservation architecture. These different reservation styles allow intermediate routers to merge individual reservations for the same session (as in a multicast group).

Maintaining Soft State: RSVP maintains the resource reservations within the individ- ual network elements by keeping them as soft-state. Soft-state is simply state information that requires periodical refresh, otherwise it is discarded and its associated resources are freed. Soft-state within RSVP is maintained by periodically sending PATH and RESV messages at configurable refresh intervals. State information is updated by simply sending the new path or reservation states.

The RSVP soft-state mechanism adds both adaptability and robustness. Even if the trans- mission path changes due to a route change of the network protocol, the soft-state ensures

2.3. RESERVATION PROTOCOLS 53 proper RSVP operation; unused reservations will eventually time out and new reservations will be established along the new path. RSVP also supports explicit tear down messages (TEARDOWN) to avoid holding reservations for several refresh periods longer than re- quired. The soft-state mechanism is also robust against occasional loss of control messages or if hosts lose their entire state due to a crash. The recovery time following such an error depends mainly on the refresh period of the soft-state. The benefits of the soft-state approach, however, do not come for free; The periodic refresh or exchange of messages be- tween RSVP nodes on a per-session basis adds significant overhead and does not scale. The periodic messages increase the processing load on core routers and the bandwidth required for signalling increases in proportion to the number of sessions. However, the scalability problem occurs only in the core of the network. If RSVP is used within Intranets or local area networks at the edge of the Internet, scalability is not an issue.

There are several solutions to resolve the scalability problem: first, it is suggested that RSVP is used only at the edge of the network, whereas the DiffServ architecture is deployed in the core (see section 3.2.6); second, research on RSVP has shown that soft-state could easily be replaced by a hard-state mechanism with soft-state as fall back solution [MSH98]; and third, ongoing research in the area of aggregation of IntServ state proposes solutions allowing the omission of per-session soft-state in the core network [BV98, GA98].

Protocol Overhead Control: The protocol overhead caused by RSVP is determined by the number of RSVP messages sent, the size of these messages and the refresh frequency. RSVP tries to minimize the protocol overhead by merging path and reservation messages of equal sessions as they traverse the network. Therefore, each link between RSVP nodes carries no more than one PATH message per session in either direction during a path refresh period (and respectively for RESV messages).

Modularity: RSVP mainly interfaces with (1) the end-user application which provides the FlowSpec, (2) the network routing protocol which forwards the PATH messages, and (3) the network admission control process. RSVP is designed to be largely independent of these interfacing components and the FlowSpec format used by the application and the admission control module. The FlowSpec is simply treated as a number of bytes which must be propagated to the admission control modules where it is processed. RSVP is also independent of the underlying routing protocol(s). The only assumption about the routing protocol is that it provides both unicast and multicast routing. RSVP does not assume that the route between a given sender and a receiver is fixed or that it is the same on the reverse path. However, if RSVP obtains notifications of route changes, a fast recovery

mechanism, called local repair (see [B+97b]), can be deployed to re-establish reservations

on the new path. The independence of the route path allows RSVP to be very robust. As long as the network protocol finds a route from the source to destination, RSVP will operate.

In contrast, since changes in the transmission routes are allowed, prevents RSVP from guaranteeing reliable QoS. Route changes due to “new routes becoming available” (rather than “routes being lost”) may cause RSVP to lose the reserved resources on the old link if there are not enough resources available on the new path. Since route changes (or oscil-

lations) are not rare in the Internet 11 and RSVP cannot guarantee QoS “promises” when

route changes occur, RSVP cannot be classified to be a reliable reservation mechanism. The routing interface to RSVP [ZK98] is subject to continuous research because more advanced routing facilities are desirable. One research area is “route pinning”. Flows should have the option to continue using the “old” path without running the risk of loosing their QoS guarantee if it is still properly functioning. Research in the area of QoS-based routing might also put forth solutions to this problem.