Guaranteed reservations are more complex than controlled load because guaranteed flow provides a way to reserve a specified maximum delay through the network, as well as a specified data rate. Guaranteed service does not control the average or minimum packet delay. Guaranteed service also does not control jitter, the difference between minimum and maximum packet delays.
The guaranteed flow model of the network assumes that there are two sources of delay in the network, the delay (D) that is independent of rate of flow, and the delay (C) that is proportional to rate of flow. Delay for a rate r would be C*r+D in an ideal situation. In practice, the RSVP-enabled network elements provide an upper bound for their contribution to C and D, and a lower bound for D. The lower bound for C is 0. The receiver chooses a reservation that takes these bounds into consideration.
The pathLatency field of the adspec for guaranteed service is an estimate of the minimum delay through the network for that type of service. It can be estimated from many diverse factors such as speed of light through fiber cables or minimum path length of routing code. Each RSVP-enabled node adds its own estimate of this value to the adspec.
The delay that is based on the data rate can include many factors, such as time to queue a packet, and maximum time to wait for the current packet to be sent before the next one can be sent from an interface.
When a path message arrives at the receiver, the guaranteed flow adspec will contain Ctot and Dtot, which are accumulations of the C and D delay factors on the path through the network. The terms Csum and Dsum are used by intermediate nodes along with the slack term that the guaranteed flow will provide. These terms are used by nodes that will "reshape" the data flow to make it conform to the flow parameters.
These are the formula variables and their sources, for determining the Guaranteed flowspec.
┌───────────────────────────────────────────────────────────────────┐ │Var Spec Spec Field Description │ ├───────────────────────────────────────────────────────────────────┤ │Bmin Guar_adspec_t pathBW Minimum path bandwidth │ │ (IP packet bytes per │ │ second) │ ├───────────────────────────────────────────────────────────────────┤ │MTU Guar_adspec_t composedMTU Composed path MTU │ │ (bytes) │ ├───────────────────────────────────────────────────────────────────┤ │Ctot Guar_adspec_t Ctot Total rate-dependent │ │ error (bytes) │ ├───────────────────────────────────────────────────────────────────┤ │Dtot Guar_adspec_t Dtot Total rate-independent │ │ error (microseconds) │ ├───────────────────────────────────────────────────────────────────┤ │r IS_Tspec_t IS_Tspec_r Token bucket rate (IP │ │ packet bytes per second)│ ├───────────────────────────────────────────────────────────────────┤ │b IS_Tspec_t IS_Tspec_b Token bucket depth │ │ (bytes) │ ├───────────────────────────────────────────────────────────────────┤ │p IS_Tspec_t IS_Tspec_p Peak data rate (IP │ │ packet bytes per second)│ ├───────────────────────────────────────────────────────────────────┤ │m IS_Tspec_t IS_Tspec_m Minimum Policed Unit │ │ (bytes) │ ├───────────────────────────────────────────────────────────────────┤ │M IS_Tspec_t IS_Tspec_M Maximum packet size │ │ (bytes) │ ├───────────────────────────────────────────────────────────────────┤ │R Guar_Rspec_t Guar_Rspec_R Guaranteed rate (IP │ │ packet bytes per second)│ ├───────────────────────────────────────────────────────────────────┤ │S Guar_Rspec_t Guar_Rspec_S Slack term │ │ (microseconds) │ └───────────────────────────────────────────────────────────────────┘
Values for r, b, p, m, M, R, and S are to be computed for the guaranteed reservation. Assume that the reservation r, b, p, and m are chosen based on the original tspec values in the path message. If Bmin is greater than r or p, they should be increased at least to Bmin. Assume that the reservation M is set to a reasonable value for the application that is not greater than MTU. Assume that the minimum delay is not greater than the maximum that the application can tolerate. Note that all computation described below should be floating point , especially the division by 1000000 that converts between microseconds and seconds.
If r <= p <= R then the upper bound on end-to-end requested delay (Dreq) in seconds is:
Dreq = (M+Ctot)/R + Dtot/1000000
If r <= R < p then the upper bound on Dreq in seconds is
Dreq = [(b-M)/R*(p-R)/(p-r)] + (M+Ctot)/R + Dtot/1000000
The higher the value of R is, the lower Dreq will be. The application will choose an R value that is sufficiently high that the maximum delay is sufficient for what the sender and receiver need to do. Note that studies have shown that packets will often arrive much more quickly than the maximum delay, and therefore the application must be prepared to buffer them.
If the peak rate p is unknown or unspecified, it should be set to infinity. Infinity is represented in IEEE floating point with an exponent of all one bits (255), and a sign and mantissa of all zero bits. In that case the upper bound on end-to-end delay in seconds simplifies to:
Dreq = b/R + Ctot/R + Dtot/1000000
The slack term S is the difference between the requested maximum delay and the desired delay, and must be a non-negative number. A typical desired delay is when R is set to r, in the ideal fluid model of flow. The delay in that model is
Dideal = b/r + Ctot/r + Dtot/1000000
The slack term can then be:
S = Dreq - Dideal.
If the application chooses an S greater than zero, then RSVP-enabled nodes on the path can use it and the Csum and Dsum values to adjust their local reservations to lower the amount of resources allocated to the flow.
Note that a guaranteed reservation may have its values R and S adjusted by intervening nodes, so that the reservation seen by the sender in the reservation message may be different from what the receiver provided with rapi_reserve() call.
For more information, refer to Internet RFC 1633, Integrated Services in the Internet Architecture: an Overview, and Internet Draft draft-ietf-intserv-ctrl-load-svc-07.