How RSVP Works

RSVP is based on signaling messages that traverse the network, allocating resources along the way. RSVP is receiver-initiated, because sender initiation does not scale well to large, multicast scenarios in which there are heterogeneous receivers. In multicast scenarios, the application server sends out only one PATH message to multiple receiving computers, thus conserving network bandwidth. In the case of multicast traffic flows, RESV messages from multiple receivers are merged by taking the maximum values requested.

RSVP is a soft-state protocol, meaning that the reservation must be periodically refreshed or it expires. The reservation information, or state, is cached in each hop tasked with managing resources. If the network's routing protocol alters the data path, RSVP attempts to reinstall the reservation state along the new route. When refresh messages are not received, reservations time out and are dropped, releasing bandwidth. The sender refreshes PATH messages, and the receiver refreshes RESV messages. Because RSVP sends its messages as best-effort IP datagrams with no reliability enhancement, some messages might be lost, but the periodic transmission of refresh messages by hosts and routers compensates for the occasional loss of an RSVP message. To ensure receipt of refresh messages, the network traffic control mechanism must be statically configured to grant some minimal bandwidth for RSVP messages to protect them from congestion losses. At any time, the sender, receiver, or other network device providing QoS, can terminate the session by sending a PATH-TEAR or RESV-TEAR message.

Policy is checked by the RSVP-aware routers and switches along the path. Devices might reject resource requests based on the results of these policy checks. If the reservation is rejected due to lack of resources, the requested application is immediately informed that the network cannot currently support that amount and type of bandwidth or the requested service level. The application determines whether to wait and repeat the request later or to send the data immediately using best-effort delivery. QoS-aware applications, such as those controlling multicast transmissions, generally begin sending immediately on a best-effort basis, which is then upgraded to QoS when the reservation is accepted.

Figure 9.4 is a basic example of how RSVP messages flow between a sender and receiver, through the admission control host and intermediary hops.

Enlarge figure

Figure 9.4 How RSVP Works

1. The multimedia server sends a PATH message requesting priority bandwidth to the QoS ACS host (a Windows 2000 server running the QoS Admission Control Service). The message is ultimately headed to the receiver of the data. In the case of multicast (multiple receivers), the PATH message is sent to the multicast address and received by all hosts that are members of the multicast group. Note that it is RSVP messages that are passed to the QoS ACS, not the data packets ultimately transmitted from sender to receiver.

   Until confirmation of a reservation is received with a RESV message, data for the connection is sent at a best-effort service level from the sending host. The best-effort service type instructs the RSVP SP to use the application or service's QoS parameters as guidelines for service quality requests, and makes reasonable effort to maintain the requested level of service. It does not make any guarantees that requested QoS parameters are implemented or enforced.

2. If a QoS ACS server is present in the local subnet, the PATH message is routed via the QoS ACS server. In this example, a QoS ACS host approves the request and forwards it to the receiver (client). The PATH message travels through the network to the receiver, along the data path determined by the network routing protocol.
3. A PATH state is maintained at each hop. Each PATH state contains a copy of the PATH message and the IP address of the previous hop.
4. When a PATH message arrives at the intended receiver, the receiving host (if interested in receiving the data) responds by sending a RESV message that reserves the resources along the same network path traveled by the PATH message.

   Here, the receiver creates a RESV message, indicating that it wants to receive the data from the multimedia server.

5. The RESV message follows the reverse data path back to the multimedia server, using the addressing information stored in the PATH state at each hop, to determine the route.
6. As the RESV message propagates back toward the sender, each hop determines whether or not to accept the proposed reservation and commit resources. If an affirmative decision is made, physical bandwidth is allocated and RESV messages are propagated to the next hop on the path from source to destination. If a hop is unable to commit, it sends a RESV-ERR message to the receiving host.

   When the RESV message arrives at the router hop, the reservation is granted and physical bandwidth is allocated. The hop maintains the reservation (RESV) state and notifies the traffic control service that data is to be sent.

   The reservation is considered to be installed when the first RESV message arrives at the sender in response to the PATH message for the corresponding session. The reservation remains until the session is terminated by either host or a network device. As long as the reservation is in place, the sender is able to transmit prioritized data.

7. The multimedia server and the client periodically send PATH and RESV messages during the data transmission, to keep the reservation state in place.

Every hop might not be RSVP-capable, especially when data crosses the Internet. Both RSVP and non-RSVP routers forward PATH messages towards the destination address using their local unicast or multicast routing table. This means that the routing of PATH messages is unaffected by non-RSVP routers in the path. Although a group of non-RSVP routers cannot perform a resource analysis and grant a reservation, if such a cloud has sufficient bandwidth capacity, it may still provide some level of useful real-time service.

RSVP dynamically adapts to new routes during the flow of a data stream. When a route changes (for example, when a router or switch can no longer commit to the requested resources), the next PATH message initializes the path state on the new route, and future RESV messages establish a reservation state for the new route.

You might need to enable special filtering for the RSVP messages to pass through security gateways, firewalls, or proxy servers without generating a PATH-ERR message. Windows 2000 IP Security (IPSec) does not interfere with the interpretation of RSVP messages.

© 1985-2000 Microsoft Corporation. All rights reserved.