Illustrated TCP/IP by Matthew G. Naugle Wiley Computer Publishing, John Wiley & Sons, Inc. ISBN: 0471196568   Pub Date: 11/01/98

Chapter 337
Issues

Won’t a router become overwhelmed with each receiver making RSVP requests?

No. First, any router has the capability of rejecting a request. Second, RSVP is maintained in the router via a soft state. A reservation will be torn down when it is not needed. Third, RSVP allows for the concept of merging. This allows requests to be merged together (shared) when a reservation equaling the size of the request is already in place.

Will RSVP work in areas that do not support it?

Yes. The ability to simply “flip a switch” and all routers on the Internet are RSVP capable is not a reality. In 1983, we did “flip a switch” and all routers (IMPs) and hosts were running the TCP/IP protocol, but today we have millions of routers connected to the Internet, and moving slowly is the method. Therefore, RSVP will be implemented slowly on the Internet.

We also need some RSVP-aware apps.

RSVP works with non-RSVP environments; however, the non-RSVP environments cannot provide any reservation. RSVP Path messages are forwarded without problems because they use their local unicast of multicast routing tables. In the Path message is the IP address of the last RSVP-capable node before the message traversed a non-RSVP node. In this way, a Resv message is then forwarded directly to the next RSVP-capable router on the path back towards the source. Furthermore, there is a bit setting that RSVP sends to the local traffic control mechanism when it knows that there are non-RSVP nodes hops in the path to a given sender. This allows the router to combine this with other sources of information to foreward a message along the path to receivers using Adspecs.