RSVP

The Resource Reservation Protocol (RSVP) is a resource reservation setup protocol that is used by both network hosts and routers. Hosts use RSVP to request a specific quality of service (QoS) from the network for particular application flows. Routers use RSVP to deliver QoS requests to all routers along the data path . RSVP also can maintain and refresh states for a requested QoS application flow.

RSVP treats an application flow as a simplex connection. That is, the QoS request travels only in one directionfrom the sender to the receiver. RSVP is a transport layer protocol that uses IP as its network layer. However, RSVP does not transport application flows. Rather, it is more of an Internet control protocol, similar to ICMP, IGMP, IS-IS, or OSPF. RSVP runs as a separate software process in the JUNOS Internet software and is not in the packet forwarding path.

RSVP is not a routing protocol, but rather is designed to operate with current and future unicast and multicast routing protocols. The routing protocols are responsible for choosing the routes to use to forward packets, and RSVP consults local routing tables to obtain routes. RSVP is responsible only for ensuring the QoS of packets traveling along a data path.

The receiver in an application flow is responsible for requesting the preferred QoS from the sender. To do this, the receiver issues an RSVP QoS request on behalf of the local application. The request propagates to all routers in reverse direction of the data paths toward the sender. In this process, RSVP requests might be merged, resulting in a protocol that scales well when there are a large number of receivers.

Because the number of receivers in an application flow is likely to change, and the flow of delivery paths might change during the life of an application flow, RSVP takes a soft-state approach in its design, creating and removing the protocol states in routers and hosts incrementally over time. RSVP sends periodic refresh messages to maintain its state and to recover from occasional lost messages. In the absence of refresh messages, the RSVP states automatically time out and are deleted.

The JUNOS implementation of RSVP supports RSVP Version 1. The software includes support for all mandatory objects and RSVP message types, and supports message integrity and node authentications through the integrity object.

The primary purpose of the JUNOS RSVP software is to support dynamic signaling within MPLS LSPs. Supporting resource reservations over the Internet is only a secondary purpose of the JUNOS implementation. Because of this, the RSVP software does not support IP multicasting sessions or traffic control (it cannot make resource reservations for real-time video or audio sessions).

With regard to the protocol mechanism, packet processing, and RSVP objects supported, the JUNOS implementation of the software is interoperable with other RSVP implementations .

Table 11.3 lists the RSVP standards and protocol extensions supported by the JUNOS software.

Table 11.3. RSVP Standards Supported by JUNOS Software

Standard	Title
RFC 2205	Resource Reservation Protocol (RSVP), Version 1, Functional Specification
RFC 2209	Resource Reservation Protocol (RSVP), Version 1, Message Processing Rules
RFC 2210	The Use of RSVP with IETF Integrated Services
RFC 2211	Specification of the Controlled-Load Network Element Service
RFC 2215	General Characterization Parameters for Integrated Service Network Elements
RFC 2216	Network Element Service Specification Template
RFC 2747	RSVP Cryptographic Authentication
Internet draft draft-ietf-mpls-rsvp-lsp-tunnel-05.txt	Extensions to RSVP for LSP Tunnels
Internet draft draft-ietf-rsvp-refresh-reduct-05.txt	RSVP Refresh Reduction Extensions

RSVP creates independent sessions to handle each data flow. A session is identified by a combination of the destination address, an optional destination port, and a protocol. Within a session, there can be one or more senders. Each sender is identified by a combination of its source address and source port. An out-of- band mechanism, such as a session announcement protocol or human communication, is used to communicate the session identifier to all senders and receivers.

A typical RSVP session involves the following sequence of events:

1. A potential sender starts sending RSVP path messages to the session address.

2. A receiver, wanting to join the session, registers itself if necessary. For example, a receiver in a multicast application would register itself with IGMP.

3. The receiver receives the path messages.

4. The receiver sends appropriate resv messages toward the sender. These messages carry a flow descriptor, which is used by routers along the path to make reservations in their link-layer media.

5. The sender receives the resv message, and then it starts sending application data.

This sequence of events is not necessarily strictly synchronized. For example, receivers can register themselves before receiving path messages from the sender, and application data can flow before the sender receives resv messages. Application data that is delivered before the actual reservation contained in the resv message typically is treated as best effort, nonreal-time traffic with no QoS guarantee.

RSVP uses several types of messages to establish and remove paths for data flows, to establish and remove reservation information, to confirm the establishment of reservations, and to report errors as specified in Table 11.4.

A reservation request includes options for specifying the reservation style. The reservation styles define how reservations for different senders within the same session are treated and how senders are selected. Two options specify how reservations for different senders within the same session are treated:

• Distinct reservationEach receiver establishes its own reservation with each upstream sender.

• Shared reservationAll receivers make a single reservation that is shared among many senders.

Table 11.4. RSVP Message Types

Message Type	Description
Path	Transmitted downstream by each sender host, along the routes provided by the unicast and multicast routing protocols. Path messages follow the exact paths of application data, creating path states in the routers along the way, thus enabling routers to learn the previous hop and next -hop node for the session. Path messages are sent periodically to refresh path states. The refresh interval is controlled by a variable called the refresh time, which is the periodical refresh timer expressed in seconds. A path state times out if a router does not receive a specified number of consecutive path messages. This number is specified by a variable called keep- multiplier . Path states are kept for (( keep-multiplier + 0.5) * 1.5 * refresh-time ) seconds.
Resv	Each receiver host sends reservation request (resv) messages upstream toward senders and sender applications. Resv messages must follow exactly the reverse path of path messages. Resv messages create and maintain a reservation state in each router along the way. Resv messages are sent periodically to refresh reservation states. The refresh interval is controlled by the same refresh time variable, and reservation states are kept for (( keep-multiplier + 0.5) * 1.5 * refresh-time ) seconds.
PathTear	PathTear messages remove (tear down) path states as well as dependent reservation states in any routers along a path. PathTear messages follow the same path as path messages. A PathTear typically is initiated by a sender application or by a router when its path state times out. PathTear messages are not required, but they enhance network performance because they release network resources quickly. If PathTear messages are lost or not generated, path states eventually time out when they are not refreshed, and then the resources associated with the path are released.
ResvTear	ResvTear messages remove reservation states along a path. These messages travel up-stream toward senders of the session. In a sense, ResvTear messages are the reverse of resv messages. ResvTear messages typically are initiated by a receiver application or by a router when its reservation state times out. ResvTear messages are not required, but they enhance network performance because they release network resources quickly. If ResvTear messages are lost or not generated, reservation states eventually time out when they are not refreshed, and then the resources associated with the reservation are released.
PathErr	When path errors occur (usually because of parameter problems in a path message), the router sends a unicast PathErr message to the sender that issued the path message. Using PathErr messages is advisory; these messages do not alter any path state along the way.
ResvErr	When a reservation request fails, a ResvErr error message is delivered to all the receivers involved. Using ResvErr messages is advisory; these messages do not alter any reservation state along the way.
ResvConfirm	Receivers can request confirmation of a reservation request, and this confirmation is sent with ResvConfirm message. Because of the complex RSVP flow-merging rules, a con-firmation message does not necessarily provide end-to-end confirmation of the entire path. Therefore, ResvConfirm messages are an indication of potential success only, with no guarantees . RSVP is a resource reservation setup protocol that is designed to interact with integrated services on the Internet.

Two options specify how senders are selected:

• Explicit senderList all selected senders.

• Wildcard senderSelect all senders, which then participate in the session.

The following reservation styles, formed by a combination of these four options, currently are defined:

• Fixed filter (FF)This reservation style consists of distinct reservations among explicit senders. Examples of applications that use fixed-filter style reservations are video applications and unicast applications, which both require flows that have a separate reservation for each sender.

• Wildcard filter (WF)This reservation style consists of shared reservations among wildcard senders. This type of reservation reserves bandwidth for any and all senders, and propagates upstream toward all senders, automatically extending to new senders as they appear. A sample application for wildcard filter reservations is an audio application in which each sender transmits a distinct data stream. Typically, only a few senders are transmitting at any one time. Such a flow does not require a separate reservation for each sender; a single reservation is sufficient.

• Shared explicit (SE)This reservation style consists of shared reservations among explicit senders. This type of reservation reserves bandwidth for a limited group of senders. A sample application is an audio application similar to that described for wildcard filter reservations.

Enabling RSVP

To enable RSVP, include the following statements. To enable RSVP on all interfaces, specify all for interface- name :

 [edit]  protocols {   rsvp {     interface  interface-name  ;   } } 

Configuring RSVP Aggregation

The resource requirementsprocessing, bandwidth, and memoryfor running RSVP on a router increase proportionally with the number of sessions. Handling large numbers of refresh messages transmitted between RSVP neighbors is crucial for supporting large numbers of sessions. Path and Resv messages typically represent the majority of refreshes.

If topology failures occur, every node adjacent to the failure might notify all affected sender and receiver nodes. These notification messages are either tear or error messages, and they typically represent a flood that ripples out from the original failure point.

Aggregation provides a mechanism for reducing message flooding and network overload. It also enhances the efficiency and reliability in delivering RSVP tear or error messages. Note that RSVP aggregation is called bundle message in the Internet draft RSVP Refresh Reduction Extensions.

By default, aggregation is disabled on all interfaces. For interoperability with other routers, you might need to keep aggregation disabled. However, we recommend that you enable aggregation between Juniper Networks routers to improve scalability. If you have several thousand MPLS LSPs, you must enable aggregation to ensure stable operation. To enable aggregation, include the aggregate statement:

 [edit protocols rsvp interface  interface-name  ]  aggregate; 

Configuring the RSVP Hello Interval

RSVP hello packets enable RSVP nodes to detect the loss of a neighboring node's RSVP state information. (Losses typically occur when the neighboring router restarts or the link fails.) In standard RSVP, such detection occurs as a consequence of RSVP's soft-state model. However, detection typically requires several minutes to time out the soft state. RSVP hello packets detect the neighboring node's state changes much more quickly, usually within 10 to 20 seconds.

Between hello-capable neighbors, hello packets are sent unicast toward each other. A loss of (2 * keep-multiplier +1) consecutive hello packets causes the neighbor's state to go down, and all RSVP sessions to and from that neighbor are declared to be down.

JUNOS RSVP hello packets are optional and are backward compatible with RSVP implementations that do not support hello packets. For neighbors that do not support hello packets, RSVP uses the soft-state timeout for loss detection.

If all neighboring nodes support hello packets, you can reduce the refresh overhead (by increasing the value set in the refresh-time statement) without adversely affecting the node or link failure detection time. Also, the network can scale to a larger number of sessions because the refresh operations consume less CPU and bandwidth.

For information about setting the refresh overhead, see "Configuring RSVP Timers," on page 591.

By default, RSVP sends hello packets every 3 seconds. To modify how often RSVP sends hello packets, include the hello-interval statement:

 [edit protocols rsvp interface  interface-name  ]  hello-interval  seconds  ; 

Configuring RSVP Authentication

All RSVP protocol exchanges can be authenticated to guarantee that only trusted neighbors participate in setting up reservations. RSVP authentication uses an HMAC-MD5 message-based digest. This scheme produces a message digest based on a secret authentication key and the message contents. (The message contents also include a sequence number.) The computed digest is transmitted with RSVP messages. After you have configured authentication, all received and transmitted RSVP messages with all neighbors are authenticated on this interface.

MD5 authentication also provides protection against forgery and message modification. However, it does not provide confidentiality because all messages are sent in clear text, and it does not prevent replay attacks.

By default, authentication is disabled. To enable authentication, configure a key on each interface by including the authentication-key statement:

 [edit protocols rsvp interface interface-name]  authentication-key key; 

Reserving Bandwidth on an Interface

For each interface on which RSVP is enabled, by default, RSVP permits all the interface's bandwidth (100 percent) to be used for RSVP reservations.

Oversubscription on an interface occurs when the aggregate demand of all RSVP sessions is allowed to exceed physical capacity of the link. You can use oversubscription to take advantage of the statistical nature of traffic patterns and to permit higher utilization of links. In particular, you can use oversubscription in places where peak utilizations of traffic do not coincide in time.

Undersubscription on an interface occurs when the total demand of all RSVP sessions is always less than the physical capacity of the link. You can use undersubscription to bound utilization of links and reduce congestion.

You can modify the link bandwidth used for RSVP reservations, either decreasing it below 100 percent or oversubscribing the interface. To do this, include the subscription statement:

 [edit protocols rsvp interface  interface-name  ]  subscription  percentage  ; 

percentage is the percentage of the interface's bandwidth that RSVP allows to be used for reservations. It can be a value from 0 through 65,000 percent. If you specify a value greater than 100, you are oversubscribing the interface.

You can use the subscription factor to shut down new RSVP sessions on a per-interface basis. If you set the percentage to 0, no new sessions (including those with zero bandwidth requirements) are permitted on the interface. Existing RSVP sessions are not affected by changing the subscription factor. To clear an existing session, issue the clear rsvp session command.

Configuring RSVP Timers

RSVP uses two interrelated timing parameters:

• Refresh timeControls the interval between the successive generation of refresh messages. Refresh messages include Path and Resv messages. Refresh messages are sent periodically so that reservation states in neighboring nodes do not time out. Each node chooses a value for the refresh timer independently. Each Path and Resv message carries the refresh timer value, and the receiving node extracts this value from the messages.

• Keep multiplierA locally configured small integer in the range 1 through 255.

To determine the lifetime of a reservation state, use the following formula:

  lifetime  = (  keep-multiplier  + 0.5) * 1.5 *  refresh-time  

In the worst case, ( keep-multiplier 1) successive refresh messages must be lost before a reservation state is deleted.

By default, the refresh timer value is 30 seconds. To modify this value, include the refresh-time statement:

 [edit protocols rsvp]  refresh-time  seconds  ; 

The default value of the keep multiplier is 3. To modify this value, include the keep-multiplier statement:

 [edit protocols rsvp]  keep-multiplier  number;  

Preempting RSVP Sessions

Whenever bandwidth is insufficient to handle all RSVP sessions, you can control the preemption of RSVP sessions. By default, an RSVP session is preempted only by a new higher-priority session.

To always preempt a session when the bandwidth is insufficient, include the preemption aggressive statement:

 [edit protocols rsvp]  preemption aggressive; 

To disable RSVP session preemption, include the preemption disabled statement:

 [edit protocols rsvp]  preemption disabled; 

To return to the default (that is, preempt a session only for a new higher-priority session), include the preemption normal statement:

 [edit protocols rsvp]  preemption normal; 

Tracing RSVP Protocol Traffic

To trace RSVP protocol traffic, include the traceoptions statement at the [edit protocols rsvp] hierarchy level:

 [edit protocols rsvp]  traceoptions {   file  filename  <replace> <size  size  > <files  number  > <no-stamp>      <(world-readable  no-world-readable)>;   flag  flag  <  flag-modifier  > <disable>; } 

For more information about tracing and global tracing options, see the JUNOS technical documentation.

You can specify the following RSVP-specific flags in the RSVP traceoptions statement:

• all All tracing operations

• error All detected error conditions

• packets All RSVP messages

• path Path messages

• pathtear PathTear messages

• resv Resv messages

• resvtear ResvTear messages

• route Routing table changes in RSVP

• state Session state transitions