Summary

  • RFC 9546 places a DetNet Associated Channel Header directly after the monitored flow’s S-Label, but gives active OAM an independent circular eight-bit sequence number.
  • PREOF must use that d-ACH sequence for OAM processing; the standard explicitly says that App-flow and OAM use different sequence-number spaces.
  • A clean OAM history can establish continuity inside one Node ID, Level, Session and time scope. It cannot reconstruct absent production packets or certify the application result.

The first clue was almost too reassuring. The active test packets were numbered without a gap. Replication had produced copies, elimination had removed the extras, and the observation point received an orderly stream. Yet the production controller had missed a time-critical message.

An operator looking only at the common service label could conclude that the application report must be false. The test and production traffic belonged to the same DetNet service. The test packet had experienced the same class of special functions. Its sequence was intact. What more could a receipt possibly say?

The answer in RFC 9546 is precise: it can say what happened to the OAM history, not what happened to the App-flow history. The distinction is designed into the packet. It is not an inconvenience added by an auditor.

One service label, two ledgers

At the DetNet service sub-layer, an S-Label identifies a DetNet flow. For active OAM over the MPLS data plane, RFC 9546 requires the DetNet Associated Channel Header—d-ACH—to appear immediately after that S-Label. This makes the association operationally useful. A node can recognise that the test packet concerns the service identified by the label and can subject it to the relevant DetNet functions.

Association is not identity. The d-ACH carries a sequence number of its own. When PREOF processes an active OAM packet, it must take sequencing information from that d-ACH field. The RFC then removes any possible ambiguity: App-flow and OAM use different sequence-number spaces.

That sentence prevents a seductive but invalid join. Suppose OAM packet 41 survives elimination and emerges after packet 40. The observation supports a bounded statement about the test stream. It does not show which App-flow packet was current at that instant, whether an App-flow copy arrived late, whether a production duplicate was discarded, or whether the application had already crossed its deadline. There is no normative equation in which OAM 41 becomes production packet 41.

The common S-Label is therefore a relationship key, not a shared event number. It answers, “Which service context is this test about?” It does not answer, “Which production event does this test packet replace?” A monitoring system that stores only label plus sequence silently converts two ledgers into one.

The header defines the scope of the observation

The d-ACH begins with four fixed bits, 0001. They distinguish the packet from an IP packet and from a DetNet data packet. A four-bit Version follows; RFC 9546 defines version zero. Then comes the circular eight-bit Sequence Number, a sixteen-bit Channel Type, a twenty-bit Node ID, a three-bit Level, five flag bits and a four-bit Session ID.

Those fields are not ornamental protocol furniture. Together they delimit who can speak, within which maintenance scope, about which test conversation.

The Node ID identifies the DetNet node that originated the packet. It must be provisioned uniquely within the DetNet domain. The standard deliberately leaves the distribution method outside its scope. A collector cannot infer global uniqueness from the width of the field, and it cannot prove correct provisioning merely because the value parses. Its inventory must establish which domain was meant, which node held the value at that time, and how collisions or reassignment are handled.

Level supplies hierarchy analogous to a maintenance-domain level. An inner operational team and an outer service boundary may observe related traffic while having different visibility and authority. Session ID distinguishes simultaneous OAM sessions from the same node at the same level. Channel Type says which associated-channel protocol the packet carries.

The defensible key is consequently closer to S-Label, Node ID, Level, Session ID, Channel Type, epoch and observation point. An eight-bit number by itself is not a history. It is a number waiting for a scope.

A small circular counter needs an epoch

The originator must set the d-ACH Sequence Number before transmission. The initial value should be random or unpredictable, and the normal strategy is to increment it for every active OAM packet. The originator may choose another strategy, however, including deliberately unusual sequences for negative testing of Packet Ordering Functions.

The field ranges only from 0 to 255. RFC 9546 considers that sufficient because active OAM traffic is expected to run at a much lower rate than the App-flow, making wraparound manageable for the intended processing. The claim is scoped. It is not a universal promise about any rate an operator may configure, any retention period a data lake may use, or any algorithm that ignores time.

A dashboard that sees 254, 255, 0, 1 needs enough context to distinguish normal wrap from a restarted session. A gap might mean loss, deliberate negative testing, collection failure, a changed observation point or a new origin epoch. A repeated value might be a duplicate, a wrap, a reset or two sessions that were merged after their Session IDs were discarded.

This is why preserving raw fields matters. A green/red derivative is convenient for a wallboard but destroys the facts needed to review ambiguity later. The record should retain the full d-ACH tuple, S-Label, receive time, observation point and the configuration epoch under which the test ran.

PREOF success remains local to the sequence space it processed

Packet Replication, Elimination and Ordering Functions can improve the chance of timely, ordered delivery. A packet may be copied onto member flows, later copies may be eliminated, and an ordering function may hold or release packets according to its configured rules. The existing DetNet standards make these valuable mechanisms real. They do not make their evidence universal.

When the packet is OAM, PREOF uses the d-ACH sequence. When the packet is App-flow data, the production sequencing information belongs to the App-flow’s own control context. Each elimination decision refers to the history window visible in that space. Each ordering decision depends on its own arrivals, delay assumptions and state.

An immaculate OAM result can coexist with an App-flow gap because the two streams contain different packets at different rates. An OAM gap can coexist with successful application delivery for the same reason. Even strong fate sharing does not merge the counters. It may improve the relevance of the test, but relevance is not substitution.

This is distinct from asking whether the probe took the same ECMP or LAG member, received the same shaping treatment, or crossed the same tunnel. Those are equivalence questions. RFC 9546 presents an earlier accounting constraint: even when the association and treatment are accepted, the OAM sequence still belongs to a separate ledger.

Build the evidence chain without inventing a join

An operator can preserve the boundary with four linked records.

First, the service-association record shows that the OAM packet carried the intended S-Label and a valid d-ACH in the required position. Second, the OAM-session record identifies Node ID, Level, Session ID, Channel Type, epoch and test policy. Third, the OAM-PREOF record shows what replication, elimination or ordering did to those OAM sequence values at named nodes. Fourth, a separate App-flow record follows production sequencing through its own PREOF decisions to the receiver and application.

Correlation is still useful. An OAM discontinuity and an App-flow discontinuity observed in the same bounded interval can justify investigation. A change in both histories after the same configuration event can strengthen a causal hypothesis. But correlation must retain the two source identities. The system should say “these two scoped observations coincided”, not “the OAM number proved the production packet was delivered”.

The operational gain is substantial. Once the ledgers remain separate, a dispute becomes diagnosable. The test generator may have restarted. Node IDs may have collided. A collector may have dropped an OAM record. App-flow copies may have shared a hidden risk. The ordering window may have expired for production traffic while the sparse test stream remained unaffected. Or the application may have rejected a packet that the network delivered. One green line cannot adjudicate those possibilities.

Sources