RSVP works in conjunction with weighted fair queuing (WFQ) or random early detection (RED). This conjunction of reservation setting with packet queuing uses two key concepts: end-to-end flows with RSVP and router-to-router conversations with WFQ. In order to get RSVP supprt for LLQ you need to use WFQ. But as such RSVP can be enabled without having WFQ configured on that interface.
RSVP support for LLQ is dependent on the PQ. If LLQ is not available on any interface or platform, then RSVP support for LLQ is not available.
If ip rtp priority and RSVP is configured on the same interface, RSVP will be using the rtp priority queue.
For more details, refer:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1834/products_feature_guide09186a0080080204.html
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt5/qcfsig.htm#47981
The reservations depends on several factors.You must understand the "feeds and speeds" of your applications. By default, the amount reservable by a single flow can be the entire reservable bandwidth. You can, however, limit individual reservations to smaller amounts using the single flow bandwidth parameter. This value may not exceed the interface reservable amount, and no one flow may reserve more than the amount specified.
By default, 75 percent of the bandwidth available on an interface is reservable. If you are using a tunnel interface, RSVP can make a reservation for the tunnel whose bandwidth is the sum of the bandwidths reserved within the tunnel.
End-to-end controls for data traffic assumes that all sessions will behave so as to avoid congestion dynamically. Real-time demands do not follow this behavior. Determine the bandwidth to set aside so bursty data traffic will not be deprived as a side effect of the RSVP QOS configuration.
Hope this answers your question.
