Configuring RSVP

• 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.

• Real-time traffic (that is, voice or video information) experiences problems when operating over datagram services. Since real-time traffic sends an almost constant flow of information, the network "pipes" must be consistent. Some guarantee must be provided that service between real-time hosts will not vary. Routers operating on a FIFO basis risk unrecoverable disruption of the real-time information that is being transmitted.

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.

• Jitter--A slight time or phase movement in a transmission signal can introduce loss of synchronization or other errors.

• Insufficient bandwidth--Voice calls use a digital signal level 0 (DS0 at 64 kbps); video conferencing uses T1/E1 (1.544 Mbs or 2.048 Mbps); and higher-fidelity video uses much more.

• Delay variations--If the wait time between when signal elements are sent and when they arrive varies, the real-time traffic will no longer be synchronized and may fail.

• Information loss--When signal elements drop or arrive too late lost audio causes distortions with noise or crackle sounds. The lost video causes image blurring, distortions, or blackouts.

• RSVP Flow--This is a stream that operates "multidestination simplex," since data travels across it in only one direction (from the origin to the targets). Flows travel from a set of senders to a set of receivers. The flows can be merged or left unmerged, and the method of merging them varies according to the attributes of application using the flow.

• WFQ Conversation--This is the traffic for a single transport layer session or network layer flow that crosses a given interface. This conversation is called from the source and destination address, protocol type, port number, or other attributes in the relevant communications layer.

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 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).

Plan for RSVP before entering the details needed as RSVP configuration parameters.

• Serial line interfaces--PPP, HDLC, LAPB, HSSI, and similar serial line interfaces are well modeled by RSVP. The device can, therefore, make guarantees on these interfaces. With NBMA interfaces, these are also the most in need of reservations.

• Multiaccess LANs--These data links are not modeled well by RSVP interfaces, because the LAN itself represents a queuing system that is not under the control of the device making the guarantees. The device guarantees what load it will offer, but cannot guarantee what competing loads or timings of loads that neighboring LAN systems will offer. The network administrator can use admission controls to control how much traffic is placed on the LAN. The network administrator, however, should focus on the use of admission in network design in order to use RSVP effectively.

• Public X.25 networks--It is not clear that rate or delay reservations can be usefully made on public X.25 networks.

You must use a specialized configuration on Frame Relay and ATM networks, as discussed in the next sections.

• Reservations are made for an interface or subinterface. If subinterfaces contain more than one DLC, the bandwidth required and the bandwidth reserved may differ. Therefore, RSVP subinterfaces of frame relay circuits must contain exactly one DLC to operate correctly.

• In addition, Frame Relay DLCs have rates (CIR) and burst controls (Bc and Be) that may not be reflected in the configuration, and may differ markedly from the interface speed (either adding up to exceed it or being significantly smaller). Therefore, the ip rsvp bandwidth interface configuration command must be entered for both the interface and the subinterface. Both bandwidths are used as admission criteria.

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.

• When ATM is configured, it most likely uses a usable bit rate (UBR) or an available bit rate (ABR) virtual channel (VC) connecting individual routers. With these classes of service, the ATM network makes a "best effort" to meet the traffic's bit-rate requirements, and assumes that the end-stations are responsible for information that does not get through the network.

• This ATM service has the capability of opening separate channels for reserved traffic having the necessary characteristics. RSVP should open these VCs and adjust the cache to make effective use of the VC for this purpose.

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.