| Internet-Draft | DetNet PREOF Loss Matrix YANG | October 2026 |
| Li, et al. | Expires 3 May 2027 | [Page] |
This document specifies a Standards Track YANG 1.1 data model (ietf-detnet-preof-loss-matrix) for reporting pre-elimination correlated packet delivery and co-failure outcomes across Deterministic Networking (DetNet) Packet Replication, Ordering, and Elimination Functions (PREOF). Against a closed source-declared packet population, the model classifies each original sequence number across paired replication branches into a 16-cell joint outcome matrix ({on-time, late, missing, indeterminate} x {Branch A, Branch B}) and four fate-sharing summary buckets (delivered-both, delivered-a-only, delivered-b-only, lost-both), enabling operators to distinguish masked single-branch drops from correlated dual-branch failures.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Replication can improve delivery reliability when the branches do not fail together. Two marginal loss ratios cannot reveal how often both branches fail for the same original packet. Multiplying those ratios assumes independence, which can fail under shared congestion, interference, power, or software faults. A joint outcome measurement therefore needs packet-level correlation and a population that includes packets absent from both receivers.¶
DetNet [RFC8655] provides replication and elimination concepts. Reliable and Available Wireless [RFC9912] discusses reliability over wireless segments. One-way packet loss [RFC7680], loss-pattern metrics [RFC3357], and loss episode measurements [RFC6534] already define important single-path and temporal properties. This document specifies a Standards Track YANG data model that reports correlated per-packet outcomes across paired DetNet PREOF replication branches against a closed source-declared packet population.¶
The report is intended for a managed measurement domain. It can support transport for a RAN cloud but does not prescribe radio resource allocation. Pairwise observations characterize two selected branches only; they MUST NOT be presented as the full joint distribution of a system with three or more branches.¶
In particular, the bi-packet loss pair in [RFC6534] observes two distinct source packets at different sending times. Here, an outcome pair concerns copies of the same original packet on two branches. The existing binary pair encoding is not reinterpreted, and no new IPPM metric registry allocation is requested by this YANG reporting specification.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Before measurement, the producer and consumer MUST share a measurement contract identifying the original-packet population, replication scope, branch identities, observation points, deadline budget, correlation method, and closure rules. contract-id identifies the immutable, version-specific measurement contract; population-id identifies the exact closed population in that contract namespace. It MUST distinguish correlation generations across restart or sequence reuse.¶
The population MUST be established from authoritative source or replication-function evidence, not the union of packets received on the two branches. For every original packet it identifies which copies are expected on the two branches and the reference emission event used for the deadline. Packets that never reach either receiver still belong to the denominator. If the producer cannot establish the closed original-packet set, it MUST use unavailable-reason and MUST NOT report a complete denominator or zero joint loss.¶
The accounting concerns the replication service from the declared source event to the selected merge observer. Missing includes failure anywhere in that declared scope; it does not by itself attribute a failure to a radio, forwarding hop, or sender. A narrower claim about packets actually emitted on both branches requires corresponding source-emission evidence. The same two branch identifiers MUST have a stable meaning throughout a reported window.¶
A single report contains at most 4294967295 original packets, and a positive population is required for counts. Larger populations MUST be divided into distinct, non-overlapping windows. A producer MUST NOT report a zero denominator as a successful reliability measurement. The data model uses uint32 counts so that its bounded 16-cell sum is exact in the arithmetic domain used by YANG XPath constraints.¶
A contract MUST specify source identity and emission event, flow and direction, the identities and pre-elimination placement of both observers, original/copy correlation and restart handling, expected-copy eligibility, timestamp scales and error treatment, capture-completeness rules, and population membership/disjointness. These are required deployment inputs; the opaque identifier does not transport them. Changing any interpretation requires a new contract-id. A producer MUST split a window at a contract change. An unknown contract prevents semantic aggregation even if the matrix is syntactically valid.¶
Every original in a counts population MUST be eligible for an intended copy on both selected branches. Known ineligible originals MUST be excluded when forming the source-declared common population, not removed from only one branch after classification. A change in this eligibility policy requires a new contract and a split window. Eligibility does not require successful creation or emission of both copies: failure to produce an expected copy remains within the population and is classified using the observation and closure rules. Unknown eligibility prevents a complete qualifying counts population; it MUST NOT be guessed from the union of received copies.¶
An original packet is correlated with observations on each branch using the replication mechanism and the measurement contract. This specification introduces no new packet sequence header, reset flag, or per-packet epoch. A sequence number is insufficient without its flow, direction, and generation context. Sequence wrap, restart, or reuse MUST NOT merge unrelated originals. If correlation cannot be resolved, affected outcomes become indeterminate, or the population is unavailable if its membership is no longer known.¶
The preferred observer is at the merge function with branch-specific observations before elimination. An observer after elimination alone normally cannot determine branch outcomes and MUST NOT infer them from the surviving packet. A producer relying on distributed observation reports MUST establish the completeness and identity of those reports before classifying an absence as missing.¶
For each original packet, the producer determines a conservative interval enclosing the true elapsed time from the declared source event to an observed copy. The interval includes clock error, timestamp quantization, domain conversion, and observation uncertainty. An arrival is certainly on time when its upper endpoint is at most the deadline budget. It is certainly late when its lower endpoint is greater than that budget. A boundary-straddling interval is indeterminate.¶
A packet may have duplicate observations within one branch. The producer MUST account for the original at most once per branch. If any valid observation proves an on-time delivery, the branch outcome is on-time. Otherwise, if an observation might have been on time, the outcome is indeterminate even if another copy is certainly late. If all valid observed copies are certainly late, and the observer evidence is complete, the outcome is late.¶
Each packet has a closure instant after its deadline, including the configured closure-wait and any necessary observation-report completeness allowance. The observer MUST have continuous, valid instrumentation through closure before classifying a never-observed copy as missing. An instrumentation gap, unknown source time, corrupt observation, or uncertain closure produces indeterminate rather than missing for the affected original and branch.¶
Closure-wait does not extend the delivery deadline. It permits distinguishing an observed late delivery from a copy not observed by closure. A missing classification is a timeout-bounded observation, not proof that a packet will never arrive. The report MUST NOT be finalized until every original in the population has reached a valid closure or been classified indeterminate. An event discovered after finalization does not rewrite the final report silently; it is a measurement exception requiring a distinct report or diagnostic under the deployment contract.¶
The classification precedence is: a valid proof of an on-time copy gives O; otherwise any observation that could have been on time, or any relevant unresolved capture gap, gives I; otherwise one or more certainly late observations with complete evidence gives L; otherwise complete evidence through valid closure gives M; otherwise the result is I. A certainly late copy does not cancel a prior instrumentation gap in which an on-time copy might have passed. Copies arriving after closure are outside the finalized measurement; identifying an error in the earlier evidence is a report conflict, not permission to count a new disjoint population.¶
The four outcomes are on-time (O), late (L), missing (M), and indeterminate (I). Every original belongs to exactly one of the 16 ordered outcome pairs. All cells, including zero cells, MUST be present in a counts report. Their sum MUST equal expected. A consumer MUST reject a counts report with absent or duplicate cells, a negative or out-of-range count, unequal total, or identical branch identities.¶
Let C[a,b] be a cell count and N the expected population. The number of originals certainly failing the deadline on both branches is the sum over a and b in {L,M}. A conservative upper bound on that number also includes all pairs with no on-time outcome and at least one indeterminate outcome. A known on-time copy on either branch proves that the original did not fail this paired delivery test, even if the other branch is indeterminate.¶
F = {late, missing}
J_lower = sum(C[a,b] for a in F for b in F)
J_upper = sum(C[a,b] for a != on-time for b != on-time)
Observed joint-failure fraction is in [J_lower/N, J_upper/N].
If there are no indeterminate outcomes: J_lower = J_upper.¶
These bounds describe only the observed window and its declared evidence. They are not statistical confidence intervals or deterministic future-service guarantees. A producer or consumer MUST NOT label them as a probability of future failure without a separate justified predictive model. Correlation within a time series also prevents applying independent-trial confidence formulas without checking their assumptions.¶
Marginal branch failure fractions can be derived from the same matrix, retaining uncertainty from I cells. A consumer MUST NOT replace the joint counts with a product of marginals unless an independent analysis justifies that model, and even then MUST identify the result as a model estimate rather than the observed joint fraction. A joint failure is not proof of a common physical cause; causal diagnosis requires additional evidence.¶
Each finalized window has an opaque 128-bit identifier unique across the reporting producer and its restarts. A producer MUST NOT reuse an identifier for a different population or changed counts. A report is immutable after finalization. A repeated retrieval of the same report does not constitute another measurement. Consumers MUST deduplicate by authenticated producer identity and window id before aggregating non-overlapping populations.¶
The producer MUST retain a complete window as one coherent operational-data entry. It MUST NOT expose a partially populated matrix as finalized data. A filtered retrieval that omits cells is not a complete report even if the server retains all of them. A client requiring joint results MUST retrieve and validate the complete counts subtree.¶
Retention limits are implementation and deployment policy. The producer MAY evict old complete windows. Disappearance of a window is not evidence of zero loss or a negative count. If clients require exhaustive time coverage, the measurement contract must provide a source-side window manifest or another existing reliable inventory mechanism; this model does not define an event stream with exactly-once delivery.¶
The report does not contain raw user payload. population-id and branch labels are opaque references in the managed measurement domain. Their lifecycle, namespace mapping, and authorized interpretation MUST be provisioned. A consumer unable to resolve them MAY retain the raw report but MUST NOT combine it with unrelated measurement scopes.¶
Before adding matrices, the consumer MUST establish equal contract interpretation, equal ordered branch roles, equal deadline and closure rules, and disjoint source populations. Window identifiers distinguish reports; distinct identifiers do not prove disjoint populations. A changed report for the same population MUST NOT be added to the old one. If two immutable reports conflict, the consumer MUST withhold their combined result and obtain an explicit reconciliation outside this reporting model.¶
When branch roles are exchanged under a verified mapping, the consumer MUST transpose the matrix before comparison. A shared path name is not sufficient to map two observers. Aggregate arithmetic MUST use a width large enough for all summed windows and compute the lower and upper fractions from summed counts and summed populations, not an unweighted average of ratios. Raw sums exceeding uint32 can remain local analytic results; they MUST NOT be serialized into a single counts window that exceeds this module range.¶
The DetNet OAM framework [RFC9551] already covers service monitoring and PREOF observability. This document specifies a management report for a particular paired population, not an OAM packet format or a replacement failure-detection protocol. Measurement interpretation guidance [MEAS-INTERPRET] also separates measurement scope and evidence from root-cause attribution. The report follows that boundary: it cannot infer a common cause, future reliability, or application experience from a joint matrix alone.¶
The DetNet YANG model in [RFC9633] already describes flows, service protection, and sequence configuration. This report does not replace that configuration model. A deployment MUST explicitly map its report contract and ordered branch roles to the relevant configured flow and observation identities; a shared display name does not establish the mapping. The individual PREOF OAM proposal [PREOF-OAM] describes replication, elimination, timeout, gap, and late-event observability. Such events can supply evidence, but they do not by themselves establish this report's complete source population and 16-cell joint matrix. Referencing that proposal does not imply working-group adoption.¶
This module uses YANG 1.1 [RFC7950] and the Network Management Datastore Architecture [RFC8342]. Read-only nodes are operational data. A server advertises support using YANG Library [RFC8525]; successful transport establishment alone does not establish support. JSON encoding follows [RFC7951].¶
The following tree follows [RFC8340]. The module definition, including its feature, choice, when, must, and reference constraints, is authoritative.¶
module: ietf-detnet-preof-loss-matrix
+--ro replication-outcomes
+--ro window* [id]
+--ro id binary
+--ro population-id string
+--ro contract-id string
+--ro branch-a string
+--ro branch-b string
+--ro deadline-budget uint64
+--ro closure-wait uint64
+--ro (evidence)
+--:(unavailable)
| +--ro unavailable-reason? string
+--:(accounted)
+--ro counts!
+--ro expected uint32
+--ro cell* [a b]
+--ro a outcome
+--ro b outcome
+--ro packets uint32¶
<CODE BEGINS> file "ietf-detnet-preof-loss-matrix@2026-10-30.yang"
module ietf-detnet-preof-loss-matrix {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-detnet-preof-loss-matrix";
prefix rpo;
organization
"IETF Deterministic Networking (DetNet) Working Group";
contact
"Zhiqiang Li <lizhiqiangyjy@chinamobile.com>";
description
"ietf-detnet-preof-loss-matrix data model.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2026-10-30 {
description "Initial revision.";
reference "draft-li-detnet-preof-correlated-outcomes-yang-00";
}
typedef outcome {
type enumeration {
enum on-time {
description "Certainly at or before deadline.";
}
enum late {
description "Certainly late, observed by closure.";
}
enum missing { description "Not observed by valid closure."; }
enum indeterminate {
description "Evidence is insufficient.";
}
}
description "Mutually exclusive outcome for one branch.";
}
container replication-outcomes {
config false;
description "Retained, finalized paired observation windows.";
list window {
must "branch-a != branch-b" {
error-message "Two distinct branches are required.";
}
key "id";
description "An immutable final report, never a partial
update.";
leaf id {
type binary { length "16"; }
description "Unique identifier, including across restarts.";
}
leaf population-id {
type string { length "1..256"; }
mandatory true;
description
"Reference to the exact original-packet manifest and its
correlation generation within the measurement domain.";
}
leaf contract-id {
type string { length "1..256"; }
mandatory true;
description
"Immutable, version-specific measurement contract
identifier
in a provisioned namespace. Equality alone does not prove
two populations are disjoint.";
}
leaf branch-a {
type string { length "1..128"; }
mandatory true;
description "First replication branch at the merge
observer.";
}
leaf branch-b {
type string { length "1..128"; }
mandatory true;
description "Second, distinct branch at the merge
observer.";
}
leaf deadline-budget {
type uint64;
units "nanoseconds";
mandatory true;
description "Budget from source emission to merge
observation.";
}
leaf closure-wait {
type uint64;
units "nanoseconds";
mandatory true;
description
"Wait after the latest deadline before final
classification.
This is not permission to extend the deadline.";
}
choice evidence {
mandatory true;
description "Complete accounting or unavailable
population.";
case unavailable {
leaf unavailable-reason {
type string { length "1..512"; }
description "Why a closed original-packet set is
unknown.";
}
}
case accounted {
container counts {
must "sum(cell/packets) = expected" {
error-message "Outcome counts must sum to
population.";
}
presence "The original-packet population is known.";
description "Exactly one pair outcome per original
packet.";
leaf expected {
type uint32 { range "1..max"; }
mandatory true;
description "Size of the source-declared population.";
}
list cell {
key "a b";
min-elements 16;
max-elements 16;
description "All 16 outcome pairs, including zero
cells.";
leaf a {
type outcome;
description "Outcome on branch A.";
}
leaf b {
type outcome;
description "Outcome on branch B.";
}
leaf packets {
type uint32;
mandatory true;
description "Original packets with this outcome
pair.";
}
}
}
}
}
}
}
}
<CODE ENDS>¶
| A / B | O | L | M | I |
|---|---|---|---|---|
| O | 950 | 10 | 5 | 5 |
| L | 10 | 4 | 3 | 2 |
| M | 5 | 2 | 2 | 1 |
| I | 0 | 0 | 0 | 1 |
The matrix totals 1000. The four certainly failed cells contain 4 + 3 + 2 + 2 = 11 originals. Including L/I, M/I and I/I adds 4 potentially failed originals, giving an observed joint-failure fraction between 11/1000 and 15/1000. The 5 O/I entries do not increase the upper bound because branch A proves timely delivery.¶
If only received-packet unions were used as the denominator, the M/M originals would be invisible and the resulting joint measurement would be biased. If a capture failure affected branch B, it would be wrong to move every unobserved B packet to M; the affected cells must use I unless complete evidence can be recovered.¶
This constructed example illustrates the 16-cell joint outcome matrix and the conservative interval bounds [J_lower/N, J_upper/N]. It is not an implementation or decoding test result.¶
| Test | Expected outcome |
|---|---|
| Both copies absent; source manifest known; observers complete | M/M cell |
| Only receive union known | Population unavailable |
| A proves on-time; B capture lost | O/I cell; no joint failure |
| Arrival uncertainty straddles deadline | Indeterminate unless another copy proves on-time |
| Duplicate before elimination | Count one original on that branch |
| Sequence reset without generation context | Do not correlate across reset |
| 16 cells do not sum to N | Reject complete counts interpretation |
| Repeated window id with changed counts | Conflicting report; do not aggregate |
| Window omitted by retention | Missing coverage, never zero failures |
| Third branch present in system | Do not generalize pairwise result |
A conforming report producer MUST preserve the source-declared eligible packet denominator even when both branch copies are missing, and a consumer MUST validate all 16 matrix cells before computing any joint loss or delivery ratio. Required negative test cases include: (1) rejecting a received-union denominator that omits lost-both packets, (2) rejecting omitted zero cells or duplicate cell coordinates, (3) detecting swapped branch roles without matrix transposition, (4) rejecting packets with unknown dual-branch eligibility, and (5) distinguishing unavailable observation evidence from a measured zero joint-failure count.¶
The deployment requires an active DetNet replication and elimination service with identifiable original sequence numbers and pre-elimination branch observation points as defined in [RFC8655] and [RFC9551]. Standard equal-cost multi-path (ECMP) forwarding or upper-layer application retries without per-packet DetNet sequence correlation do not instantiate a valid paired observation population.¶
This YANG data model operates strictly at the DetNet service and forwarding sub-layers [RFC9633]. It requires no modification to DetNet data-plane encapsulation headers, sequence number fields, or upper-layer application protocols.¶
A useful validation separates the original-packet generator, the two branch observers, and the report consumer. The source population includes packets missing on both branches. Loss injection and observer-capture failure must yield different outcomes. This document does not establish joint failure probabilities for future traffic or prove physical failure independence.¶
The YANG data defined here is designed to be accessed using NETCONF [RFC6241] or RESTCONF [RFC8040]. NETCONF implementations use the secure transport requirements of [RFC6242]. RESTCONF uses HTTPS; implementations of this specification that expose RESTCONF MUST support TLS 1.3 [RFC9846]. Servers MUST authenticate peers, authorize each read or operation, and protect message integrity and confidentiality. The NETCONF Access Control Model [RFC8341] provides access control. Deployments MUST NOT permit unauthenticated fallback when the protected channel fails.¶
The module is read-only but exposes service quality, branch relationships, and potentially sensitive population references. Those nodes require role-scoped read authorization. A false population manifest can hide joint failures, and a compromised observer can falsely assert complete capture. Consumers MUST bind both to their measurement contract and trusted source identities. Input sequence identifiers are untrusted unless validated in the replication scope; attackers can otherwise create false correlations. Implementations MUST limit the number of retained windows and the work used to match originals and copies. Authentication of a report does not establish the independence of two branches or the correctness of a claimed physical cause.¶
Servers MUST bound retained records, request rate, response size, and processing work per authorized principal. Failure of an observation or management channel MUST NOT be converted into a favorable quality or reliability result. Protected transport authenticates the reporting peer; it does not prove that a sensor, estimator, or device is truthful. Consumers MUST use only authorized sources for the relevant device and measurement scope.¶
This module defines no writable nodes or RPCs. Sensitive readable nodes under replication-outcomes/window are contract-id, population-id, branch-a, branch-b, deadline-budget, closure-wait, unavailable-reason, and counts. They reveal service selection, topology, and service performance. Window id also permits linkage across queries. Read authorization and retention limits SHOULD apply to the whole window so that partial disclosure does not create a misleading complete report. A contract identifier MUST NOT cause automatic retrieval of an arbitrary URL supplied by an untrusted source.¶
A deliberately filtered view can depart from whole-window disclosure when required by access policy or an authorized query. The consumer MUST NOT treat that partial view as a complete joint matrix or infer omitted counts as zero. The server's retained complete window and its resource bounds remain unchanged.¶
IANA is requested to register the following URI in the IETF XML Registry defined by [RFC3688]. This request does not assign the namespace before publication.¶
URI: urn:ietf:params:xml:ns:yang:ietf-detnet-preof-loss-matrix. Registrant Contact: the IESG. XML: N/A; the requested URI is an XML namespace.¶
IANA is requested to register the module ietf-detnet-preof-loss-matrix in the YANG Module Names registry under the guidelines of [RFC6020] and [RFC9907]. Namespace: urn:ietf:params:xml:ns:yang:ietf-detnet-preof-loss-matrix. Prefix: rpo. Maintained by IANA: N. Reference: this document. No new transport port, data-plane flag, or packet code point is requested.¶