Confirming RSVP Reservations

The RSVP_RESERVE_INFO object enables a receiving application to be notified of the outcome of an RSVP reservation request. RSVP reservation confirmation is achieved by setting the ConfirmRequest member of the RSVP_RESERVE_INFO object to a nonzero value. This setting is necessary because RSVP network nodes are not required to automatically generate RSVP CONFIRMATION messages, per the RSVP specification.

Until the presence of a reservation is discerned (senders learn about the presence of a reservation by listening for a WSA_QOS_RECEIVERS event), data for the connection will be treated as BEST_EFFORT traffic, which provides a compelling reason for network programmers to enable RSVP confirmation immediately after a WSAConnect, WSAJoinLeaf function call, or use of the SIO_SET_QOS IOCTL.

Senders can query whether their application is allowed to send by using SIO_CHK_QOS. If the binary result of ALLOWED_TO_SEND is false (indicating that the application is not allowed to send) and the application chooses to send anyway, the traffic is treated as BEST_EFFORT. Once the RESV message arrives at the sender (triggering the RSVP confirmation), the RSVP SP on the sending host modifies traffic control service to match the service type in the RESV message, and the traffic is treated as per the service type.

RSVP confirmation requests are only useful for receiving applications.