RSVP is currently incompatible with frame-relay traffic shaping If RSVP is enabled for even a single subinterface, frame-relay traffic shaping cannot be used on the entire interface A

workaround for this is to use generic traffic shaping.

Scalability

The scalability of RSVP is suspect, and to date no large-scale implementations exist. Given this, care should be taken to control the size and scope of RSVP's deployment. Given the stringent delay requirements of voice traffic, it is doubtful whether these limits will ever be reached, but care should be taken so that RSVP routers are not subject to an excessive amount of reservations.

Security

To prevent reservations from any unwanted sources, the ip rsvp neighbor command should be used to limit the neighbors who are allowed to make reservations. Without this control, any RSVP-capable device may reserve the bandwidth which was planned for voice traffic.

Voice-Specific Reservation Issues

When configuring RSVP for a VoIP dial peer, the dial-peer construct, discussed in a later chapter, makes bandwidth reservations based upon the

Page 87 amount of data which it is providing to the network. This calculation includes the voice traffic plus the IP, UDP, and RTP headers and the frame rate using the following formula:

bps = packet_size + ip/udp/rtp header size * 50/s

Using the numbers available to dial peer, the equation becomes bps = (20 bytes * 8 bits/byte) + (40 bytes * 8 bits/byte) * 50 packets/s

which is equal to 24,000 bits/s. Even though G.729 compression brings the payload size down to 8 kbps, the IP overhead is 16 kbps.

However, as discussed earlier, compressed RTP can shrink the 40-byte header to 4—5 bytes. Using CRTP, the equation becomes

bps = (20 bytes * 8 bits/byte) + (5 bytes * 8 bits/byte) * 50 packets/s

which is equal to 10,000 bits/s. Given that all RTP headers cannot be compressed, the value used for planning is usually 11 kbps.

The disparity between the amount of bandwidth the dial peer is reserving and the amount which is actually sent can falsely limit the number of reservations that can be made for VoIP traffic.

Reservation Workaround

A workaround to this problem is to falsely set the interface bandwidth to a number that is greater than the actual bandwidth. An example of this problem and its resolution are presented as

follows.

EXAMPLE

A 56-kbps link configured to allow up to 48 kbps for RSVP would allow only two VoIP sessions. In reality, those sessions would only consume 22 kbps of bandwidth and unfairly prevent a third session from being granted a reservation over the link.

Three sessions will consume 33 kbps, so we know that the link is capable of supporting them without consuming the entire link's bandwidth. However, three RSVP requests from dial peers at 24 kbps would require 72 kbps to be allocated to RSVP for the connections to be accepted. By default, RSVP permits only 75 percent of the link's bandwidth to be reserved so the link's bandwidth would have to set 100 kbps to accept all three sessions.

This workaround can have serious effects on other aspects of the

Page 88 network. Specifically, routing protocols such as OSPF and EIGRP use the link's bandwidth to determine optimal routing paths. In simple hub-and-spoke configurations, this may not be an issue, but in more elaborate configurations, improper routing may occur. If this workaround is to be used, the routing topology should be studied to ensure that the modification will not adversely affect operation. Also, if CRTP is disabled for any reason, the link will be oversubscribed.

Non-RSVP Intermediary Routers

RSVP can be implemented within a network where all routers do not support RSVP or all links are not configured for RSVP, but the obvious caveat is that bandwidth allocation and congestion cannot be controlled over those links. Simply put, if the non-RSVP routers and links are fast and lightly loaded, then there's a good chance the reservation will be met. If, however, the non-RSVP links are slow and/or heavily loaded, then there's a good chance that the reservation will not be met.

Configuring RSVP

bandwidth and a single-reservation maximum bandwidth. The interface command for enabling RSVP is

ip rsvp bandwidth [interface-kbps] [single-flow-kbps]

where interface-kbps represents the maximum bandwidth which can be reserved on the interface and single-flow-kbps represents the maximum amount any one reservation will be granted. By default, interface-kbps is set to 75 percent of the configured bandwidth for the interface and single-flow-kbps is set to interface-kbps. If the defaults are used, it is important that the interface bandwidth be accurately configured using the interface

command: bandwidth. On serial interfaces, the bandwidth defaults to T1 speeds (1536 kbps) so it must be manually configured for subrate interface speeds.

EXAMPLE

An example configuration for a Cisco 3600 connected to a fractional T1 link running at 1024 kbps is presented below. ! interface Serial0/0 description Fractional T1 to NY Page 89 ip address 10.3.1.2 255.255.0.0 ip rsvp bandwidth 768 768 bandwidth 1024 ipx network 100 fair-queue 64 256 1000 !

NOTE: The router automatically fills in the values for interface-kbps and single-flow-kbps. The fair-queue command is automatically configured by the router to provide up 1000 reservable (RSVP) conversations and limit dynamic conversations (other routed traffic) to 256. These numbers can be modified using the same command, if required.

To enable RSVP and WRED (discussed later), the interface command random-detect must be used. For example,

! interface Serial0 description Fractional T1 to NY ip address 10.3.1.2 255.255.0.0 ip rsvp bandwidth 768 768 bandwidth 1024 random-detect !

EXAMPLE

The following example includes the relevant RSVP configurations for the involved routers. The network comprises a Cisco 3600 voice-enabled router communicating with an AS5300

voice-enabled access server over a T1 link service by the 3600 and a Cisco 4500 at the AS5300 site. The diagram in Figure 4-8 helps clarify the design.

As a review of RSVP operation, Figures 4-9 and 4-10 indicate the setup as messages are communicated. They depict the signaling used when a call is initiated from the 3600. First, the 3600 sends out the RSVP path message to the AS5300 including the bandwidth

requirements in the message. The intermediary 4500 stores the IP address of the 3600's serial port in memory as part of the path state. It then forwards the RSVP path message to the AS5300. The AS5300 receives the RSVP path, interprets the information, and issues an RSVP reservation request using an RSVP resv message. The intermediary 4500 processes the reservation request, sets up the appropriate filter and bandwidth reservation on serial 0, and forwards the

Page 90

Figure 4-8

Figure 4-9

The C3600 sends an RSVP message.

RSVP resv message to the 3600. The 3600 processes the reservation request and sets up the appropriate filter and bandwidth reservation on serial 0/0.

Figure 4-9 represents a unidirectional reservation from the C3600 to the AS5300. A second reservation will be made in the opposite direction

Page 91

Figure 4-10

A second reservation is made in the opposite direction.

so that bandwidth may be reserved from the AS5300 to C3600. (See Figure 4-10.) The relevant configurations are provided below:

Router C3600

!

description T1 link to Headquarters ip address 172.16.1.2 255.255.255.0 ip rsvp bandwidth 1152 1152 bandwidth 1536 fair-queue 64 256 1000 ! Voice-configuration supporting RSVP ! Router C4500 ! interface Ethernet0

description Ethernet link to AS5300 ip address 192.168.2.1 255.255.255.0 !

interface Serial0

description T1 link to Branch Office ip address 192.168.1.1 255.255.255.0 ip rsvp bandwidth 1152 1152 bandwidth 1536 fair-queue 64 256 1000 ! Page 92

Access Server AS5300

!

interface Ethernet0

description Ethernet link to C4500 ip address 192.168.2.2 255.255.255.0 !

Voice-configuration supporting RSVP

!

NOTES:

• Details for configuring RSVP-enabled voice traffic will be covered in the chapter on dial peers.