RSVP is an IETF Internet standard (RFC 2205) network layer signaling protocol for allowing an application to dynamically reserve network bandwidth. RSVP enables applications to request a specific QoS for a data flow. Hosts and routers use RSVP to deliver QoS requests to the routers along the paths of the data stream and to maintain router and host state to provide the requested service, usually bandwidth and latency. RSVP uses a mean data rate, the largest amount of data that the router will keep in queue, and minimum QoS to determine bandwidth reservation.
WFQ or WRED act as the workhorse for RSVP, setting up the packet classification and scheduling required for the reserved flows. RSVP is used by the following:
RSVP treats data flow from receiver to sender as logically independent from the flow from sender to receiver. Accordingly, a reservation for data from sender to receiver is independent from a reservation from receiver to sender. Because RSVP establishes a reservation for simplex flows, reservations for traffic can be made from any or both directions. RSVP is a hop-by-hop QoS signaling protocol. This means that RSVP messages are transmitted from one node to another through all RSVP-aware nodes along the data path. Figure 5-5 shows the reservation setup mechanism.
The following steps show the event sequence for RSVP resource reservation in a unicast scenario:
1. | The transmitting sender host usually knows the characteristics of the traffic it generates, such as data rate and the deviation from data rate. As it transmits data, the sender's RSVP module periodically sends RSVP path messages, which do the following:
- Describe the traffic generated by the sender - Create a state on each intermediate RSVP-aware node along the data path
Path messages are sent with the destination address of the receiver host and are routed as data sent to that host.
|
2. | Path messages create a path state in each router that is traversed. Through this path setup mechanism, all devices along the path become aware of their adjacent RSVP nodes for data flow.
|
3. | When a local RSVP module notifies a receiver host application that an RSVP path message has been received, the receiver host application decides whether resources should be reserved.
|
4. | When a decision is made to request network resource reservation, the host application sends a request to the local RSVP module to assist in the reservation setup.
|
5. | The RSVP protocol then carries the request as Resv messages to all nodes along the reverse data path to the data source. The reservation is made on a hop-by-hop basis, and each intermediate node checks for sufficient resources and decides whether the request can be granted. If the reservation is successful, a Resv state is created, and the reservation request is forwarded to the previous hop in the data path.
|
6. | The receiver can request a notification about the reservation status. In this case, when the sender receives the Resv message from the receiver, it sends the receiver a Resv confirmation message.
|
7. | If the receiver sends any data, it will start sending path messages to the sender. In this case, Steps 1 to 6 are repeated with the receiver acting as the sender and the sender acting as the receiver.
|
