Tuesday, 7 April 2015

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  

1 comment:

  1. Every time i search for any Cisco advanced configuration scenarios i hit your blog in google...well done keep it up bro ^_^

    ReplyDelete