/mcpQuality of Service for Voice over IP Resource Reservation Protocol 28 QoSVoIP.mif One consideration when deploying RSVP for VoIP is the impact of resource reservation on the postdial delay. Implementing VoIP CAC based on RSVP relies on a prompt confirmation or rejection of the requested reservation. The time taken to reserve resources adds to the postdial delay, which should be kept as low as possible in most cases. RSVP packets are carried inside IP datagrams and are unreliable by nature. If an RSVP packet is lost during the initial reservation setup, an RSVP refresh timer must expire before the lost packet is resent. Because this refresh timer typically is defined in tens of seconds, a scenario that may add a postdial delay is unacceptable for the user. The call rsvp-sync resv-timer global configuration command lets you control the maximum amount of time that the terminating gateway waits for the result of RSVP reservation requests. The default value of this timer is 10 seconds; you can set it to a value from 1 to 60 seconds according to your expectation of postdial delay. Using RSVP with LLQ Flows requesting a particular QoS via RSVP can take advantage of the queueing alternatives available in LLQ, which has two major components: a strict priority queue (PQ) and a CBWFQ system. Earlier implementations of RSVP relied on WFQ to meet the QoS requirements for delay-sensitive traffic. A reserved queue with a low weight was created when the RSVP reservation was installed. However, WFQ could not meet the delay requirements of voice traffic, and voice calls using RSVP were not able to take advantage of the PQ available throughout LLQ. In Cisco IOS Release 12.1(3)T and later releases, a priority profile based on traffic characteristics exists so that certain flows can take advantage of the strict PQ in LLQ. When a RSVP reservation request is received on an interface where you have enabled WFQ, the flow traffic specification (TSpec) is compared against the profile to decide if that flow should take advantage of the PQ or if a queue should be reserved on the WFQ system. The TSpec is the traffic description carried in RSVP messages. This traffic description is made in terms of a token bucket (token rate r, plus a bucket size b) and some additional parameters (peak rate p, minimum policed unit m, and maximum packet size M). The PQ profile is defined in terms of token rate, bucket size, and an optional peak rate to token rate ratio. Flow reservations with a TSpec that do not exceed those defined in the PQ profile will use the PQ. Those flows with a TSpec that exceeds at least one parameter defined in the profile will get a reserved queue in the WFQ system. The priority profile allows you to classify priority flows based on their traffic characteristics—not just on the transport protocol and port. Figure 8 shows the LLQ structure for an interface where traffic is classified into different queues using several methods, including RSVP. G729br8 24 G729r8 24 GSMEFR 29 GSMFR 30 Table 6 Bandwidth Reserved by RSVP per VoIP Call (continued) Codec Reserved Bandwidth per VoIP Call (kbps)