Resv message processing

The processing of Resv messages is more complex. They are the messages responsible for reservations, so the RSVP process not only has to record an incoming Resv message in the reservation state, but it may also merge the new reservation with a reservation already in place.

First of all, the RSVP process has to find the corresponding path state entry. If no corresponding session has been found in the path state or if the entry found does not match the reservation made because of a port or style incompatibility, a Resv Error message will be sent back to the originator of the message.

The information about the reservation in a Resv message is contained in a series of flow descriptors which are located at the end of the message. The flow descriptor format depends on the reservation style. A WF reservation is shared among all the senders, so a flow descriptor is a single Flowspec object in this case. When the FF style is used, a reservation is made for each sender, so each flow descriptor is a list of (Flowspec, Filter_Spec) pairs. The SE style is used to make a reservation for a set of senders, therefore a flow descriptor is composed of a Flowspec object followed by a list of Filter_Spec objects.

Each flow descriptor is examined separately in order to create or update reservations. Then the reservations done or modified are handed to the Traffic Control module.

The processing of a Resv message may result in the merging of the new reservation with a reservation already in place. If that happens and if the result of the merging is an increase of the QoS originally requested, a Resv message containing the new information is sent upstream.

If a Resv_Confirm object was present in the message and if the reservation requested was satisfied, the agent should send a Confirmation message back to the sender (see section ).