Summary

  • RFC 9892 lets a modem describe packet classes with modem-local TID and FID values and Diffserv or Ethernet match rules. Those identifiers select a classification set; they do not establish a queue, credit window, forwarding treatment or service outcome.
  • Operational evidence begins after the classifier: the router must validate the complete set, apply explicit, wildcard and precedence rules, identify the negotiated extension that consumes it, update data-plane state and separately observe the disposition of matching packets.

The export looked conclusive: one row said that a packet had matched TID 7 and FID 3. The incident note expanded the row into a larger claim. The traffic had entered the priority queue and received its intended treatment.

Only the first sentence was supported.

RFC 9892, published on the IETF Standards Track in January 2026, defines a Traffic Classification Data Item for the Dynamic Link Exchange Protocol. It gives a modem a structured way to tell an attached router that certain packet-header values form a classification set and that particular values belong to particular flows. It supplies identifiers, match formats, update rules and receiver validation.

The specification deliberately does not make classification synonymous with treatment. It says the format is independent of a particular use. A separate extension supplies the operational meaning. The classifier can identify the traffic that some later mechanism may pause, meter, credit or measure. It does not prove that the mechanism was negotiated, that state was installed, that a queue admitted a packet or that a remote application received anything.

That separation is the useful design. It also creates the evidence boundary that a compact dashboard is most likely to erase.

The number belongs to the modem, not the estate

The classification set is named by a Traffic Classification Identifier, or TID. Each member flow is named by a Flow Identifier, or FID, carried inside a Sub-Data Item. The modem provides this information to the router. A using extension supplies the destination association needed to turn the set into an actionable mapping.

TID and FID values have modem-local scope. The number 7 issued by one modem has no implied relationship to the number 7 issued by another. Even an apparently stable pair cannot be treated as a global business key without the modem and session context that gave it meaning.

RFC 8175 makes that context visible. DLEP is a session-oriented exchange between a modem and an attached router. Separate modem connections produce separate sessions, extensions are negotiated per session, and the protocol runs on the local link. Any signaling over the attached medium is outside the base DLEP specification.

An evidence record therefore needs more than TID and FID. It needs the peer identities, session lifecycle, receiving message, classifier version and using extension. Stripped of that envelope, the numbers resemble durable object identifiers while retaining none of the authority such identifiers imply.

The same caution applies to the registry. The IANA DLEP Parameters registry records Traffic Classification as Data Item type 29 and records the initial Diffserv and Ethernet Sub-Data Item types. That makes wire labels interoperable. It does not show that a named implementation supports them, that two peers negotiated an extension, or that any packet met a rule.

A replacement is not an append-only history

A modem may supply classifiers in a Session Initialization Response and may send new or updated sets in Session Update messages. When the router sees a TID that it already knows, RFC 9892 requires it to replace the corresponding classification information and update associated data-plane state as needed.

That is current-state semantics, not a historical ledger. If an observer stores each received Sub-Data Item as an additive fact, an old match can survive beside its replacement and produce a classification that no participant actually held. If it stores only the latest view, it loses the transition that explains a changed treatment. Both are avoidable when the evidence model keeps the complete set version and the replacement time.

Order supplies no rescue. Sub-Data Items have no required semantic ordering. A parser cannot infer priority because one entry appeared first, nor can an auditor reconstruct update intent by sorting FIDs numerically. The rules reside in the item type, the complete set and the extension that consumes it.

The empty cases are equally precise. A Traffic Classification Data Item with zero Sub-Data Items means no traffic should match the TID. A Diffserv Sub-Data Item with zero DSCP values means a wildcard match for DSCPs that lack an explicit FID mapping. “Nothing matches” and “everything not otherwise named matches” are opposite policies, even though both carry a zero count.

An interface that renders both as default has already changed the decision surface.

Validation happens across the whole set

Diffserv classification identifies one or more DSCP values that should be treated as one flow. The router must validate the received information before using it. Each DS field value may appear only once across the complete Traffic Classification Data Item, not once per Sub-Data Item. A duplicate in two separate fragments therefore invalidates the item rather than creating two plausible matches.

RFC 2474 helps keep the terms narrow. A classifier selects packets from header content under defined rules. The DSCP is then mapped to a per-hop behavior at a network node, often through a queue-service or queue-management discipline. Service construction across boundaries remains a larger system. Selection, local forwarding behavior and delivered service are related, but they are not one observation.

The broader Diffserv architecture in RFC 2475 reinforces that local-policy boundary. Classifiers and traffic conditioners sit within domains and at their edges. A header value is an input to a policy-controlled treatment, not a portable receipt for an end-to-end promise.

Ethernet classification adds another decision layer. It can match VLAN and Priority Code Point values. A zero VLAN identifier tells the receiver to ignore that field; the reserved all-ones value cannot be used. Explicit VLAN mappings are considered before the default mapping.

If both the Diffserv and Ethernet classifiers match a packet, RFC 9892 says the Ethernet VLAN/PCP information takes precedence. A telemetry system that retains only the DSCP match may be factually accurate about one input and wrong about the classifier that won.

Useful evidence therefore records all candidates, the whole-item validity result, the explicit or wildcard route and the precedence rule that selected the FID. A single final label may be convenient for forwarding. It is insufficient for explanation.

The consuming extension owns the next decision

RFC 9892 says its formats are used only when an extension requires them. This is not a minor compatibility note. The classifier has no generic operational action of its own.

RFC 9894, for example, defines a Diffserv-aware credit-window extension. A participant must advertise support during initialization, and an implementation claiming the extension must support the required RFC 9892 and RFC 9893 messages, Data Items and processing. The modem can configure DSCP-to-window mappings, while the router uses the supplied classifier to identify traffic associated with each window.

RFC 9893 supplies the separate Credit Window Association Data Item. It binds a TID to a DLEP destination and rejects missing or overlapping classifications. A TID is not used by that mechanism merely because the classifier exists. It must be associated in the extension-defined way.

That handoff marks the boundary with the existing Leadership Alliance analysis of credit. The earlier article examined why a Credit Window Grant is permission to send and not proof of attached-link delivery. This article stops one rung earlier. Before credit can be granted to the right flow, the system must establish which classifier set was current, which rule matched and which extension gave the FID operational meaning.

The remaining ladder is long: install intended state, select a queue or window, admit a particular packet, debit credit if applicable, transmit over the attached link, receive remotely and observe application effect. A classifier can be valid while any later transition fails.

Authenticity narrows the question; it does not answer it

RFC 9892 warns that an actor masquerading as a DLEP peer could inject an alternate classifier and change the mapping of traffic to queues, causing delay, congestion or loss. RFC 8175's transport and link security options can protect the control exchange.

Authentication is necessary, but its conclusion remains bounded. A secure session can establish which peer sent the classification. It does not establish that the peer's policy was correct, that the receiver installed the intended state, that overlapping local configuration did not alter the result or that a packet received the service an operator later described.

The evidence chain should therefore contain both provenance and effect. Preserve authenticated sender, session, message hash and validation result. Then separately preserve selected FID, consuming extension, associated destination, intended state, observed queue state, packet counters, link transmission and remote observation. Security protects the claim's origin; running state tests the claim's effect.

This is the practical form of Heng Lu's running-code primacy. The common specification should make coordination possible and the running system should determine what actually happened. The minimum-initial-specification principle keeps the shared layer thin: common formats, validation and precedence are enough; local extensions and operators retain later decisions and their consequences.

The warning in Reality Layers and Symbolic Power applies directly to a label such as classified. If the label silently absorbs receipt, validity, association, installation and outcome, a descriptive field becomes an authority claim. Precision is not pedantry here. It prevents one small identifier from owning an entire service story.

The classifier named the flow. That was useful. It became trustworthy only when the system also recorded what the name could not prove.

Sources