This chapter covers the Resource Reservation Protocol (RSVP) feature and its supported use on Frame Relay networks. RSVP is a signaling QoS feature that provides Call Admission Control to allow end systems or hosts located on either side of a network to establish a reserved-bandwidth path between them. In such a way, the quality of service (QoS) for real-time applications between the end systems is ensured.
This chapter begins with a general overview of the RSVP feature and subsequently focuses on RSVP support for Frame Relay. The focus of this chapter is to explain the major configuration tasks required for setting up an RSVP reserved-bandwidth path on a Frame Relay network. In addition, the Cisco IOS show commands for monitoring and maintaining the RSVP feature on a Frame Relay network are covered.
The topics and questions that this chapter addresses include the following:
General overview of RSVP
RSVP support for Frame Relay and the benefits of the RSVP feature on a Frame Relay network
Configuring RSVP support for Frame Relay on a Cisco router
Monitoring and maintaining RSVP support for Frame Relay on a Cisco router
After completing this chapter, readers will recognize the benefits of the RSVP feature and become familiar with its use on Frame Relay networks. Readers will become familiar with the Cisco configuration commands required to enable RSVP support for Frame Relay on a Cisco router. Readers will also recognize the Cisco IOS show commands for monitoring and maintaining RSVP for Frame Relay on a Cisco router.
This section addresses the characteristics of real-time interactive traffic and standard data traffic on the network and discusses the QoS requirements of each major type of traffic. This section also introduces the RSVP feature and describes how it allows end systems to request QoS guarantees from the network.
The emergence of voice traffic into traditional data networks has made it very common to see both voice and standard data traffic sharing the same network resources. However, both forms of traffic have different characteristics and distinctive requirements.
Standard data traffic is typically composed of traffic on the network that is not real-time sensitive in nature. A common example of standard data traffic is LAN-to-LAN file transfers. Data traffic typically relies on an underlying datagram service for transport and does not require consistent network latency to ensure good application performance.
During congestion of the transport network, the end hosts or application-level software provide the necessary flow controls to recover from packet loss or delay. By contrast, real-time and interactive traffic are composed of traffic that is intolerant to network latency, delay, packet loss, and jitters. Real-time traffic, such as voice and video information, requires consistent network latency in order to prevent signal delay or loss. The failure of consistent network latency can result in the distortion and quality degradation of the audio signal or video image. Similarly, interactive traffic, such as Telnet or SSH, requires a consistent degree of network delay to ensure an acceptable level of performance.
As such, the stringent requirements of real-time and interactive traffic are very different from those required by standard data traffic. RSVP provides a QoS signaling mechanism that allows end systems to request QoS guarantees from the network for real-time and interactive traffic.
The RSVP protocol is a QoS signaling mechanism that provides an IP service to allow end systems or hosts running real-time applications to establish a reserved bandwidth path between the sender and receiver. RSVP signals are exchanged across the network to allocate resources required by the applications from the pool of available bandwidth on the network. This prevents large data file transfers from impairing the available resources on the network and ensures a consistent latency for real-time traffic.
RSVP can work in conjunction with other QoS features that also reserve bandwidth, such as Class-Based Weighted Fair Queuing (CBWFQ) or IP Real-Time Protocol (RTP) priority. For instance, Weighted Fair Queuing (WFQ) can coexist with RSVP on the same interface. RSVP can use the WFQ queuing algorithm to ensure QoS for its data flows. When you enable multiple bandwidth reserving features, portions of the interface's available pool of bandwidth are assigned to each of these features. An internal interface-based or PVC-based bandwidth manager manages the pool of available bandwidth and prevents the aggregate amount of bandwidth reserved by these features from oversubscribing the interface or PVC. The available pool of bandwidth can be verified with the show queue type num privileged EXEC command, as shown in Example 22-1.
Example 22-1. Output of show queue type num Command
Router#show queue serial2/3
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 18572278
Queueing strategy: weighted fair
Output queue: 0/1000/64/18572268 (size/max total/threshold/drops)
Conversations 0/3/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 96 kilobits/sec
By default, the pool of bandwidth available to the interface is 75 percent of the total bandwidth of the interface. However, this pool of bandwidth available to the interface can be configured via the max-reserved-bandwidth interface configuration command. A configuration example is shown in Example 22-2.
Example 22-2. Changing the Available Bandwidth at the Interface with max-reserved-bandwidth Command
Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z Router(config)#interface serial2/3 Router(config-if)#max-reserved-bandwidth 100 Reservable bandwidth is being reduced Some existing reservations may be terminated. Router(config-if)# Router#show queue serial2/3 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 18572078 Queueing strategy: weighted fair Output queue: 0/1000/64/18572268 (size/max total/threshold/drops) Conversations 0/3/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 128 kilobits/sec
In Example 22-2, the total bandwidth available at the interface is 128 kbps. By default, 96 kbps (75 percent) is available for use by bandwidth-reserving QoS features configured at the interface. The max-reserved-bandwidth configuration command changes this to 100 percent, and all bandwidth available can now be reserved.
Unlike other bandwidth-reserving QoS features, such as CBWFQ or Low Latency Queuing (LLQ), RSVP does not automatically reserve any bandwidth when it is configured. When a traffic flow that meets the RSVP reservation criteria arrives at the router, RSVP attempts to reserve bandwidth out of the remaining pool of available bandwidth.
The RSVP Support for Frame Relay feature allows RSVP to be configured at the Frame Relay PVC level for better management of congestion, in conjunction with Frame Relay Traffic Shaping and its associated per-VC queuing features.
Common queuing features, such as WFQ, can be configured at the interface or VC level to manage congestion on a router. However, in a Frame Relay environment, the congestion point is most often at the PVC level instead of the interface level, largely because of the bandwidth limitations enforced by the committed information rate (CIR).
The CIR is the sending rate at which traffic traversing a Frame Relay network is guaranteed its delivery. When a Frame Relay network is oversubscribed, the CIR is exceeded and packets might be dropped as a result of congestion. As such, if packets are dropped from a real-time voice traffic flow, the packet loss can adversely affect the voice quality of the transmission. Therefore, the Frame Relay Traffic Shaping feature is configured on the Frame Relay interface to prevent the outbound traffic rate from exceeding the configured CIR value. For example, oversubscription can happen when the sum of the RSVP traffic and other traffic exceeds the CIR.
At the same time, per-VC queuing features, such as fancy queuing (PQ and CQ), WFQ, CBWFQ, and LLQ, can be used on the VC to provide QoS guarantees for the traffic. RSVP can coexist with other QoS features on the VC to reserve bandwidth and enforce QoS. When multiple bandwidth-reserving features, such as LLQ and CBWFQ, are concurrently configured, the bandwidth is assigned and reserved at the time of configuration. This bandwidth is deducted from the pool of available bandwidth managed by the bandwidth manager. However, if the configured bandwidth exceeds the pool of available bandwidth, the command is rejected. RSVP, on the other hand, performs bandwidth reservation only at the time of arrival of the RSVP traffic. RSVP attempts to reserve its required bandwidth from the bandwidth remaining in the pool.
RSVP provides several important benefits to its users, such as those listed here:
If the minimum CIR (MINCIR) is defined, RSVP can provide admission control based on the MINCIR value defined for the VC, instead of the amount of bandwidth available on the interface (which is, by default, 75 percent of the total bandwidth).
RSVP allows resources to be reserved at the Frame Relay VC level, which is the point of congestion, to enforce QoS for high-priority traffic.
RSVP supports both point-to-point and multipoint Frame Relay subinterfaces. This allows deployment of services such as Voice over IP (VoIP).
RSVP can coexist with CBWFQ and IP RTP priority bandwidth-reserving features. These features consult with the bandwidth manager during bandwidth reservation to prevent oversubscription.
RSVP, which is an IP service, can now be integrated into a Frame Relay environment to provide QoS enforcement on a per-VC basis.
The next section discusses the major configuration tasks involved in establishing a reserved-bandwidth path using the RSVP Support for Frame Relay feature.
This section explains the major configuration tasks involved in establishing a reserved-bandwidth path via the RSVP Support for Frame Relay feature between two users on a Frame Relay network.
To enable RSVP Support for Frame Relay, perform the configuration steps described below, beginning from the global configuration mode. Note that some configuration steps are listed as optional.
Enter the interface configuration mode of the Frame Relay interface and enable Frame Relay encapsulation with the encapsulation frame-relay interface configuration command. As required, create a point-to-point or multipoint subinterface under the main Frame Relay interface.
For a point-to-point subinterface, assign a Frame Relay DLCI to the subinterface with the frame-relay interface-dlci dlci interface configuration command. For a multipoint subinterface or the physical interface with multiple VCs, use the frame-relay map ip ip-address dlci [broadcast] command.
Enable Frame Relay Traffic Shaping with the frame-relay traffic-shaping interface configuration command on the physical interface. This enables FRTS and per-VC queuing for all PVCs and SVCs on the Frame Relay interface.
(optional) Enable the LMI type on the Frame Relay interface with the frame-relay lmi-type command. With Cisco IOS release 11.2, by default, the Frame Relay interface performs Local Management Interface (LMI) autosense.
Enable RSVP on the Frame Relay interface and subinterface with the ip rsvp bandwidth reserve-bandwidth-in-kbps largest-reserve-bandwidth-in-kbps interface configuration command. If subinterfaces are used, this command must be configured for the subinterfaces.
Configure Frame Relay Traffic Shaping parameters in a Frame Relay map-class with the map-class frame-relay map-class-name command. Within the Frame Relay map class, define the incoming or outgoing CIR for the Frame Relay PVC with the frame-relay cir {in|out} bps map-class configuration command.
(optional) Configure the Frame Relay MINCIR value in the Frame Relay map class with frame-relay mincir {in|out} bps map-class configuration command. When MINCIR is defined, RSVP can provide admission control based on the MINCIR value defined for the VC.
Configure WFQ in the Frame Relay map class with frame-relay fair-queue map-class configuration command. This turns on fair-queuing for the RSVP traffic flows on the PVC.
Configure FRF.12 Fragmentation for the Frame Relay PVC with the frame-relay fragment fragment-size map-class configuration command. This turns on FRF.12 class-based fragmentation on the Frame Relay PVC.
Associate the configured Frame Relay map class to the Frame Relay PVC with the frame-relay class class-name interface configuration command at the physical or subinterface level.
The examples in this section show a scenario in which the RSVP Support for Frame Relay feature is set up on the Frame Relay network depicted in Figure 22-1 with the configuration commands shown. The configurations on the routers are shown in Example 22-3.
Example 22-3. Configurations of Routers in Figure 22-1
! Router R1 <output omitted> interface FastEthernet0/0 ip address 10.0.0.1 255.255.255.0 ! interface Serial4/2 no ip address encapsulation frame-relay frame-relay traffic-shaping ip rsvp bandwidth 96 96 ! interface Serial4/2.102 point-to-point ip address 172.16.1.1 255.255.255.252 frame-relay interface-dlci 102 class rsvp ip rsvp bandwidth 64 64 ! interface Serial4/2.103 multipoint ip address 172.16.2.1 255.255.255.240 ip ospf network broadcast frame-relay class rsvp_p2mp frame-relay map ip 172.16.2.2 103 broadcast ip rsvp bandwidth 32 32 ! ! router ospf 1 network 10.0.0.0 0.0.0.255 area 0 network 172.16.1.0 0.0.0.3 area 0 network 172.16.2.0 0.0.0.15 area 1 ! map-class frame-relay rsvp frame-relay cir 256000 no frame-relay adaptive-shaping frame-relay fair-queue frame-relay fragment 200 ! map-class frame-relay rsvp_p2mp frame-relay cir 128000 no frame-relay adaptive-shaping frame-relay fair-queue frame-relay fragment 200 ! Router R2 <output omitted> interface FastEthernet0/0 ip address 20.0.0.2 255.255.255.0 ! interface Serial5/2 no ip address encapsulation frame-relay frame-relay traffic-shaping ip rsvp bandwidth 64 64 ! interface Serial5/2.201 point-to-point ip address 172.16.1.2 255.255.255.252 frame-relay interface-dlci 201 class rsvp ip rsvp bandwidth 64 64 ! router ospf 1 log-adjacency-changes network 20.0.0.0 0.0.0.255 area 0 network 172.16.1.0 0.0.0.3 area 0 !! ! map-class frame-relay rsvp frame-relay cir 256000 no frame-relay adaptive-shaping frame-relay fair-queue frame-relay fragment 200 ! Router R3 <output omitted> interface FastEthernet1/0 ip address 30.0.0.1 255.255.255.0 ! interface Serial1/2 no ip address encapsulation frame-relay frame-relay traffic-shaping ip rsvp bandwidth 32 32 ! interface Serial4/2.301 multipoint ip address 172.16.2.2 255.255.255.240 ip ospf network broadcast frame-relay class rsvp frame-relay map ip 172.16.2.1 301 broadcast ip rsvp bandwidth 32 32 ! ! router ospf 1 network 30.0.0.0 0.0.0.255 area 1 network 172.16.2.0 0.0.0.15 area 1 ! ! map-class frame-relay rsvp frame-relay cir 128000 no frame-relay adaptive-shaping frame-relay fair-queue frame-relay fragment 200
In the configurations shown in Example 22-3, RSVP is configured to set up reserved-bandwidth paths between the routers on the Frame Relay network. For instance, between router R1 and R2, up to 64 kbps of bandwidth can be reserved by end systems or hosts on either side.
The next section demonstrates the commands for monitoring and troubleshooting RSVP Support for Frame Relay.
Using the configured setup in Figure 22-1, this section looks at some commands that can be used to verify RSVP Support for Frame Relay. Because there are no explicit end systems available in this setup for setting up the reserved path, the Cisco IOS RSVP commands ip rsvp sender-host and ip rsvp reservation-host are used. These commands allow routers R1 and R2 to simulate RSVP PATH and RESV messages on the Frame Relay network and allow RSVP to be fully illustrated.
Example 22-4 shows the configuration commands needed to add on routers R1 and R2 for this purpose.
Example 22-4. Using ip rsvp sender-host and ip rsvp reservation-host to Routers R1 and R2
! Router R1 R1(config)# ip rsvp sender-host 20.0.0.2 10.0.0.1 udp 7000 7001 16 1 ! Router R2 R2(config)# ip rsvp reservation-host 20.0.0.2 10.0.0.1 UDP 7000 7001 FF LOAD 16 1
The ip rsvp sender-host command causes router R1 to simulate an IP RSVP sender-host located at 10.0.0.1, which is requesting an RSVP reserved bandwidth path of 16 kbps to 20.0.0.2 on UDP port numbers 7000 and 7001. The ip rsvp reservation-host command is configured on router R2 to accept and reserve a bandwidth of 16 bps on UDP port numbers 7000 and 7001.
The next examples illustrate several show commands that can be used to verify RSVP operation on the routers.
The show ip rsvp neighbor command can be used to verify the immediate RSVP neighbor, as shown in Example 22-5, which is executed on router R2.
Example 22-5. Output of show ip rsvp neighbor Command
R2#show ip rsvp neighbor Interfac Neighbor Encapsulation Se5/2.20 172.16.1.1 RSVP
The show ip rsvp interface command can be used to display the current active RSVP reservations on the routers' RSVP-enabled interfaces. An example is shown in Example 22-6.
Example 22-6. Output of show ip rsvp interface Command
R1#show ip rsvp interface interface allocated i/f max flow max pct UDP IP UDP_IP UDP M/C Se4/2 16K 96K 96K 16 0 0 0 0 Se4/2.102 16K 64K 64K 25 0 1 0 0 Se4/2.103 0M 32K 32K 0 0 0 0 0
In addition, the show ip rsvp installed and show ip rsvp installed detail commands can be used to display information about interfaces and their admitted reservations. Both commands are shown in Example 22-7 and Example 22-8.
Example 22-7. Output of show ip rsvp installed at Router R1
R1#show ip rsvp installed RSVP: Serial4/2.102 BPS To From Protoc DPort Sport 16K 20.0.0.2 10.0.0.2 UDP 7000 7001 RSVP: Serial4/2.103 has no installed reservations
Example 22-8. Output of show ip rsvp installed detail at Router R1
R1#show ip rsvp installed detail
RSVP: Serial4/2 has the following installed reservations
RSVP: Serial4/2.102 has the following installed reservations
RSVP Reservation. Destination is 20.0.0.2, Source is 10.0.0.2,
Protocol is UDP, Destination port is 7000, Source port is 7001
Reserved bandwidth: 16K bits/sec, Maximum burst: 1K bytes, Peak rate: 16K bits/sec
QoS provider for this flow:
WFQ on FR PVC dlci 102 on Se4/2: RESERVED queue 25. Weight: 6
Conversation supports 1 reservations
Data given reserved service: 0 packets (0M bytes)
Data given best-effort service: 0 packets (0 bytes)
Reserved traffic classified for 1805 seconds
Long-term average bitrate (bits/sec): 0M reserved, 0M best-effort
RSVP: Serial4/2.103 has no installed reservations
This chapter discussed the RSVP protocol, which is an IP service for end systems or hosts located on either side of a network to establish a reserved-bandwidth path between them. This chapter presented an overview of the RSVP protocol and described its use on a Frame Relay network, which is available with the RSVP Support for Frame Relay feature. This chapter showed the major Cisco IOS configuration tasks involved in configuring RSVP Support for Frame Relay on a Cisco router. It also explained the relevant Cisco IOS show commands for monitoring and maintaining RSVP Support for Frame Relay on a Cisco router.
Cisco IOS Release 12.1(5)T Documentation, RSVP Support for Frame Relay: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/rsvp_fr.htm