RSVP ready to manage VoIP, video traffic

Network managers looking for help with real-time communications should reconsider their reservations about RSVP, or the Resource Reservation Protocol.

Though stigmatized by past failings, the protocol is now one of the best tools available for managing quality of service (QoS) for real-time media, particularly voice over IP (VoIP) and video. Given the rapid growth of real-time communications, a sophisticated QoS mechanism is vitally important to traffic management.

Several misconceptions about RSVP's scalability have lingered since the protocol's inception a decade ago. However, much has changed since those early days of RSVP. Significant advances in the technology and improvements in the industry's understanding of real-time networking design have combined to mitigate virtually all of RSVP's initial scalability shortcomings.

RSVP travels ahead of a phone call session or other media stream to check whether intermediary routers have enough capacity to effectively handle the session. As the acronym implies, the protocol reserves space for performance-sensitive traffic. It checks on the availability of resources at a router to make sure it is not too busy with other traffic, thereby ensuring the quality of the signal as it passes through a node.

After the Internet Engineering Task Force (IETF) ratified RSVP as a standard in the mid-1990s, early field use exposed several weaknesses. Because it required so much work on the part of the router to manage the traffic reservations, RSVP put too heavy a processing load on network routers as traffic levels grew, thereby causing bottlenecks and hampering performance.

Initially, network engineers assumed that every router needed to support RSVP, which meant greatly increased workloads throughout a communications infrastructure. But with experience, the industry has learned that RSVP is unnecessary except in the most heavily congested nodes, such as consolidated access points on the edge of wide-area networks.

RSVP's activity in the data plane has also been a source of scalability concerns. The first versions of RSVP classified the traffic in the data plane, performing a detailed packet examination that slowed traffic. Over the years networks administrators have satisfactorily relied on other mechanisms for managing traffic so that such detailed classification is no longer necessary.

RSVP is now able to work with a Differentiated Services solution and can use the Differentiated Services Code Point, which serves as an identification badge of sorts for VoIP or other high-priority media traffic. This eliminates the need for the router to conduct an in-depth examination of traffic packets. The router only has to see the code point to provide the necessary QoS treatment.

Earlier versions of RSVP -- a "soft state" protocol -- also ran into a problem with the number of session refreshes required to maintain a reservation request. This was a significant problem to RSVP's scalability, but the IETF addressed this issue several years ago with the addition of "refresh reduction," which combines multiple refreshes into a single message. The IETF also created a means to aggregate multiple RSVP reservations into one message, again boosting RSVP's scalability.

Scalability was not the only challenge for early versions of RSVP. The protocol did not have a means for seamlessly recovering if a message was lost while a call was being established. The IETF solved this issue with another addendum to RSVP, called "reliable messaging." This mechanism sends refresh messages at a much higher rate than normal at the beginning of a call. Once the call connects, RSVP then returns to the default refresh interval of one and a half minutes.

Because of RSVP's initial shortcomings, many network managers have shied way from it, instead relying on a much more basic admission-control mechanism. Known generically as "call counting," this approach simply counts the number of sessions that can be allowed. Once a certain number of sessions is reached, additional requests are refused.

This technique was satisfactory five years ago, but VoIP, video and other media communications are exploding. Such call-counting mechanisms cannot effectively address the volume and complexity of today's real-time traffic. Call-counting functions have no ability to adjust to network events.

For a few years, the IETF has also been working on an alternative protocol to RSVP called Next Steps in Signaling. NSIS is still not available in production routers and applications, and when all is said and done, NSIS may not be much different from the more mature RSVP. As was demonstrated with RSVP, any new protocol goes through an initial reality check, when live deployments reveal unanticipated issues. RSVP, on the other hand, has been extensively vetted in thorns-and-all networks for a decade, giving the protocol a thoroughness that no standards body can imbue in the first iteration of any protocol.

RSVP is a tested, decade-old standard. It might have taken 10 years, but the issues surrounding RSVP have been addressed, and the protocol now offers a dependable and much-needed tool in handling the ever-greater flows of VoIP and other media traffic. The time is right to take another look at RSVP.