The former results in heavy message processing overhead at end systems and routers. We have addressed this problem in an on-going project, BGRP.
The latter implies that in a backbone environment, the amount of bandwidth consumed by refresh messages and the storage space that is needed to support a large number of flows at a router are too large. We have developed a new reservation mechanism that simplifies the process of establishing reserved flows while preserving many unique features introduced in RSVP. Simplicity is measured in terms of control message processing, data packet processing, and user-level flexibility. Features such as robustness, advertising network service availability and resource sharing among multiple senders are also supported in the proposal.
The proposed mechanism, YESSIR (YEt another Sender Session Internet Reservations) generates reservation requests by senders to reduce the processing overhead, builds on top of RTCP, uses soft state to maintain reservation states, supports shared reservation and associated flow merging and is backward compatible with the IETF Integrated Services models.
YESSIR extends the all-or-nothing reservation model to support partial reservations that improve over the duration of the session.
We have implemented both RSVP and YESSIR on the IBM Common Router Architecture software platform. Both implementations have the similar data structures and coding style, and share the same set of data processing routines. We measured the various costs associated with RSVP and YESSIR on a router. The measured router was the IBM 2210 Nways Multiprotocol Router, which is based on a Motorola 68040 processor with bus speed of 32MHz. Processing times were measured by reading clock ticks from the timer register of the processor that has a timing resolution of 31.25 ns per tick. We divided the times into categories so that we can have somewhat loose subjective comparison between RSVP and YESSIR.