When a receiver generates an Rspec for a Resv message to be sent for a Guaranteed Service reservation request it must include a Slack Term, S(ms) as well as the amount of bandwidth, R to be installed in each router along the path. S represents the amount by which the end-to-end delay bound will be below the end-to-end delay required by the application assuming each router along the path reserves R bandwidth according to the Guaranteed Service fluid approximation. Inclusion of a non-zero Slack Term offers the individual routers greater flexibility in making their local reservations. In certain circumstances this greater flexibility could increase the chance of an end-to- end reservation being successful. Some routers have deadline based schedulers that decouple rate and delay guarantees. Such a scheduler may sometimes be unable to meet it's deadline requirement for Guaranteed Service in which case it might still be able to accept the reservation providing the Slack Term is at least as large as the excess delay. The excess delay would then be subtracted from the Slack Term before unicasting the Resv message to the previous hop upstream. Similarly a rate based scheduler might be able to admit a reservation request by reserving less than the requested bandwidth and unicasting the reduced reservation request to a previous hop upstream provided it could extract enough slack. Any router using available slack to reduce it's reservation must conform to the rules in equation (3) to ensure that the end-to-end delay bound remains satisfied. where:
Suppose the token bucket rate (as defined earlier) of the data to be sent is 1.5Mb/s and the receiver has calculated from the Tspec and Adspec parameters in received Path messages that the desired end-to-end delay can be achieved by a reservation of (R=2.5Mb/s, S=0) which is then requested in Figure 2.7. However because R3 only has 2Mb/s of unused bandwidth and there is no slack available the reservation is denied. In Figure 2.8 the reservation is increased to R=3Mb/s and the amount by which such a reservation would be within the required delay bound is put in the Slack Term(S>0). R5 and R6 reserve the requested 3Mb/s. R3 can only reserve a value of 2Mb/s which if used as the new reservation value in the propagated Resv message will cause an increase in the end to end delay bound. R3 can calculate this increase, di and if it is less than the value of the Slack Term, S1 in the received Resv message then the request can be accepted and a reservation of 2Mb/s installed in R3. R3 will then set the Rspec in the Resv message to (R=2Mb/s, S2=S1-di) before unicasting it to the next hop upstream which results in R2 and R1 also reserving 2Mb/s.The end-to-end delay bound of the reserved path is now no greater than for a reservation of 2.5Mb/s in every router if that were possible.