10-13 Use RSVP for QoS Signaling | Cisco Field Manual[c] Router Configuration

Resource Reservation Protocol (RSVP) is used to set up end-to-end QoS across a heterogeneous network.
RSVP is an IP protocol that provides out-of- band signaling to request the network resources to implement a specific QoS policy. Other queuing methods are needed to implement the QoS reservations .
RSVP can make controlled load (using WRED) or guaranteed rate (using WFQ) reservations.
When RSVP receives a reservation request for an application, it propagates requests across the network to the destination. At each network node (router), RSVP requests the reservation so that resources across an end-to-end path are reserved.
RSVP provides admission control such that reservation requests are set up and granted only as network resources are available.
RSVP can work with Low Latency Queuing (LLQ) to provide strict priority queuing for time-sensitive voice traffic. Other nonvoice traffic is carried over other reservations.
RSVP supports reservations and queuing for voice flows over Frame Relay. Admission control and resource reservations occur on a per-VC (DLCI) basis.
RSVP can work with Common Open Policy Service (COPS) to provide centralized monitoring and management of RSVP. COPS for RSVP can work over Ethernet, Fast Ethernet, HSSI, and T1 interfaces.
COPS Policy Decision Points (PDPs) are servers running Cisco QoS Policy Manager, for example. Policy Enforcement Points (PEPs) are routers acting as COPS clients .

NOTE

RSVP must be used in conjunction with WFQ or WRED. RSVP performs resource reservations, and WFQ or WRED performs the actual reservation implementation.

Configuration

Use RSVP with LLQ.
1. Enable RSVP to work with a strict priority queue:
```
 (global)  ip rsvp pq-profile  [  voice-like   r  ' [  b  '[  p-to-r  '  ignore-peak-value  ]] 
```
  The voice-like keyword indicates that the typical p-q (priority queue) profile is used for voice flows. The default r ', b ', and p-to-r ' values are used. Voice flows are directed into the strict priority queue of WFQ.
  
  However, specific values can be given for r ' (maximum flow rate; 1 to 1048576 bytes/sec; the default is 12288 bytes/sec), b ' (maximum burst; 1 to 8192 bytes; the default is 592 bytes), and p-to-r ' (maximum ratio of peak rate to average rate; 100 to 4000 percent; the default is 110 percent). With the ignore-peak-value keyword, the peak-to-average rate ratio is not evaluated. A flow is directed into the priority queue as long as its parameters are less than or equal to all the parameters given.
2. Enable RSVP on an interface:
```
 (interface)  ip rsvp bandwidth  [  interface-kbps  [  single-flow-kbps  ]] 
```
  RSVP can be configured with interface-kbps, the maximum amount of bandwidth that may be allocated on the interface (1 to 10,000,000 kbps), and single-flow-kbps, the maximum amount of bandwidth that may be allocated to a single flow (1 to 10,000,000 kbps).
3. (Optional) Specify a burst factor for the interface:
```
 (interface)  ip rsvp burst policing  [  factor  ] 
```
  The optional factor (100 to 700; the default is 200 percent) gives the burst factor as a percentage of the requested burst. In other words, the burst factor tells how strict or loose traffic bursts on the interface are policed. Lower values are more strict; higher values are more loosely enforced.
4. (Optional) Enable RSVP proxy for non-RSVP hosts .
  - Send and receive RSVP RESV messages:
```
 (global)  ip rsvp reservation   session-ip-address sender-ip-address  {  tcp   udp   ip-protocol  }  session-dport sender-sport   next-hop-ip-address next-hop-interface  {  ff   se   wf  } {  rate   load  }  bandwidth burst-size  
```
  - Send and receive RSVP PATH messages:
```
 (global)  ip rsvp sender   session-ip-address sender-ip-address  {  tcp   udp   ip-protocol  }  session-dport sender-sport   previous-hop-ip-address previous-hop-interface bandwidth burst-size  
```
    The router simulates receiving and forwarding RSVP reservation ( ip rsvp reservation ) and path ( ip rsvp sender ) requests in case a downstream or upstream host is not RSVP-capable. IP addresses are given for session-ip-address (the intended receiver or destination), sender-ip-address (the sender), and next-hop-ip-address (the router nearest the receiver) or previous-hop-ip-address (the router nearest the sender). The interface of the next-hop or previous-hop router is also given as next-hop-interface or previous-hop-interface ( ethernet, loopback, null, or serial ).
    
    The tcp, udp, or ip-protocol (0 to 255) specify what protocol is carried over the reservation. The port numbers are given for session-dport (the receiver's destination port) and sender-sport (the sender's source port). If a destination port is set to 0, RSVP expects that either the application doesn't use port numbers or all port numbers apply to the reservation.
    
    For RESV messages ( ip rsvp reservation ), the reservation style is given as ff (fixed filter, a single reservation), se (shared explicit, a shared reservation with limited scope), or wf (wildcard filter, a shared reservation with unlimited scope). The reservation is either rate (guaranteed rate) or load (controlled load). The reservation bandwidth can be given as bandwidth (1 to 10,000,000 kbps), the average rate, which can be up to 75 percent of the total interface bandwidth. The maximum burst size is given as burst-size (1 to 65535 KB).
(Optional) Use COPS for RSVP.
1. Define the COPS servers:
```
 (global)  ip rsvp policy cops  [  acl  [  acl  ]...]  servers   server-ip  [  server-ip...  ] 
```
  Up to eight COPS policy servers can be specified as server-ip, with the first one acting as the primary server. The traffic sessions to be governed by the COPS policy can be limited with one or more standard or extended acl numbered IP access lists (1 to 99 or 100 to 199), separated by spaces. Servers are tried in sequential order in case a server doesn't answer.
2. (Optional) Confine a policy to PATH and RESV messages:
```
 (global)  ip rsvp policy cops minimal  
```
  In some cases, confining the COPS servers to only PATH and RESV messages improves server performance and latency times for router requests. Other RSVP messages are not forwarded to the COPS servers for management.
3. (Optional) Set a COPS timeout:
```
 (global)  ip rsvp policy cops timeout   seconds  
```
  The PEP (router) retains policy information for seconds (1 to 10000 seconds; the default is 300 seconds, or 5 minutes) after the connection to a COPS server is lost.
4. (Optional) Report all RSVP decisions:
```
 (global)  ip rsvp policy cops report-all  
```
  By default, the PEP (router) sends only reports of RSVP configuration decisions to the PDP (COPS server). With this command, the router can also send reports of RSVP outsourcing decisions to the PDP if required by the COPS server software.

Using RSVP for QoS Signaling Example

RSVP is configured to direct all voice flows into a strict priority queue. Interface serial 1 is a full T1 with WFQ configured. RSVP is also configured on the interface, with a maximum total reserved bandwidth of 512 kbps and 30 kbps per flow. Burst policing is set to 400 percent, relaxing the policing of traffic bursts in the reserved flows. A sample proxy reservation is configured to 10.1.1.10 (UDP port 40) from 10.2.2.20 (UDP port 50). The next-hop router is 10.1.1.1 on interface serial 0. A fixed filter reservation is requested for guaranteed rate, using a bandwidth of 20 kbps and a burst size of 80 KB.

COPS for RSVP is also configured. The two COPS servers are 192.168.66.45 and 192.168.66.46. The router reports all configuration and outsourcing decisions to the COPS server.

  ip rsvp pq-profile voice-like   interface serial 1   description Full-T1 1.544 Mbps   ip address 192.168.211.1 255.255.255.0   fair-queue   ip rsvp bandwidth 512 30   ip rsvp burst policing 400   ip rsvp reservation 10.1.1.10 10.2.2.20 udp 40 50 10.1.1.1 serial 0 ff rate 20 80   ip rsvp policy cops servers 192.168.66.45 192.168.66.46   ip rsvp policy cops report-all