Summary

  • RFC 2214 exposed each interface’s backlog term C, delay term D, slack and RowStatus as read-create SNMP objects for Guaranteed Service.
  • Those values described implementation error and a local resource trade-off. They did not prove that a named flow crossed the interface, retained an RSVP reservation, received a composed RFC 2212 bound or met measured delay.

A manager looking at RFC 2214’s table could see something that resembled a compact service certificate. One row, indexed by an interface, held a byte count for backlog, a microsecond count for delay, a slack value and a status. Every column was read-create. If the row was valid and the numbers were present, it was tempting to conclude that the interface guaranteed a delay.

The MIB said less, and that restraint was its engineering value.

Published in September 1997 by Fred Baker, John Krawczyk and Arun Sastry, RFC 2214 extended the Integrated Services MIB for Guaranteed Service. It did not define the guarantee itself; RFC 2212 did that. It exported the interface attributes needed to describe how a real implementation departed from an idealized fluid server and how a local element might spend spare delay margin to reserve fewer resources.

C priced the cost of packetization

RFC 2212 characterized an implementation with two error terms, C and D. C was rate-dependent. In the end-to-end delay calculation, C was divided by the reserved rate R. That form mattered because some implementation costs change with transmission rate. The RFC used serialization into ATM cells as one example.

RFC 2214 presented C through intSrvGuaranteedIfBacklog. Its unit was bytes. The object described data backlog created by the “vagaries” of an implementation’s deviation from strict bit-by-bit service. For packetized weighted fair queueing, the text suggested setting it to the maximum packet size.

Backlog was therefore not a live queue-depth meter. It did not say how many bytes were waiting when SNMP read the row. It was an error characterization used in a mathematical service model. Confusing those two meanings would turn a configured bound into telemetry it never claimed to be.

D priced time that rate could not explain

The second object, intSrvGuaranteedIfDelay, carried D in microseconds. D was the rate-independent, per-element error term: the worst non-rate-based transit-time variation through the service element. RFC 2214 illustrated it with the path from input interface to processor to output interface, and with worst-case Ethernet collision delay.

That still did not make D an observation of a packet. It was a maximum set for an element, often at boot or configuration time. The end-to-end model added local values into Dtot. A management read could show what one interface declared; it could not establish that the current packet path included that interface, that every hop contributed correctly, or that routing remained unchanged.

RFC 2212 made the missing conditions explicit. Guaranteed Service bounded queueing delay for conforming traffic, assuming no component failure and no route change during the flow. It did not control minimum or average delay. Path latency still had to be added to obtain a maximum datagram delay. The mechanisms that collected per-hop C and D into Ctot and Dtot belonged to setup, routing or management functions outside RFC 2212.

Slack was a decision that had to survive refresh

Slack introduced the most revealing state. If a network element used an amount Si to reduce the resources reserved for flow i, RFC 2214 required that value to be stored. Later reservation refreshes for the same flow had to reuse the same Si without recomputation. The purpose was consistency.

The example began with delay margin: S = Dreq - (b/r + Ctot/r + Dtot). An intermediate element could consume s <= S. An RCSD scheduler could allow a larger local delay bound; a WFQ scheduler could reduce the local reservation rate under the specified transformation rules. Slack let an element exchange some unused delay margin for lower local resource commitment without increasing the overall bound.

This made slack consequential but not evidentiary in the broad sense. It was not spare bandwidth, observed latency or an application SLA. It recorded a local allocation decision. Its persistence across refreshes prevented the reservation from drifting because the same request was repeatedly recalculated under changing local choices.

That persistence created a new audit question: which flow did the stored value belong to, when was it chosen, and was the same decision actually reused? The interface table alone could not answer. RFC 2214 indexed the row by ifIndex, not by a flow identity. The generic flow table lived in RFC 2213, while RSVP’s receiver-oriented soft-state lifecycle lived in RFC 2205.

Read-create described authority, not outcome

All four columns were read-create. A management station might therefore do more than observe the declared parameters. RFC 2214’s security section warned that an SNMP SET could create an RSVP or Integrated Services reservation under rules different from RSVP negotiation.

That sentence blocks a convenient fiction. A successful SET cannot be relabeled as receiver consent. A writable interface row cannot prove that admission control accepted a specific requester, that refresh messages continued, that a classifier selected the intended packets or that a scheduler delivered the calculated treatment.

The status column was narrower too. It used RowStatus and was valid on interfaces configured for Guaranteed Service. In the RowStatus convention, active means a conceptual row is available for use by the managed device. It does not mean the path is complete or the promise has been met.

RFC 2214’s lasting achievement was to make implementation error and local discretion visible. C stated how packetization or another rate-dependent effect departed from the fluid ideal. D stated the rate-independent delay allowance. Slack exposed how an element could trade delay margin for resources and required that choice to remain stable across refreshes. Status made the row manageable.

Together they formed a useful ledger. A ledger becomes trustworthy when it preserves its boundary: it can describe the parameters an interface declares and the local choice it stores. The guarantee still has to be established across the actual flow, path, composition, traffic conformance and observation.

Sources