One Path With Advertising(OPWA), refers to the reservation model for the case where the sender includes an Adspec in its Path messages to enable the receiver to determine the end-to-end service that will result from a given reservation request. If the sender omits the Adspec from its Path messages then the reservation model is referred to simply as One Pass in which case there is no easy way for the receiver to determine the resulting end-to-end service. The objective of this aspect of the RSVP reservation model, both for One Pass and One Pass with Advertising is to minimise the latency (in terms of number of handshakes between senders and recipients) before a reservation is in place. Here we consider the OPWA case. Let us assume that the sender omits the Controlled-Load Service data fragment from the Adspec thereby restricting each receiver to reservation of Guaranteed Service only. Upon receiving Path messages the receiver extracts the following parameters from the Sender Tspec: r, b, p, m. In addition the following are extracted from the Adspec: Minimum Path Latency, Ctot, Dtot, PathMTU, Path Bandwidth. In a way similar to incremental route calculation, OPWA permits incremental accumulation of the delay for a reservation. The required bound on end-to-end queuing delay, Qdelreq is now calculated by subtracting the Minimum Path Latency from the value of end-to-end delay required by the receiver’s application. Typically, the receiver would then perform an initial check by evaluating equation (2) for R equal to the peak rate, p. If the resultant delay was greater than or equal to Qdelreq then equation (2) would be used for calculation of the minimum value of R necessary to satisfy Qdelreq. Otherwise equation (1) would be used for this purpose. This minimum value of R is then obtained by inserting Qdelreq into either equation (1) or (2) along with M(given by PathMTU), Ctot, Dtot, r, b, p, as appropriate. If the obtained value of R exceeds the Path Bandwidth value as obtained from the Adspec of the received Path message then it must be reduced accordingly. The receiver can now create a reservation specification, Rspec comprising firstly the calculated value, R of bandwidth to be reserved in each router, and secondly a Slack Term that is initialised to zero In some cases even with R set to the minimum permissible value of r the resultant end-to-end queuing delay as given by eqs (1) and (2) will still be less than Qdelreq in which case the difference can be represented in a non-zero slack term. In addition there are other scenarios explained in section 2.9.6 in which the slack term may not be initialised to zero. The Rspec can now be used in the creation of a Resv message which also includes the following:
In practice there are certain scenarios in which a ResvConf message might be received by a receiver only for the request to be rejected shortly afterwards.
The Resv message is now sent to the previous hop upstream as obtained from the stored path state. Upon reaching the next upstream router the Resv messages can be merged with other Resv messages arriving on the same interface according to certain rules as described later to obtain an effective Flowspec and Filterspec. The following action is then taken.
The effective Flowspec is passed to the traffic control module within the router which applies both admission control and policy control to determine whether the reservation can be accepted. Admission control is concerned solely about whether enough capacity exists to satisfy the request while policy control also takes into account any additional factors that need to be considered (e.g. certain policies may limit a users reserved bandwidth even if spare bandwidth exists). If the reservation attempt is denied then any existing reservations are left unaltered and the router must send a ResvErr message downstream. If the reservation request is accepted then reservation state is set up in accordance with the effective Flowspec and Filterspec. In accepting the request it may be permissible to alter the Rspec associated with the reservation from (Rin, Sin) to (Rout, Sout) in accordance with the rules described earlier
The resultant reservation may then be merged with other reservations in accordance with the rules in section 2.9 to obtain a new Resv message that is sent to the next router upstream, the address of which is obtained from the stored path state.