Summary

  • RFC 1513 extended RMON to Token Ring networks and explicitly defined dropEvents as detected resource-shortage episodes at the probe, not the exact number of frames dropped.
  • The specification also warned that assured delivery could make a promiscuous probe count some soft-error reports twice. Reporter, upstream neighbour, station order and sample interval were therefore part of the evidence, not decoration around the counter.
  • A management value, an inference about network loss, a decision to blame a station, an authorized control action and the resulting service state were separate receipts. Later RMON work named exact dropped-frame counters separately.

One click of the counter

Remote monitoring begins with an attractive bargain. Place a probe on a shared network, let it watch continuously, and ask it for compact numbers instead of moving every frame to a central console. The probe becomes a witness that can remember traffic, errors and station behaviour while the management station is elsewhere.

In September 1993, RFC 1513 adapted that bargain to IEEE 802.5 Token Ring. Its predecessor, RFC 1271, had described nine RMON functional groups, but some statistics and history objects assumed Ethernet. RFC 1513 supplied Token Ring-specific views and added ring-station, station-order, station-configuration and source-routing groups.

The interesting historical fact is hidden inside a counter description. tokenRingMLStatsDropEvents increased when the probe dropped packets because it lacked resources. The RFC immediately narrowed the meaning: this was not necessarily the number of packets dropped. It was the number of times the condition had been detected.

One event might hide one missing frame. It might hide a burst. Two events might overlap with very different volumes. A counter could be perfectly implemented and still fail to answer “how many frames were lost?” because that was never the question encoded by the object.

The counter did not lie. The careless noun attached to it did.

The observer had a failure mode

That distinction placed the probe inside the system it observed. Resource exhaustion was not only a network condition; it was a condition of the witness. When the probe could no longer account for all incoming frames, the management data became a record of partial visibility.

RFC 1513 repeated the same semantics in MAC-layer statistics, promiscuous statistics and their sampled history tables. That repetition matters. A current total and a value stored for one historical interval could share a name family while requiring different time context. A poll needed the data-source interface, table and control-row identity, owner, status, activation epoch and sampling interval. Without them, a delta could combine two different collection regimes.

Counters also age badly when their epoch is forgotten. A probe restart, row deletion and recreation, 32-bit wrap or data-source change can make a smaller value look like recovery or a larger value look continuous. The number alone cannot tell the management station whether it belongs to the same witness and the same experiment.

This is why later RMON-2 work is revealing. RFC 4502 described separate DroppedFrames objects and explicitly said that, unlike dropEvents, those values were the exact number of frames dropped from a collection. The later name did not correct a false counter. It created a different measurement.

A report could arrive twice

The observer problem did not stop at capacity. RFC 1513 warned that Token Ring soft-error report packets could be sent with assured delivery. A device monitoring promiscuously might therefore count some errors twice.

The warning breaks a comfortable assumption: packet receipt is not event uniqueness. Two observed reports may describe one underlying error. Assured delivery improves the chance that a report arrives; it can also create duplicates that must not be mistaken for two faults.

An operator needed at least the reporting station, report type, relevant sequence or timing evidence, capture point and deduplication rule. Even then, the source record proves only that duplication was possible. It does not prove that any named implementation deduplicated badly or that a particular counter value was inflated.

The same discipline applies in reverse. A missing duplicate does not prove a missing event. A zero counter does not prove perfect traffic visibility. Measurement is a chain from frame to probe, classification, state update, poll and interpretation. Every link can narrow what the final number means.

Reporter, neighbour, cause

Token Ring error accounting made topology part of the interpretation. RFC 1513 instructed the host group to increment different entries for different error categories. Address Copied errors affected the nearest upstream neighbour of the reporting station. Line and burst errors affected both the reporting station and its upstream neighbour. Internal and abort errors affected only the reporter.

Those rules created a useful operational projection. They did not establish physical guilt. A station named in a counter might have reported the error, been adjacent to the reporter, or been selected by an accounting convention. The projection answered “where should this evidence be filed?” before anyone could safely answer “what failed?”

The Ring Station Order Group made the order of stations available to management. That order could help locate the relevant neighbour and notice topology changes. Yet an order table was another snapshot. It did not prove that the topology was unchanged when the error occurred, that every station was visible, or that a frame reached its destination.

The distinction is easily lost in dashboards. A label that shows one station beside a red number can turn a classification relationship into a causal verdict. RFC 1513's details resist that collapse. Reporter, neighbour, counter bucket and root cause were not synonyms.

Good frames belonged to a different population

The document also defined what it meant by a “good frame” and specified which counters excluded errored traffic. Some octet and packet totals counted valid frames; error counters came from error-report packets; dropEvents described the probe's inability to account for traffic. These populations cannot be combined without checking their definitions.

A ratio built from incompatible populations may be arithmetically correct and operationally meaningless. If the numerator represents detected shortage episodes and the denominator represents good frames, the result is not a loss rate. If an error report can be duplicated, its count cannot silently become an incident count. If the probe dropped frames before classification, later category totals cannot reconstruct what it never processed.

The lesson is more precise than “telemetry is uncertain.” Telemetry can be exact about a bounded object. The uncertainty enters when an analyst substitutes a broader operational claim for that object.

Seeing and acting shared a document, not an authority

RFC 1513 did more than observe. Its Ring Station Configuration Group allowed active operations: a monitored station could be removed or configuration information downloaded. That placed a control surface beside the measurement surface.

The document had already stated an important limit. A MIB object's access level described whether reading or writing made protocol sense; it was independent of administrative authorization policy. A read-write definition therefore did not authorize an operator, process or organization to change a station. It only defined a possible protocol operation.

This gap matters most when automated response is tempting. A rise in dropEvents may show that the probe itself is short of resources. A station counter may reflect a neighbour-attribution rule. A duplicated report may inflate an error category. None of those facts alone justifies ejecting a station from the ring.

An active operation requires its own chain: authenticated requester, authorization decision, target identity, pre-action topology, command, response, configuration state and observed network outcome. The object that suggested investigation cannot serve as the receipt that remediation was justified or successful.

Source routing was another partial view

Token Ring could carry optional source-routing information. RFC 1513's Source Routing Statistics Group derived utilization data from that information, separating all-route, single-route, local and hop-count patterns.

Optional visibility is not universal topology. A packet without a route information field did not supply the same evidence as one with it. A frame observed on one ring did not prove an end-to-end path. A hop bucket summarized encoded routing information, not successful delivery or current policy authority.

Here again the MIB preserved a useful thin layer. It exposed what a probe could classify without pretending to settle every operational question. RFC 3577 later placed RFC 1513 inside the wider RMON family: media-specific monitoring alongside RMON-1, RMON-2, switched-network and high-capacity extensions. The family grew by naming new observations rather than forcing every question into one old counter.

What the record proves

The RFC Editor record proves the publication, authorship, standards lineage and present Historic status. The IETF Datatracker preserves the document history. RFCs 1271, 1757, 2021, 2819, 3577 and 4502 establish the surrounding RMON lineage.

They do not prove a named deployment, packet loss, outage, vendor defect, successful intervention or current implementation behaviour. Historic status is not an incident report. RFC 4502's later deprecation of some Token Ring RMON-2 augmentations for insufficient independent interoperability evidence is also not proof that RFC 1513 caused operational failure.

Heng Lu's Running-Code Primacy supplies the right test: the shared specification becomes operationally meaningful only through observed execution and results. Minimum Initial Specification explains why a common layer should define the minimum stable meaning while leaving local capacity and action choices visible. On Reality Layers warns against letting a symbol inherit authority from the reality it only represents.

RFC 1513's small disclaimer was therefore architectural, not clerical. The number 42 could truthfully say that the probe noticed 42 shortage episodes. It could not testify to 42 missing frames, 42 network failures or 42 reasons to punish a station. Trust began when the counter's semantics travelled with its value.

Sources