Table Of Contents
RSVP Refresh Reduction and Reliable Messaging
First Published: November 25, 2002Last Updated: February 19, 2007
The RSVP Refresh Reduction and Reliable Messaging feature includes refresh reduction, which improves the scalability, latency, and reliability of Resource Reservation Protocol (RSVP) signaling to enhance network performance and message delivery.
History for the RSVP Refresh Reduction and Reliable Messaging Feature
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Prerequisites for RSVP Refresh Reduction and Reliable Messaging
RSVP must be configured on two or more routers within the network before you can use the RSVP Refresh Reduction and Reliable Messaging feature.
Restrictions for RSVP Refresh Reduction and Reliable Messaging
Multicast flows are not supported for the reliable messages and summary refresh features.
Information About RSVP Refresh Reduction and Reliable Messaging
To configure the RSVP Refresh Reduction and Reliable Messaging feature, you should understand the following concepts:
Feature Design of RSVP Refresh Reduction and Reliable Messaging
RSVP is a network-control, soft-state protocol that enables Internet applications to obtain special qualities of service (QoS) for their data flows. As a soft-state protocol, RSVP requires that state be periodically refreshed. If refresh messages are not transmitted during a specified interval, RSVP state automatically times out and is deleted.
In a network that uses RSVP signaling, reliability and latency problems occur when an RSVP message is lost in transmission. A lost RSVP setup message can cause a delayed or failed reservation; a lost RSVP refresh message can cause a delay in the modification of a reservation or in a reservation timeout. Intolerant applications can fail as a result.
Reliability problems can also occur when there is excessive RSVP refresh message traffic caused by a large number of reservations in the network. Using summary refresh messages can improve reliability by significantly reducing the amount of RSVP refresh traffic.
Note RSVP packets consist of headers that identify the types of messages, and object fields that contain attributes and properties describing how to interpret and act on the content.
Types of Messages in RSVP Refresh Reduction and Reliable Messaging
The RSVP Refresh Reduction and Reliable Messaging feature (Figure 1) includes refresh reduction, which improves the scalability, latency, and reliability of RSVP signaling by introducing the following extensions:
•Reliable messages (MESSAGE_ID, MESSAGE_ID_ACK objects, and ACK messages)
•Bundle messages (reception and processing only)
•Summary refresh messages (MESSAGE_ID_LIST and MESSAGE_ID_NACK objects)
Figure 1 RSVP Refresh Reduction and Reliable Messaging
The reliable messages extension supports dependable message delivery among neighboring routers by implementing an acknowledgment mechanism that consists of a MESSAGE_ID object and a MESSAGE_ID_ACK object. The acknowledgments can be transmitted in an ACK message or piggybacked in other RSVP messages.
Each RSVP message contains one MESSAGE_ID object. If the ACK_Desired flag field is set within the MESSAGE_ID object, the receiver transmits a MESSAGE_ID_ACK object to the sender to confirm delivery.
A bundle message consists of several standard RSVP messages that are grouped into a single RSVP message.
A bundle message must contain at least one submessage. A submessage can be any RSVP message type other than another bundle message. Submessage types include Path, PathErr, Resv, ResvTear, ResvErr, ResvConf, and ACK.
Bundle messages are addressed directly to the RSVP neighbor. The bundle header immediately follows the IP header, and there is no intermediate transport header.
When a router receives a bundle message that is not addressed to one of its local IP addresses, it forwards the message.
Note Bundle messages can be received, but not sent.
Summary Refresh Messages
A summary refresh message supports the refreshing of RSVP state without the transmission of conventional Path and Resv messages. Therefore, the amount of information that must be transmitted and processed to maintain RSVP state synchronization is greatly reduced.
A summary refresh message carries a set of MESSAGE_ID objects that identify the Path and Resv states that should be refreshed. When an RSVP node receives a summary refresh message, the node matches each received MESSAGE_ID object with the locally installed Path or Resv state. If the MESSAGE_ID objects match the local state, the state is updated as if a standard RSVP refresh message were received. However, if a MESSAGE_ID object does not match the receiver's local state, the receiver notifies the sender of the summary refresh message by transmitting a MESSAGE_ID_NACK object.
When a summary refresh message is used to refresh the state of an RSVP session, the transmission of conventional refresh messages is suppressed. The summary refresh extension cannot be used for a Path or Resv message that contains changes to a previously advertised state. Also, only a state that was previously advertised in Path or Resv messages containing MESSAGE_ID objects can be refreshed by using a summary refresh message.
Benefits of RSVP Refresh Reduction and Reliable Messaging
Enhanced Network Performance
Refresh reduction reduces the volume of steady-state network traffic generated, the amount of CPU resources used, and the response time, thereby enhancing network performance.
Improved Message Delivery
The MESSAGE_ID and the MESSAGE_ID_ACK objects ensure the reliable delivery of messages and support rapid state refresh when a network problem occurs. For example, MESSAGE_ID_ACK objects are used to detect link transmission losses.
How to Configure RSVP Refresh Reduction and Reliable Messaging
This section contains the following procedures:
•Enabling RSVP on an Interface (required)
•Enabling RSVP Refresh Reduction (required)
Enabling RSVP on an Interface
Perform the following task to enable RSVP on an interface.
2. configure terminal
3. interface type number
4. ip rsvp bandwidth [interface-kbps [sub-pool]]
Enabling RSVP Refresh Reduction
Perform the following task to enable RSVP refresh reduction.
2. configure terminal
3. ip rsvp signalling refresh reduction
Verifying RSVP Refresh Reduction and Reliable Messaging
Perform the following task to verify that the RSVP Refresh Reduction and Reliable Messaging feature is functioning.
2. clear ip rsvp counters [confirm]
3. show ip rsvp
4. show ip rsvp counters [interface interface-unit | summary | neighbor]
5. show ip rsvp interface [interface-type interface-number] [detail]
6. show ip rsvp neighbor [detail]
Configuration Examples for RSVP Refresh Reduction and Reliable Messaging
This section provides the following configuration example:
RSVP Refresh Reduction and Reliable Messaging: Example
In the following example, RSVP refresh reduction is enabled:Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# interface Ethernet1Router(config-if)# ip rsvp bandwidth 7500 7500Router(config-if)# exitRouter(config)# ip rsvp signalling refresh reductionRouter(config)# end
The following example verifies that RSVP refresh reduction is enabled:Router# show running-configBuilding configuration...Current configuration : 1503 bytes!version 12.2no service single-slot-reload-enableservice timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice internal!hostname Router!no logging bufferedlogging rate-limit console 10 except errors!ip subnet-zeroip cef!ip multicast-routingno ip dhcp-client network-discoverylcp max-session-starts 0mpls traffic-eng tunnels!!interface Loopback0ip address 192.168.1.1 255.255.255.0ip rsvp bandwidth 1705033 1705033!interface Tunnel777no ip addressshutdown!interface Ethernet0ip address 192.168.0.195 255.0.0.0no ip mroute-cachemedia-type 10BaseT!interface Ethernet1ip address 192.168.5.2 255.255.255.0no ip redirectsno ip proxy-arpip pim dense-modeno ip mroute-cachemedia-type 10BaseTip rsvp bandwidth 7500 7500!interface Ethernet2ip address 192.168.1.2 255.255.255.0no ip redirectsno ip proxy-arpip pim dense-modeno ip mroute-cachemedia-type 10BaseTmpls traffic-eng tunnelsip rsvp bandwidth 7500 7500!interface Ethernet3ip address 192.168.2.2 255.255.255.0ip pim dense-modemedia-type 10BaseTmpls traffic-eng tunnels!!router eigrp 17network 192.168.0.0network 192.168.5.0network 192.168.12.0network 192.168.30.0auto-summaryno eigrp log-neighbor-changes!ip classlessno ip http serverip rsvp signalling refresh reduction!!!!line con 0exec-timeout 0 0line aux 0line vty 0 4logintransport input pad v120 telnet rlogin udptn!end
The following sections provide references related to the RSVP Refresh Reduction and Reliable Messaging feature.
Related Topic Document Title
RSVP commands: complete command syntax, command mode, defaults, usage guidelines, and examples
Cisco IOS Quality of Service Solutions Command Reference, Release 12.4T
Cisco IOS Quality of Service Solutions Command Reference, Release 12.2SB
Cisco IOS Quality of Service Solutions Command Reference, Release 12.2SR
QoS features including signaling, classification, and congestion management
This section documents modified commands only.
ip rsvp signalling rate-limit
To control the transmission rate for Resource Reservation Protocol (RSVP) messages sent to a neighboring router during a specified amount of time, use the ip rsvp signalling rate-limit command in global configuration mode. To disable this function, use the no form of this command.
Syntax for T Releases
ip rsvp signalling rate-limit [burst] [max-size] [period]
no ip rsvp signalling rate-limit
Syntax for 12.0S and 12.2S Releases
ip rsvp signalling rate-limit [burst] [limit] [max-size] [period]
no ip rsvp signalling rate-limit
This command is disabled by default; therefore, no messages are sent.
Use the ip rsvp signalling rate-limit command to prevent a burst of RSVP traffic engineering signaling messages from overflowing the input queue of a receiving router, which would cause the router to drop some messages. Dropped messages substantially delay the completion of signaling.
This command replaces the ip rsvp msg-pacing command.
The following command shows how every 10 ms 6 messages with a message queue of 500 bytes are sent to any neighboring router:Router(config)# ip rsvp signalling rate-limit 10 6 500
show ip rsvp signalling rate-limit
To display the Resource Reservation Protocol (RSVP) rate-limiting parameters, use the show ip rsvp signalling rate-limit command in user EXEC or privileged EXEC mode.
show ip rsvp signalling rate-limit
This command has no arguments or keywords.
The following command shows the rate-limiting parameters:Router# show ip rsvp signalling rate-limitRate Limiting:Max msgs per interval: 4Interval length (msec): 20Max queue size: 500Max msgs per second: 200
Table 1 describes the fields shown in the display.
flow—A stream of data traveling between two endpoints across a network (for example, from one LAN station to another). Multiple flows can be transmitted on a single circuit.
latency—The delay between the time a device receives a packet and the time that packet is forwarded out the destination port.
MPLS—Multiprotocol Label Switching. A method for directing packets primarily through Layer 2 switching rather than Layer 3 routing. In MPLS, packets are assigned short, fixed-length labels at the ingress to an MPLS cloud by using the concept of forwarding equivalence classes. Within the MPLS domain, the labels are used to make forwarding decisions mostly without recourse to the original packet headers. MPLS is formerly known as tag switching.
packet—A logical grouping of information that includes a header containing control information and (usually) user data. Packets most often refer to network layer units of data.
refresh message—A message that represents a previously advertised state, contains the same objects and information as a previously transmitted message, and is sent over the same path.
router—A network layer device that uses one or more metrics to determine the optimal path along which network traffic should be forwarded. Routers forward packets from one network to another based on network layer information.
RSVP—Resource Reservation Protocol. A protocol that supports the reservation of resources across an IP network. Applications running on IP end systems can use RSVP to indicate to other nodes the nature (bandwidth, jitter, maximum burst, and so on) of the packet streams they want to receive.
soft state—The status that RSVP maintains in routers and end nodes so that they can be updated by certain RSVP messages. The soft state characteristic permits an RSVP network to support dynamic group membership changes and adapt to changes in routing.
subpool—A division of bandwidth such that no one tunnel dominates.
tunnel—A secure communication path between two peers, such as routers.
Note See Internetworking Terms and Acronyms for terms not included in this glossary.
CCVP, the Cisco Logo, and the Cisco Square Bridge logo are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, Follow Me Browsing, FormShare, GigaDrive, GigaStack, HomeLink, Internet Quotient, IOS, iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networking Academy, Network Registrar, Packet, PIX, ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet, StackWise, The Fastest Way to Increase Your Internet Quotient, and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0612R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2002, 2004, 2006, 2007 Cisco Systems, Inc. All rights reserved.