Specification of Guaranteed Quality of Service
Extracted elements (28)
End-to-end delay consists of a fixed component (path latency, determined by routing) and a queueing component (controlled by guaranteed service). The queueing delay is primarily a function of token bucket size b and reserved rate R, both under application control, so applications can estimate and tune their delay a priori.
No buffer specification is included in the RSpec because the network element is expected to derive required buffer space from the TSpec token bucket and peak rate, the RSpec rate and slack, and the upstream Ctot/Dtot or Csum/Dsum values, combined with internal traffic management knowledge.
Non-conforming datagrams are relegated to best-effort rather than dropped to prevent a denial-of-service scenario: a new receiver requesting a reservation with an inadequate TSpec could otherwise cause the policer to discard traffic, cutting off existing best-effort receivers of the same flow.
The C error term is divided by rate R in the delay bound formula because its effect (e.g., ATM cell serialization delay) scales with transmission rate; rate-independent delays SHOULD be incorporated into D instead. This distinction ensures accurate delay budgeting across heterogeneous elements.
RSVP shared reservations using guaranteed service have a known open problem: the RSpec rate R is set to achieve a delay bound (not merely to match sender traffic), so shared reservations can fail at a link whenever available bandwidth is less than R, even if the link has adequate bandwidth for the actual number of senders.
The token bucket (r, b) and peak rate (p) used by guaranteed service map directly to ATM Q.2931 QoS parameters for Variable Bit Rate traffic: Sustained Cell Rate, Burst Size, and Peak Cell Rate. ATM implementations must also account for per-cell and per-datagram overhead when scaling token bucket parameters for VC setup.
A network element MUST provide the buffer space b+Csum+(Dsum*r) at each reshaping point to ensure that conforming traffic is not lost. The reshaping token bucket MUST start with a full bucket of tokens.
A service request for an existing flow with a new TSpec and/or RSpec SHOULD be treated as a new invocation requiring re-admission control. Flows that strictly reduce their TSpec/RSpec SHOULD never be denied service.
Each network element MUST ensure its service approximates the fluid model at the reserved service rate R, matching it to within sharp error bounds characterized by C and D. It is acceptable to provide better service than the fluid model.
If the sum of per-element C or D values exceeds (2^32)-1, the end-to-end error term MUST be set to (2^32)-1. Individual elements may advertise C up to 2^28 bytes and D up to 2^28 microseconds.
In the RSpec, rate R MUST be greater than or equal to r (the token bucket rate) and slack S MUST be nonnegative. A flow MUST be rejected if the requested maximum datagram size M is larger than the MTU of the link.
In the TSpec, the peak rate p MUST be greater than or equal to the token bucket rate r. If the peak rate is unknown or unspecified, p MUST be set to infinity.
Links are not permitted to fragment datagrams as part of guaranteed service. Datagrams larger than the MTU of the link MUST be policed as nonconformant.
Policing MUST NOT be done except at the edge of the network; inside the network, elements that wish to police MUST do so by reshaping traffic to the token bucket, not by simple drop-based policing.
Subnetwork network elements MUST adjust the token bucket rate and possibly bucket size to account for adding link-level headers. Tunnels MUST also account for additional IP headers they introduce.
The network element MUST ensure that the queueing delay of any datagram is less than b/R + C/R + D, where C and D are the maximum local deviations from the fluid model. C and D are worst-case maximums; implementations with occasional service gaps must set D large enough to cover those gaps.
The scheduling and admission control algorithms of the element MUST ensure that delay bounds are never violated and datagrams are not lost when traffic conforms to the TSpec. The element MUST also ensure that misbehaving flows do not affect service given to other flows.
Traffic MUST obey the rule that over all time periods the amount of data sent cannot exceed M+min[pT, rT+b-M]. Datagrams smaller than the minimum policed unit m MUST be counted as size m for conformance testing.
When a network element uses slack from the RSpec, the new (Rout, Sout) pair must satisfy Sout + b/Rout + Ctoti/Rout <= Sin + b/Rin + Ctoti/Rin, and r <= Rout <= Rin. At a merge/split point, Rout is the maximum of all incoming rates and Sout is the minimum slack.
When a network element uses slack Si to reduce its resource reservation for flow i, the value Si MUST be stored. On subsequent reservation refreshes for that flow, the element MUST reuse the same slack Si without further computation, ensuring reservation consistency.
Each network element exports error terms C (parameter 131, rate-dependent, in bytes) and D (parameter 132, rate-independent, in microseconds). End-to-end composed values Ctot and Dtot are parameters 133 and 134; since-last-reshaping-point values Csum and Dsum are parameters 135 and 136.
The RSpec (parameter 130) specifies desired service as rate R (bytes/sec, >= r) and slack term S (microseconds, 0 to 2^32-1). Higher R reduces queueing delay; S represents excess headroom that network elements may use to reduce their resource reservation.
The TSpec (TOKEN_BUCKET_TSPEC, general parameter 127) specifies a flow's traffic using: token bucket rate r (bytes/sec), bucket depth b (bytes), peak rate p (bytes/sec), minimum policed unit m (bytes), and maximum datagram size M (bytes). Both r and b MUST be positive; m MUST be <= M.
RFC 2212 assigns IntServ parameter numbers: TOKEN_BUCKET_TSPEC = 127, guaranteed service_name = 2, RSpec = 130, C = 131, D = 132, Ctot = 133, Dtot = 134, Csum = 135, Dsum = 136. These numbers are used in RSVP FLOWSPEC and ADSPEC objects.
Guaranteed service can be used to mount a denial-of-service attack: a receiver requesting a reservation with an inadequate TSpec/RSpec can cause reshaping queues to grow, increasing queueing delays for other flows. The specification mitigates this by requiring non-conforming datagrams be treated as best-effort rather than dropped.
Each network element processes each (TSpec, RSpec) invocation through admission control, transitioning to either ACCEPTED (returning a new (Rout, Sout)) or REJECTED. On re-invocation with changed parameters, admission control is reapplied; on refresh for a flow that previously consumed slack Si, the element reuses Si without recomputation.
For r, b, p, and R represented as IEEE floating-point: the sign bit MUST be zero. Exponents less than 127 (representing values < 1.0) are prohibited; exponents greater than 162 are discouraged except for infinity. Infinity is represented with exponent all-ones (255) and sign/mantissa all-zeroes.
The TSpec is encoded as three single-precision IEEE 754 floating-point values (r, b, p) followed by two 32-bit integers in network byte order (m, M). The RSpec rate R uses single-precision IEEE float; the slack term S is a 32-bit integer.