Specification of the Controlled-Load Network Element Service
Extracted elements (27)
Controlled-load service is defined to approximate best-effort service under unloaded conditions rather than specifying explicit delay or loss bounds. This targets adaptive real-time applications that work well on unloaded nets but degrade quickly under overload, and deliberately avoids isochronous guarantees.
Excess controlled-load packets forwarded as best-effort will cause inelastic best-effort traffic to back off elastic traffic (e.g., TCP) if no discrimination is applied. Implementations should protect elastic traffic via separate resource allocations per class or by processing excess controlled-load traffic at lower priority than elastic best-effort traffic.
Implementations must make bandwidth exceeding the TSpec token rate available to flows in certain situations. A flow receiving exactly its token rate will see permanent queueing delay growth if a burst arrives and the flow continues generating at token rate; some mechanism to 'borrow' bandwidth for burst clearing (explicit or statistical) is required.
The service is intentionally minimal with no optional functions or capabilities, ensuring all implementations are functionally identical. This simplifies application and system design and allows a wide range of internal implementation techniques.
When nonconformant packets arrive, implementations may either degrade all packets equally (preserving ordering, preferred for TCP which interprets reordering as loss) or split packets into conformant and nonconformant sets with different service levels (preferred for time-sensitive applications such as interactive conferencing). The specification permits either approach.
The use of Controlled-Load service with RSVP is specified in RFC 2210, which defines the format of RSVP FLOWSPEC, SENDER_TSPEC, and ADSPEC objects for controlled-load applications. The RSVP protocol itself is specified in RFC 2205.
Consistent with protecting conformant flows and best-effort traffic, the network element MUST attempt to forward excess (nonconformant) controlled-load traffic on a best-effort basis if sufficient resources are available.
Each network element accepting controlled-load service MUST ensure adequate bandwidth and packet processing resources are available via active admission control. All resources important to element operation — link bandwidth, buffer space, and forwarding engine capacity — must be considered.
Each network element providing controlled-load service MUST independently ensure policing requirements are met; elements must not assume upstream nodes have already policed flows. This is especially important at multicast split points where large numbers of packets fail the conformance test as a matter of normal operation.
Links MUST NOT fragment packets receiving controlled-load service. Packets larger than the link MTU are treated as nonconformant to the TSpec and forwarded under policing rules.
Network elements MUST reject a service request if the requested maximum packet size M exceeds the link MTU. Both m and M must be positive and m must be less than or equal to M.
The network element SHOULD prevent excess controlled-load traffic from unfairly impacting the handling of best-effort traffic, to avoid excess controlled-load packets dominating best-effort bandwidth at the expense of elastic flows such as TCP.
The token bucket depth b must be in the range 1 byte to 250 gigabytes. Network elements MUST return an error for requests outside this range and MUST return an error for any in-range value the element cannot support.
The token bucket rate r must be in the range 1 byte/s to 40 terabytes/s. Network elements MUST return an error for requests with values outside this range and MUST return an error for any in-range value the element cannot support.
When nonconformant traffic arrives for one or more controlled-load flows, the network element MUST continue to provide the contracted QoS to those controlled-load flows not experiencing excess traffic.
When resources are available, network elements in the interior of the network SHOULD be prepared to accommodate packet bursts somewhat larger than the actual TSpec, because traffic distortion from queueing points may cause legitimate bursts to arrive slightly out of spec.
A merged TSpec for RSVP is computed by taking the largest r, largest b, largest p, smallest m, and smallest M across all TSpecs in the set. The merged parameters are used at the local node and passed upstream to traffic sources to describe the installed reservation.
Conformance to the TSpec requires that over all time periods T, the amount of data sent does not exceed rT+b (the token bucket rule). Packets smaller than the minimum policed unit m are counted as size m. Packets causing a violation of rT+b, or exceeding the outgoing link MTU, are nonconformant.
The controlled-load service uses the TOKEN_BUCKET_TSPEC (general parameter number 127, per RFC 2215) to describe flow traffic parameters. It contains bucket rate r, bucket depth b, peak rate p, minimum policed unit m, and maximum packet size M. The service is assigned service_name 5.
The Least Common TSpec — adequate to describe traffic from any one of several flows, useful for shared SNMP-created reservations — is computed by taking the largest r, largest b, largest p, smallest m, and largest M across the set. Unlike the merged TSpec, it is not passed upstream to sources.
The peak rate p exists primarily for TOKEN_BUCKET_TSPEC compatibility with other QoS services. In this version, a service module may always ignore p and assume peak data rate equals the incoming interface line rate; explicit use may be added in future revisions.
The sum of n TSpecs for a shared reservation of n flows is computed as: sum of all r values, sum of all b values, sum of all p values, minimum of all m values, and maximum of all M values across the set.
TSpec A is a substitute for (greater than or equal to) TSpec B if and only if A's r, b, p, and M are each greater than or equal to B's and A's m is less than or equal to B's. TSpecs that differ but do not satisfy all five conditions are unordered with respect to each other.
A correct implementation is not susceptible to a denial-of-service attack based on requesting a very small resource allocation for a targeted flow, because excess traffic above the requested level is forwarded best-effort rather than dropped.
A denial-of-service attack is possible by maliciously reconfiguring the admission control algorithm to overallocate bandwidth or other forwarding resources, starving non-controlled-load flows. This is considered no more vulnerable than other router misconfigurations and can be protected by existing reconfiguration access controls.
Any mechanism used to invoke controlled-load service (RSVP, SNMP, or proprietary) must provide sufficient security to prevent unauthorized traffic from obtaining preferential treatment, because such treatment directly and quantifiably degrades service for other flows.
The TSpec is encoded as three IEEE single-precision floating-point values followed by two 32-bit integers in network byte order: r (bucket rate), b (bucket size), p (peak rate), m (minimum policed unit, integer bytes), M (maximum packet size, integer bytes). For r and b only non-negative finite IEEE values are valid; for p, positive infinity (exponent all-ones, sign and mantissa all-zeroes) is also permitted.