The sender tspec contains a structure with five fields that define the flow. The two receiver flowspecs also contain this structure.
typedef struct {
float32_t IS_Tspec_r; /* Token bucket rate (IP packet bytes/sec) */
float32_t IS_Tspec_b; /* Token bucket depth (bytes) */
float32_t IS_Tspec_p; /* Peak data rate (IP packet bytes/sec) */
u_int32_t IS_Tspec_m; /* Min Policed Unit (bytes) */
u_int32_t IS_Tspec_M; /* Max packet size (bytes) */
} IS_Tspec_t;
The token bucket rate (r) is in bytes of IP datagrams per second. That is, the packets must include the IP packet header (20 bytes) and either the UDP header (8 bytes) or the TCP header (20 bytes), as well as the data in the packet, when computing packet sizes. The valid value of r may range from 1 byte per second to 40 terabytes per second. The bucket depth (b) may range from 1 byte to 250 gigabytes.
The maximum packet size (M) should be no bigger than the maximum transmission unit (MTU) of the path between sender and receiver. The value of m must be no bigger than M.
In a tspec the sender indicates, for any arbitrary time period of T seconds, that the amount of data sent in that period will not be greater than r*T+b. When computing this, any packet that is less than the minimum policed unit (m) in size should be counted as m bytes.
The token bucket model is a way of viewing the transmission of data. The sender has a stream of data that comes from some source, and the sender expects to send it using RSVP. The sender may need to send at a specified rate dictated by the data stream source, for example an audio or video data stream. The receiver may need to output the data in a timely fashion after receiving it as well. The token bucket rate is the rate at which the sender will send. Imagine bytes (tokens) filling the token bucket. When enough accumulate so that the above formula is not violated, a packet is built and sent. The bucket is reduced by the amount that was sent.
The peak data rate (p) is mainly used in guaranteed flowspecs. It can be set the same as r, for controlled load flowspecs. In guaranteed flowspecs, it is required that for any time period T, that the amount of data sent in that period cannot exceed M+p*T.
A Guaranteed flowspec has a tspec and an rspec. An rspec is shown below.
typedef struct {
float32_t Guar_Rspec_R; /* Guaranteed Rate (IP packet bytes/sec) */
u_int32_t Guar_Rspec_S; /* Slack term (microseconds) */
} Guar_Rspec_t;
The guaranteed rate (R) and slack term (S) are computed by the receiver based upon the values in the adspec in the path message. They are explained in a later section.
A sender and receiver in an RSVP session negotiate reasonable values of packet size, and so forth, by using information in the path and reservation messages. Typically, a sender specifies the largest packet it is willing to send. This value will be in the path message tspec. When the path message is seen by a receiver, the packet size (in the adspec) will be the maximum that can be handled by all the RSVP-enabled nodes that the message passed through. (If one or more nodes was not RSVP-enabled, then that fact is also indicated in the adspec. In that case, the reservation that is made should be considered unreliable.) Once the receiver makes a reservation, if the reservation is subsequently merged with other reservations then a similar process can happen as the reservation message goes toward the sender. Thus the sender can see what the maximum packet size should be for the packets to be sent reliably to all receivers. If a packet is larger than that size, it will be sent by "best effort" technique rather than according to the reservation that was made.
A similar process occurs for delay through the network, so that the receiver has an estimate of what sort of service it can expect and request.