RSVP is another one of those topics that's easy on the outside, but hard to get to the bottom of. We all know it uses the IntServ model, and that it's an end-to-end "QoS mechanism". But beyond knowing how to turn it on, do you really know its inner workings in IOS? To be specific, I will be covering how IOS handles RSVP, not so much the math and RFC-intentions.
RSVP is an end-to-end signaling QoS signaling protocol. The idea is that the application requiring QoS will speak RSVP natively, signaling towards its target that it is about to send data requiring a certain QoS level. The majority of the routers in between the source and the destination should be speaking RSVP, and reading this message (PATH) as it goes by. When the destination receives this PATH message, it sends back a RESV message towards the source. The RESV message makes the actual "QoS" reservation as it makes its way back up the path. RSVP is inherently one-way; if the receiver in this example also needs to send with a reservation, it needs to send its own, separate PATH back and wait for a RESV. In other words, in this original example, you'll get a reservation only on the egress interfaces the directions the PATH went out, or the ingress interfaces the directions the RESV came in.
Before I diagram this, let's look at an important topic. This reservation doesn't mean a whole lot unless you pair it with some QoS mechanism. RSVP, on IOS, by itself, does nothing other than something akin to CAC (call access control). If you allow 600K to be reserved on every interface, and you're using g711ulaw (~88k per call after overhead), you could expect 6 calls to be permitted. RSVP, if setup end-to-end, does a very good job of making sure interfaces aren't oversubscribed. The idea is if that 7th call were to be placed, all calls might suffer.
