Gateway-Controlled RSVP CAC (CME or CUBE - no CUCM)

You must configure RSVP on each router that will create reservation using ip rsvp bandwidth [total-kbps] [single-flow-kbps] command. If you do not specify the total bandwidth to reserve, the router reserves 75 percent of the interface bandwidth. If no flow value is specified, any flow can reserve the entire bandwidth.

Synchronization between RSVP and call setup is enabled by default. If it has been disabled, the command to enable it is call rsvp-sync.

To set the DSCP value for RSVP control messages, use the ip rsvp signaling dscp {dscp-value} interface command.

To enable RSVP reservation on dial-peers of originating and terminating gateways, use the commands req-qos & acc-qos. The command req-qos defines the requested QoS level in RESV Request message while the command acc-qos defines the minimum acceptable QoS level in the RESV Response message. The combination of the commands at both gateways defines how the call is treated. This is summarized below in the table.

Call Scenarios	Originating Gateway		Terminating Gateway
	Requested QoS	Acceptable QoS	Requested QoS	Acceptable QoS	Results
1	controlled-load or guaranteed-delay	controlled-load or guaranteed-delay	controlled-load or guaranteed-delay	controlled-load or guaranteed-delay	Call proceeds only if both RSVP reservations succeed.
2	controlled-load or guaranteed-delay	controlled-load or guaranteed-delay	controlled-load or guaranteed-delay	best-effort	Call proceeds only if both RSVP reservations succeed.
3	controlled-load or guaranteed-delay	controlled-load or guaranteed-delay	best-effort	best-effort	Call is released.
4	controlled-load or guaranteed-delay	best-effort	controlled-load or guaranteed-delay	controlled-load or guaranteed-delay	Call proceeds only if both RSVP reservations succeed.
5	controlled-load or guaranteed-delay	best-effort	controlled-load or guaranteed-delay	best-effort	Call proceeds regardless of RSVP results. If RSVP reservation fails, call receives best-effort service.
6	controlled-load or guaranteed-delay	best-effort	best-effort	best-effort	Call proceeds with best-effort service.
7	best-effort	best-effort	controlled-load or guaranteed-delay	controlled-load or guaranteed-delay	Call is released.
8	best-effort	best-effort	controlled-load or guaranteed-delay	best-effort	Call proceeds with best-effort service.
9	best-effort	best-effort	best-effort	best-effort	Call proceeds with best-effort service.

There is no clear guidelines in IETF docs for the use of controlled-load versus guaranteed-delay. However, in summary, guaranteed-delay should be used for voip application.

• The Guaranteed service does not control the minimum or average delay of datagrams, merely the maximal queuing delay. The service guarantees that datagrams will arrive within the requested delivery time and will not be discarded due to queue overflows, provided the flow's traffic stays within its specified traffic parameters.
• Controlled load Service approximates the end-to-end behavior provided to best effort service under unloaded conditions. The assumption here is that under unloaded conditions, a very high percentage of the transmitted packets are successfully delivered to the end-nodes, and the transmission delay experienced by a very high percentage of the delivered packets will not vary much from the minimum transit delay

!!...Configure RSVP on the outgoing interface

Shanghai-GW(config)#int s2/0

Shanghai-GW(config-if)#bandwidth 1544

Shanghai-GW(config-if)#ip rsvp bandwidth 400 40

Shanghai-GW(config-if)#ip rsvp signalling dscp 31

!!...Configure QoS on the outgoing dial peer

Shanghai-GW(config-if)#dial-peer voice 3400 voip

Shanghai-GW(config-dial-peer)#req-qos guaranteed-delay

Shanghai-GW(config-dial-peer)#acc-qos guaranteed-delay

1. FIFO SHOULDN’T be used as queueing mechanism (usually WFQ) when enabling RSVP. This should be noted while having Ethernet interfaces for WAN since default is FIFO. For serial interfaces default is WFQ.
2. In case sub-interfaces are used, WFQ and RSVP should be enabled on parent interface, and RSVP should be enabled on sub-interface (once its enabled on sub it will reflect automatically on parent).
3. In case Loopback interface is used as signaling source (in this diagram H323), still RSVP should be applied in sub interface and NOT Loopback interface.

BR1#sh ip rsvp interface       

interface    rsvp  allocated  i/f max  flow max sub max

Fa0/0        ena   80K        75M      75M      0  

Fa0/0.1      ena   80K        1M       100K     0  

Lo0          ena   0          1M       100K     0