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
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:
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:
Table 11.4. RSVP Message Types
Two options specify how senders are selected:
The following reservation styles, formed by a combination of these four options, currently are defined:
Enabling RSVPTo 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 AggregationThe 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 IntervalRSVP 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.
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 AuthenticationAll 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 InterfaceFor 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 TimersRSVP uses two interrelated timing parameters:
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 SessionsWhenever 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 TrafficTo 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>; }
You can specify the following RSVP-specific flags in the RSVP traceoptions statement:
|