RSVP Messages
RSVP messages identify what application and user is requesting QoS, the service level requested from the network, the quantity of bandwidth requested, and the end nodes (source and destination addresses). Based on administrator-defined admission control policies and network resource availability, the QoS request is either approved or denied by the host performing admission control duties. If the request is approved, QoS mechanisms are invoked to classify and schedule the traffic flow, logically allocate bandwidth, and notify the requesting host of the approval so that it might begin sending priority traffic. Until this occurs, the transmission is treated as standard traffic by the network.
Information encased in RSVP messages is per data flow (a flow is a data stream between two end nodes). RSVP messages carry the following information:
Traffic classification information . The source and destination IP addresses and ports identify the traffic flow (filterspec).
Traffic parameters . Expressed using Intserv's token-bucket model, these identify the data rate of the flow (flowspec).
Service level information . From the Intserv-defined service types, conveys the flow requirements for the RSVP request.
Policy information : Allows the system to verify that the requester is entitled to the resources and to the amount of resources being requested.
RSVP uses the message types listed in Table 9.1 to establish and maintain reserved bandwidth on a subnet.
Table 9.1 RSVP Message Types
Message Type |
Function |
|---|---|
PATH |
Carries the data flow information from the sender to the receiver. The PATH message marks out the path that requested data must take when returning to the receiver. PATH messages contain bandwidth requirements, traffic characteristics, and addressing information, such as the source and destination IP addresses. PATH messages are issued for a particular session, which is determined by the destination address and port of the data flow. It is necessary to have a unique session identifier, since a sender can offer multiple traffic flows and receive RESV messages from multiple receivers. The unique session identifier enables the ability to associate the correct PATH messages with the correct RESV messages. |
RESV |
Carries the reservation request from the receiver. RESV messages contain the actual bandwidth reservation, the service level requested, and the source IP address. This is the message that causes the reservation to become active. |
PATH-ERR |
Indicates an error in response to the PATH message. |
RESV-ERR |
Indicates an error in response to the RESV message. |
PATH-TEAR |
Removes the PATH state along the route. |
RESV-TEAR |
Removes the reservation along the route. |
RESV -CONF |
Optional. If a receiver requests a confirmation, the sender transmits this message to the receiver. |
When an application on an end node requests QoS, RSVP constructs PATH messages that express the QoS requirements of the sending application, in abstract, Layer 3 terms that each network device can interpret. The receiving-end node sends back an RESV message that establishes the reservation along the data path. For the reservation to be truly guaranteed, each hop must grant the reservation and physically allocate the requested bandwidth. By granting the reservation, the hop commits to providing adequate resources. Devices might reject resource requests based on lack of policy rights by the requesting user or lack of network resources at the time of the request.
If the reservation is rejected, the application receives an immediate response that the subnet cannot currently support the amount or type of bandwidth, or the requested service level. It is up to the application to determine whether to resend the data and accept a best-effort service level or wait and repeat the bandwidth request at a later time. Note that the end nodes must periodically refresh the reservation by sending PATH and RESV messages every few seconds (generally this is set to 30 second intervals).