Resource Reservation Protocol (RSVP) is a quality of service (QoS) mechanism that was first introduced in the Internet Engineering Task Force (IETF) RFC 1633 (1994). RSVP was introduced as an integrated services model for implementing end-to-end QoS in the data network. RSVP provides an end-to-end guaranteed quality of service and relies on signaling mechanisms transmitted from source to destination. RSVP is a topology aware QoS mechanism, while the differentiated services model only makes a per hop guarantee, referred to as a per hop behavior (PHB). RSVP’s greatest disadvantage is the signaling messages that must be process level switched by every router in the end to end path.
Many enhancements (RSVP passthrough, RSVP refresh reductions) have been made to the RSVP protocol in an effort to make the protocol more scalable, but the application in real world networks is still too processor intensive to be considered in any considerable size deployment. Service providers will not perform QoS guarantees using customer-initiated RSVP path messages due to the millions of microflows (IP sessions) that can possibly traverse service provider cores at the same time. Some service provider networks use RSVP-initiated MPLS Traffic Engineering tunnels in MPLS networks for the application of customer macro-flow tunnels. Service providers do not react to customer initiated RSVP signaling messages. Customer RSVP signaling is passed through the service provider cloud, while the service provider performs QoS based on the differentiated services code point (DSCP) marking.
RSVP initiated phone calls can be synchronized from Cisco Unified Communications Manager (CUCM) as of CUCM 5.0. RSVP must be enabled on every router from source to destination unless the passthrough model is being utilized. The passthrough model does not guarantee QoS because passthrough devices may not implement any QoS. RSVP implementation in CUCM requires IOS 12.4(6T) or later and CUCM 5.0 or later. The configuration of RSVP requires a Media Termination Point (MTP) configuration on the router which will act as an RSVP agent to CUCM.
I will not get into the details of implementing RSVP on CUCM since I do everything in my power to avoid the use of the RSVP protocol. I do not recommend the use of RSVP in CUCM even though it is the only topology aware call admission control (CAC) mechanism. The burden on the route processor is far too great and the RSVP mechanism is quite complex to properly provision in CUCM and the routers. Consider the deployment of an H.323 gatekeeper to provide CAC functionality in a production network.
Author: Dennis Hartmann