he origin of the RSVP protocol can be traced b a c k t o 1991, w h e n a t e a m of n e t w o r k researchers, including myself, started playing with a n u m b e r of packet scheduling algorithms on the D A R T N E T (DARPA Testbed NETwork), a network testbed made of o p e n source, workstation-based routers. Because scheduling algorithms simply shuffle packet processing orders according to some established rates or priorities for different data flows, to test a scheduling algorithm requires setting u p t h e appropriate control s t a t e a t each r o u t e r along the data flow paths. I was challenged to design a set-up protocol that could support both unicast a n d many-to-many multicast applications. That effort led to the birth of RSVP. As a signaling protocol designed specifically to run over IP, RSVP distinguishes itself from previous signaling protocols in several fundamental ways. The most profound ones include a soft-state approach, two-way signaling message exchanges, receiver-based resource reservation, and being independent from all other related components in a QOS support architecture, such as flow-specification, admission control, scheduling algorithm, and routing. As stated in the article, "RSVP is primarily a vehicle used by applications to communicate their requirements to the network in a robust and efficient way, independent of the specific requirements." It has been more than 10 years since the original idea was first conceived. Over this time period many people contributed to the effort that has evolved RSVP from a lab toy to a Proposed Internet Standard Protocol. Other more recent protocol developments, such as MPLS (Multi-Protocol Label Switching), VPN (Virtual Private Network), and OTN (Optical Transport Network), to name a few, have adopted or considered RSVP for their own signaling use. I was stunned by RSVP's rapid adoption and development of usage. The protocol has moved on with a life of its own. I have learned many lessons from observing which features in the original design worked and which didn't. Among these lessons, I noticed that the proposal of supporting flexible resource reservations by individual users is yet to prove useful, and that the decision to make RSVP a generic messenger, which simply carries "a bag of bits" to pass to routers along the way, has proven to be a right one, which promoted the adoption of RSVP for various purposes other than QOS support. The effort that started RSVP design is but the first step in developing signaling protocols for t h e I n t e r n e t . Although the debate on which kinds of QOS support the Internet would need continues, various signaling needs demand a generic signaling protocol. Independent from whether RSVP would be the lasting o n e t o fulfill that important role, I believe the basic principles and lessons we have gained from RSVP development will extend beyond the protocol itself into new protocol designs for the future Internet.
As a signaling protocol for network bandwidth reservation, Resource ReserVation Protocol (RSVP) is a popular example REF .
RSVP: a new resource reservation protocol
IEEE Communications Magazine
IEEE Communications Magazine
Computer Science