Just when you thought it was safe to ignore the Resource Reservation Protocol (RSVP), the industry is looking to exploit this signalling scheme for everything from quality of service (QoS) to traffic engineering to policy-based management. Fortunately, the renewed interest in RSVP is prompting the Internet Engineering Task Force (IETF) to address some of the protocol’s shortcomings.
RSVP was conceived as a mechanism for allowing applications that require specific QoS, such as IP telephony, to request resources from a network. RSVP messages carry information about the sender that is requesting resources, how to identify the traffic being sent, and the level of service that user’s traffic needs. RSVP also has two other capabilities that are driving renewed industry interest: admission control and policy control.
Nearly two years ago, the IETF published guidelines indicating that wide-scale RSVP deployment must be approached with care. One of the key issues the IETF discussed was RSVP’s scalability. For example, the group raised concerns about the processing and storage burden that RSVP places on routers because each RSVP-capable router must track every RSVP session, or traffic flow, between each pair of senders and receivers. In addition, senders and receivers must periodically send messages to keep their reservation active. Such refresh messages can add to network traffic if a lot of reservations are in use.
One way around the scalability problem is to have RSVP deal with aggregates of traffic flows rather than individual flows. The IETF Multiprotocol Label Switching (MPLS) working group recently proposed this change as part of its work defining standards for explicit routing. Likewise, the MPLS working group has proposed extensions to RSVP to reduce the protocol’s processing requirements, “chattiness” and latency, as well as to improve its reliability.
These changes are intended to make RSVP usable as the signalling mechanism for setting up explicit routes — with or without resource reservations — in service provider networks. This represents a major shift in attitude regarding RSVP, which the industry to date has promoted solely for use in the enterprise environment. Needless to say, if the IETF can make RSVP more scalable, it will potentially open up the technology for use in very large networks.
It’s unclear whether the scalability enhancements to RSVP will encourage service providers to use the Integrated Services type of QoS or simply exploit RSVP signalling for explicit routing. Many industry players still see the Differentiated Services (DiffServ) approach, with its simpler, priority-based class-of-service (CoS) capabilities, as the primary QoS mechanism for use in service provider networks.
However, other vendors and industry players are interested in using RSVP and DiffServ in a complementary fashion. For example, host systems within an enterprise could use RSVP to ensure that key applications get the bandwidth, jitter control and other QoS requirements they need. At the border to the service provider network, RSVP QoS would be mapped to DiffServ.
More importantly, RSVP can be used to carry admission and policy control information. That is, RSVP can carry messages that enable RSVP-capable nodes to determine whether enough resources are available to meet a particular QoS request, and whether a particular user is allowed to make a reservation. Rather than simply carrying QoS information, RSVP can be used to trigger policy checks within enterprises and at the border of service provider networks. For example, RSVP signalling would be used to admit packets into a DiffServ domain.
Microsoft officials and other speakers at the recent iBand2 conference in San Francisco made it clear that they plan to exploit the admission and policy control aspects of RSVP. Microsoft is supporting RSVP in its operating systems, which will enable Windows hosts to generate RSVP messages containing user ID and other policy information.
The firm also is working on admission control server technology that will extract policy information from RSVP messages — a function that will also be performed by network devices, such as routers. The admission control server will then use the Lightweight Directory Access Protocol to check policy data in Active Directory, which will indicate whether a given user’s or application’s RSVP or other QoS-related request should be permitted or denied.
Try to learn as much as possible about Microsoft’s RSVP plans and evaluate what role RSVP might play in your organization’s CoS, QoS and policy strategies. Likewise, RSVP may be a key technology at the enterprise-service provider boundary, where its admission control and policy aspects potentially would be more important than its particular QoS capabilities.
