-
Network Protocols Configuration Guide, Part 1
-
IP Overview
-
Configuring IP Addressing
-
Configuring IP Services
-
Configuring RSVP
-
Configuring On-Demand Routing
-
Configuring RIP
-
Configuring IGRP
-
Configuring OSPF
-
Configuring IP Enhanced IGRP
-
Configuring Integrated IS-IS
-
Configuring BGP
-
Configuring IP Routing Protocol-Independent Features
-
Configuring IP Multicast Routing
-
Table Of Contents
Planning for RSVP Configuration
RSVP Implementation Considerations
Considerations for a Frame Relay Internetwork
Considerations for an ATM Internetwork
Enter Senders in the RSVP Database
Enter Receivers in the RSVP Database
Control Which RSVP Neighbor Can Offer a Reservation
Configuring RSVP
This chapter describes how to configure Resource Reservation Protocol (RSVP), which is an IP service. For a complete description of the RSVP commands in this chapter, refer to the "RSVP Commands" chapter of the Network Protocols Command Reference, Part 1. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
RSVP allows end systems to request Quality of Service (QOS) guarantees from the network. The need for network resource reservations differs for data traffic versus for real-time traffic, as follows:
•
Data traffic seldom needs reserved bandwidth since internetworks provide datagram services for data traffic. This asynchronous packet switching may not need guarantees of service quality. Routers can operate in a first-in, first out (FIFO) manner for data traffic packets. End-to-end controls between data traffic senders and receivers help ensure adequate transmission of bursts of information.
•
Data applications (with little need for resource guarantees) frequently demand relatively lower bandwidth than real-time traffic. The almost constant high bit-rate demands of a video conference application, and the bursty low bit-rate demands of an interactive data application, share available network resources.
RSVP prevents the demands of real-time traffic from impairing the bandwidth resources necessary for bursty data traffic. To do this, the routers sort and prioritize packets much like a statistical time division multiplexor would sort and prioritize several signal sources that shares a single channel.
RSVP mechanisms enable real-time traffic to reserve resources necessary for consistent latency. A video conferencing application can use settings in the router to propagate a request for a path with the required bandwidth and delay for video conferencing destinations. RSVP will check and repeat reservations at regular intervals. By this process, RSVP can adjust and alter the path between RSVP end systems to recover from router changes.
Real-time traffic (unlike data traffic) requires a guaranteed network consistency. Without consistent QOS, real-time traffic faces the following problems:
•
•
•
•
RSVP works in conjunction with weighted fair queuing (WFQ) or random early detection (RED). This conjunction of reservation setting with packet queuing uses two key concepts: end-to-end flows with RSVP and router-to-router conversations with WFQ.
•
•
RSVP allows for hosts to send packets to a subset of all hosts (multicasting). RSVP assumes that resource reservation applies primarily to multicast applications (such as video conferencing). Although the primary target for RSVP is multimedia traffic, a clear interest exists for the reservation of bandwidth for unicast traffic (such as NFS and virtual private network management). A unicast transmission involves a host sending packets to a single host.
RSVP Reservation Types
Two types of multicast flows are a flow that originates from exactly one sender (called a distinct reservation), and a flow that originates from one or more senders (called a shared reservation). RSVP describes these reservations as having certain algorithmic attributes.
Distinct Reservation
An example of a distinct reservation is a video application, in which each sender emits a distinct data stream that requires admission and management in a queue. Such a flow, therefore, requires a separate reservation per sender on each transmission facility it crosses (such as Ethernet, an HDLC line, a Frame Relay DLCI, or an ATM virtual channel). RSVP refers to this distinct reservation as explicit, and installs it using a Fixed Filter style of reservation.
Use of RSVP for unicast applications is generally a degenerate case of a distinct flow.
Shared Reservation
An example of a shared reservation is an audio application, in which each sender also emits a distinct data stream that requires admission and management in a queue. However, because of the nature of the application, a limited number of senders are transmitting data at any given time. Such a flow, therefore, does not require a separate reservation per sender. Instead, a single reservation that can be applied to any sender within a set, as needed.
RSVP installs a shared reservation using a Wild Card or Shared Explicit style of reservation, with the difference between the two being determined by the scope of application (which is either wild or explicit).
•
•
Planning for RSVP Configuration
You must plan carefully to successfully configure and use RSVP on your network. At a minimum, RSVP must reflect your assessment of bandwidth needs on router interfaces. Consider the following questions as you plan for RSVP configuration:
•
•
•
Plan for RSVP before entering the details needed as RSVP configuration parameters.
RSVP Implementation Considerations
You should be aware of RSVP implementation considerations as you design your reservation system. RSVP does not model all data links likely to be present on the internetwork. RSVP models an interface as having a queuing system that completely determines the mix of traffic on the interface; bandwidth or delay characteristics are only deterministic to the extent that this model holds. Unfortunately, data links are often imperfectly modeled this way. Use the following guidelines:
•
•
•
You must use a specialized configuration on Frame Relay and ATM networks, as discussed in the next sections.
Considerations for a Frame Relay Internetwork
The following RSVP implementation considerations apply as you design your reservation system for a Frame Relay internetwork:
•
•
For example, suppose that a Frame Relay interface runs at a T1 rate (1.544 Mbps) and supports several DLCs to remote offices served by 128 and 56 kbps lines. One must configure the amount of the total interface (75 percent of which being 1.158 Mbps) and the amount of each receiving interface (75 percent of which would be 96 and 42 kbps, respectively) that may be reserved. Admission succeeds if and only if enough bandwidth is available on the DLC (the subinterface) and on the aggregate interface.
Considerations for an ATM Internetwork
The following RSVP implementation considerations apply as you design your reservation system for an ATM internetwork:
•
•
RSVP Task List
After you have planned your RSVP configuration, enter the Cisco IOS commands that implement your configuration plan. The following sections discuss how to configure RSVP. You must enable RSVP on an interface in order to use it; the other tasks are optional.
•
•
•
Enable RSVP
By default, RSPV is disabled so that it is backward compatible with systems that do not implement RSVP. To enable RSVP on an interface, perform the following task in global configuration mode:
Enable RSVP for IP on an interface.
ip rsvp bandwidth [interface-kbps] [single-flow-kbps]
This command starts RSVP and sets the bandwidth and single-flow limits. The default maximum bandwidth is up to 75 percent of the bandwidth available on the interface. By default, the amount reservable by a flow can be up to the entire reservable bandwidth.
On subinterfaces, this applies the more restrictive of the available bandwidths of the physical interface and the subinterface. For example, a Frame Relay interface might have a T1 connector nominally capable of 1.536 Mbps, and 64 subinterfaces on 128 kbps circuits (64K CIR), with 1200 and 100 kbps, respectively.
Reservations on individual circuits that do not exceed 100 kbps normally succeed. If, however, reservations have been made on other circuits adding up to 1.2 Mbps, and a reservation is made on a subinterface which itself has enough remaining bandwidth, it will still be refused because the physical interface lacks supporting bandwidth.
Enter Senders in the RSVP Database
You can configure the router to behave as though it is periodically receiving an RSVP PATH message from the sender or previous hop routes containing the indicated attributes. To enter senders in the RSVP database, perform the following task in global configuration mode:
Enter Receivers in the RSVP Database
You can configure the router to behave as though it is continuously receiving an RSVP RESV message from the originator containing the indicated attributes. To enter receivers in the RSVP database, perform the following task in global configuration mode:
Enter Multicast Addresses
If RSVP neighbors are discovered to be using UDP encapsulation, the router will automatically generate UDP-encapsulated messages for consumption by the neighbors.
To enter multicast addresses, perform the following task in global configuration mode:
Enter any multicast addresses necessary if you use UDP.
ip rsvp udp-multicast [multicast-address]
However, in some cases, a host will not originate such a message until it has first heard from the router, which it can only do via UDP. You must instruct the router to generate UDP-encapsulated RSVP multicasts whenever it generates an IP-encapsulated multicast.
Control Which RSVP Neighbor Can Offer a Reservation
By default, any RSVP neighbor may offer a reservation. To control which RSVP neighbors can offer a reservation, perform the following task in global configuration mode:
When this command is configured, only neighbors conforming to the access list are accepted. The access list is applied to the IP header.
Monitor RSVP
After you configure the RSVP reservations that reflect your network resource policy, you can verify the resulting RSVP operations. To do so, perform the following tasks in EXEC mode: