Operations and Management Area Working Group Z. Li Internet-Draft Z. Du Intended status: Standards Track China Mobile Expires: 3 May 2027 J. Wang W. Cheng Y. Zhao Centec C. Zhao SAIA X. Sun Inesa 30 October 2026 IP Flow Information Export (IPFIX) Information Elements for Bounded- Latency and Residence-Budget Discard Attribution draft-li-opsawg-ipfix-latency-budget-drop-00 Abstract This document defines IP Flow Information Export (IPFIX) Information Elements and a forwardingStatus (IE 89, Status 10b: Dropped) sub- reason code for attributing packet discards caused by explicit residence-time or delivery-deadline budget expiration in bounded- latency data-center and deterministic networks. The specification standardizes primary-cause precedence over competing drop policies, clock-uncertainty comparison invariants, zero-count interval uncertainty encoding, and deterministic mapping to the IETF device packet-discard reporting model. Status of This Memo 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. Li, et al. Expires 3 May 2027 [Page 1] Internet-Draft IPFIX Latency-Budget Discard IEs October 2026 Copyright Notice 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. Table of Contents 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Deadline Evidence and Comparison . . . . . . . . . . . . . . 3 4. Primary Cause and Accounting Unit . . . . . . . . . . . . . . 5 5. Data Records and Scope . . . . . . . . . . . . . . . . . . . 6 6. Information Element Definitions . . . . . . . . . . . . . . . 8 6.1. deadlineBudgetNanoseconds . . . . . . . . . . . . . . . . 8 6.2. deadlineComparisonUncertaintyNanoseconds . . . . . . . . 8 6.3. Reuse of Existing Information Elements . . . . . . . . . 9 7. Templates, Encoding, and Collection . . . . . . . . . . . . . 9 8. Deployment and Acceptance . . . . . . . . . . . . . . . . . . 10 9. Examples and Required Boundary Behavior . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11.1. Forwarding Status Reason . . . . . . . . . . . . . . . . 14 11.2. Information Element Registrations . . . . . . . . . . . 15 11.3. Use Before Allocation . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction and Scope A network enforcement point can discard a packet because its configured delivery or residence-time budget has expired. Reporting only a generic drop does not distinguish this decision from congestion or an access-control policy. Conversely, a late arrival or a timeout at an application does not establish that any network node made such a decision. Li, et al. Expires 3 May 2027 [Page 2] Internet-Draft IPFIX Latency-Budget Discard IEs October 2026 This document defines a reporting profile for an enforcement point that can supply the actual discard decision, the applicable budget, and bounded elapsed-time evidence. It applies within a managed network with an agreed measurement context. A deterministic network [RFC8655] is one possible context; the deadline-based forwarding proposal [DEADLINE-FWD], a work in progress, is related forwarding work. Neither context establishes that a particular device supports the observations required here. The profile uses IPFIX [RFC7011], its Information Model [RFC7012], and the existing IANA Information Elements [IANA-IPFIX]. Its additions are a deadline-expired forwarding reason and two quantities: the configured budget and the comparison uncertainty. It defines no packet format, clock synchronization protocol, scheduler, transport protocol, RDMA behavior, or instruction to enable packet discarding. Application cancellation, upper-layer transaction timeouts, storage lookup misses, and transfer completion failures are outside its measurement scope. The work-in-progress packet discard model [DISCARD-MODEL] classifies discards by cause and defines interface and device accounting requirements. A deliberate discard enforcing a configured time budget belongs to its policy category, rather than a no-buffer or IP TTL-expiration category. This profile does not add a YANG identity to that model. When both representations are used, exporters and consumers MUST preserve the same primary cause and MUST NOT sum a parent aggregate, a reason-specific count, and another representation of that count as distinct discards. 2. Requirements Language 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. 3. Deadline Evidence and Comparison An enforcing Observation Point is the point at which the device makes the final decision not to forward or locally deliver the packet copy. Transferring a packet to another internal queue or processing path is not a discard. The Metering Process MUST obtain the final decision from the enforcing point, directly or through a source that preserves its attribution. An external monitor's failure to see a packet is insufficient. Li, et al. Expires 3 May 2027 [Page 3] Internet-Draft IPFIX Latency-Budget Discard IEs October 2026 The deadline budget B is a non-negative duration from a defined reference event for the packet to the latest permitted event under the enforced policy. The configured context MUST identify that reference event, the enforcement event, the budget source, and the clock interpretation. For a residence-time policy these can be local ingress and the decision to release or discard the packet. The budget is inclusive: equality is within budget. A deadline discard requires strictly greater elapsed time. Let e be the non-negative measured elapsed time from the reference event to the deadline decision, and u a conservative upper bound on the absolute error of e. The deadline-expired reason MUST be used only if the enforcing point actually discarded the packet because the deadline had expired, the measurement context is known, and e - u > B. All three conditions are necessary. The bound MUST include timestamp error, quantization, clock drift over the measured interval, clock-domain conversion, and conversion or rounding error. A statistical confidence interval MUST NOT substitute for this bound. The reference timestamp can originate at another node only if its provenance, time scale, and inter-clock error bound are established. A nominal synchronization state or timestamp resolution alone is insufficient. Unknown, invalid, or unbounded uncertainty MUST NOT be encoded or interpreted as zero. A clock step, ambiguous timestamp wrap, or lost clock mapping that invalidates the elapsed-time evidence MUST suspend use of this reason until the evidence is valid again. The comparison MUST use exact or conservatively bounded arithmetic. Unsigned subtraction, addition of B and u, unit conversion, or timestamp subtraction MUST NOT wrap, saturate, or lose precision in a way that changes the decision. If the comparison cannot be established safely, no expiry assertion is permitted. For integral non-negative durations in a common unit, first checking e > B and then e - B > u avoids both subtraction underflow and B + u overflow. An implementation MUST NOT evaluate the subtraction before its guard. If e is rounded down to integral nanoseconds, and u is rounded up, this guarded test is conservative; a fractional B MUST NOT be rounded to invent a different policy for the profile. Mathematical condition: e - u > B Integer implementation (short-circuit evaluation): expired = (e > B) and ((e - B) > u) Equality, unknown u, invalid time basis: no expiry assertion Li, et al. Expires 3 May 2027 [Page 4] Internet-Draft IPFIX Latency-Budget Discard IEs October 2026 4. Primary Cause and Accounting Unit For each actual discard, the exporter MUST select one primary reason from the actual enforcement decision. If multiple discard conditions are present, the implementation MUST document their decision precedence and make that precedence available to the operator. A packet rejected by an ACL retains the ACL reason even if it was also late. If the primary cause cannot be determined, the exporter MUST NOT select deadline expiration merely because its timing test succeeds. Queue exhaustion, a policer decision, IP TTL or Hop Limit exhaustion, admission denial, and predicted inability to meet a future deadline MUST NOT use the new reason. Nor may it describe a late packet that was forwarded. Missing evidence changes what can be asserted, not the packet's treatment. An actual drop whose cause cannot be resolved MAY be reported using the existing generic dropped status under ordinary IPFIX rules. The accounting unit is one packet copy actually discarded at one enforcing Observation Point. Multiple notifications about that same local discard MUST contribute only one increment. A telemetry mirror or exported packet sample is not another service packet: discarding that observation copy MUST NOT be reported as discarding the observed traffic. Replicas intentionally carried on separate service branches are distinct packet copies; their local discard counts MUST NOT be summed and labeled as original packets lost end to end. Establishing original-packet loss requires a separately defined source population and correlation across replicas. Counting under this profile MUST be exhaustive for the configured population at the enforcing point. Sampled, statistically scaled, or inferred counts MUST NOT be presented as profile counts. A loss of meter notifications or counter coverage invalidates the affected complete interval, even if IPFIX export transport is reliable. The exporter MUST NOT emit a complete-profile record spanning missing observations or a period when required timing evidence was invalid. It can close a shorter fully observed interval at a known boundary; otherwise it must use reporting outside this profile. Excluded time periods MUST remain visible as coverage gaps, including when no qualifying discard was observed. Li, et al. Expires 3 May 2027 [Page 5] Internet-Draft IPFIX Latency-Budget Discard IEs October 2026 5. Data Records and Scope A complete-profile Data Record MUST contain exactly one top-level occurrence of each field in Table 1. Fields MUST be identified by their Information Element identity, including enterprise identity where applicable, rather than Template position. Separate Options Records or structured-data nesting MUST NOT substitute for these fields in this profile. +==========================================+===========+======+ | Information Element | ElementId | Type | +==========================================+===========+======+ | observationPointId | 138 | U64 | +------------------------------------------+-----------+------+ | flowId | 148 | U64 | +------------------------------------------+-----------+------+ | forwardingStatus | 89 | U32 | +------------------------------------------+-----------+------+ | droppedPacketDeltaCount | 133 | U64 | +------------------------------------------+-----------+------+ | monitoringIntervalStartMilliSeconds | 359 | DTms | +------------------------------------------+-----------+------+ | monitoringIntervalEndMilliSeconds | 360 | DTms | +------------------------------------------+-----------+------+ | deadlineBudgetNanoseconds | TBD-IE1 | U64 | +------------------------------------------+-----------+------+ | deadlineComparisonUncertaintyNanoseconds | TBD-IE2 | U64 | +------------------------------------------+-----------+------+ Table 1: Required Data Record Fields In Table 1, U64 denotes unsigned64, U32 denotes unsigned32, and DTms denotes dateTimeMilliseconds. These abbreviations do not change the IPFIX abstract data types. The Observation Domain ID in the IPFIX Message Header and observationPointId identify the enforcing observation scope. flowId identifies a Flow within that Observation Domain. The configured Flow definition MUST specify direction, packet-selection keys, and any branch or interface distinction needed to identify the counted population. This profile further partitions that population by primary reason, budget, and reference-event interpretation. Each partition MUST have a distinct flowId with independent delta accounting. Additional Flow Key fields MAY be included. A policy change MUST close the affected old partition before opening a new one. Li, et al. Expires 3 May 2027 [Page 6] Internet-Draft IPFIX Latency-Budget Discard IEs October 2026 droppedPacketDeltaCount counts qualifying discards of this Flow since its previous report, or since the start of metering for its first report. The exporter MUST advance the accounting boundary once for each emitted delta. A record MUST NOT mix reasons, budgets, or reference-event interpretations, or include a cumulative count in this delta field. Different Templates do not create disjoint populations. An aggregate exported through another Template or management interface MUST NOT be added to these deltas if it includes the same events. The two monitoring-interval IEs give the absolute start and end of the metering interval represented by the delta. Start MUST be no later than end. Event membership MUST use non-overlapping intervals: the start is inclusive and the end is exclusive, and an event exactly on a boundary belongs to the new interval. The Metering Process MUST preserve this membership at its internal timing precision. Millisecond export labels can be equal for a short interval; they alone establish neither event order nor disjointness. Export Time and flowStart/flowEnd MUST NOT substitute for these monitoring boundaries. A zero delta is valid only for a fully observed interval with the profile enabled and a known, constant budget and measurement context. Its uncertainty field MUST carry a valid comparison-error bound applicable throughout that interval; it MUST NOT be obtained by taking the maximum of an empty set or by assuming zero error. Silence, missing data, or disabled metering MUST NOT be interpreted as a zero delta. The exporter MUST close a delta before its count would exceed unsigned64. It MUST NOT wrap or saturate the value and claim complete coverage. A reset of a source counter, Metering Process restart, unexplained counter decrease, or lost event state MUST close the affected accounting context. The exporter MUST NOT calculate a delta across an ambiguous discontinuity. A final complete pre-reset interval can be exported only if its boundary and count were preserved; otherwise that interval is incomplete. After an accounting discontinuity, metering MUST restart from a known boundary with a fresh flowId. An exporter MUST NOT reuse a flowId for a different population within the same Observation Domain during a Transport Session. If this cannot be ensured after restart, it MUST establish a new Transport Session and provision its context before profile export resumes. A monitoring wall-clock discontinuity likewise closes the old interval; subsequent records require a re- established time mapping and fresh accounting context. No new counter-generation IE is required. Li, et al. Expires 3 May 2027 [Page 7] Internet-Draft IPFIX Latency-Budget Discard IEs October 2026 6. Information Element Definitions 6.1. deadlineBudgetNanoseconds This unsigned64 quantity is the common inclusive deadline budget B, in nanoseconds, for the packet population reported by the record. Its reference and enforcement events are defined by the provisioned measurement context. It is a configured duration, not a timestamp, measured delay, or Flow lifetime. Zero denotes a real zero-duration budget. All values from 0 through 18446744073709551615 are valid quantities; no value denotes unavailable. A complete-profile record MUST carry the exact budget as an integral number of nanoseconds. A negative, fractional-nanosecond, or out-of- range budget MUST NOT be rounded, wrapped, or clamped into a profile value. The exporter MUST use other reporting when the budget is unrepresentable. 6.2. deadlineComparisonUncertaintyNanoseconds This unsigned64 quantity is an upper bound, in nanoseconds, on the absolute error of the elapsed-time evidence used for deadline classification. For a nonzero delta it is the maximum of the valid per-packet bounds used for its members. For a zero delta it is a valid bound applicable throughout the monitored interval, as specified in Section 5. It describes the comparison at the enforcing point, not the configured budget's accuracy, the accuracy of the packet count, or the monitoring timestamps. The exporter MUST round each per-packet bound upward to integral nanoseconds and use that conservative bound in the expiration test before aggregating. If the test then fails, the packet is not eligible. Zero is allowed only when a zero bound is justified. Every unsigned64 value, including the maximum, is a quantity rather than an unavailable sentinel. Unknown or unrepresentable uncertainty requires omission of this IE and therefore precludes a complete- profile record; it MUST NOT be replaced by zero or saturation. The aggregate bound does not allow a collector to repeat every per- packet comparison, because the elapsed times are not exported. Acceptance of an authenticated record is an assertion by the exporter, not independent proof of its clock calibration or discard decision. Li, et al. Expires 3 May 2027 [Page 8] Internet-Draft IPFIX Latency-Budget Discard IEs October 2026 6.3. Reuse of Existing Information Elements The registered Flow duration IEs describe first-to-last packet observation, and the path-delay IEs describe measured delay statistics. Neither is a configured deadline budget. absoluteError (IE 320) and relativeError (IE 321) concern error of an associated reported measured value; associating them with the budget or discard counter would misstate the measurement. This profile does not export the elapsed-time measurements themselves. Its uncertainty IE is restricted to their classification error bound. A future profile exporting the underlying measurements should reconsider reuse of absoluteError. Existing scopes, timestamps, and packet counters are retained; no generic identity, timestamp, or loss-counter IE is introduced. 7. Templates, Encoding, and Collection Before accepting a Template as this profile, a collector MUST have authenticated configuration associating the exporter identity, Transport Session, Observation Domain ID, and Template ID with this specification, the Flow definition, enforcement point, reference and enforcement events, budget source, clock interpretation, exhaustive metering mode, and discard precedence. It MUST also know how metering discontinuities and export-coverage gaps are signaled. These are managed-domain deployment prerequisites, not an in-band discovery protocol. An unknown context MUST NOT produce profile- qualified counts. Templates MUST be resolved within the correct Transport Session and Observation Domain. Withdrawal, replacement, or expiration of a Template MUST invalidate its profile association. A replacement or reused Template ID MUST be validated and associated anew before use. An unchanged periodic Template refresh does not reset metering or create a new delta. Session termination MUST invalidate retained Template and profile associations. Matching numeric identifiers in different sessions are not evidence of continuity. forwardingStatus retains the registered unsigned32 abstract type and the least-significant-octet layout specified in [RFC9710]. The new complete value, denoted TBD-DROP, consists of status bits 10 and the six-bit reason selected by IANA. TBD-DROP denotes the entire status octet, not just its reason bits. Exporters SHOULD use the one-octet reduced-size encoding of the current layout. Collectors MUST accept legal one- through four-octet encodings with the same value and zero higher octets. Nonzero higher bits do not describe this profile and MUST NOT be masked off to force acceptance. Li, et al. Expires 3 May 2027 [Page 9] Internet-Draft IPFIX Latency-Budget Discard IEs October 2026 The five unsigned64 fields in Table 1 use one through eight octets under the reduced-size encoding rules of [RFC7011]. The two dateTimeMilliseconds fields use exactly eight octets. Required fields MUST NOT use zero-length or variable-length encodings, and duplicate required fields are invalid even when their values agree. An enterprise-specific IE with the same numeric ElementId does not satisfy a required standard IE. Additional fields MAY be included and are processed using their valid Template definitions. A collector MUST check field identity, multiplicity, legal encoding lengths, record truncation, time-interval validity, the assigned forwarding value, and its provisioned context before publishing a profile-qualified count. It MUST NOT infer unknown fields from position or an unknown reason from nearby numeric assignments. Ordinary IPFIX processing can retain a generic dropped status without recognizing the reason. Invalid records MUST NOT contribute to the profile count; the collector SHOULD retain a bounded diagnostic. Base IPFIX Set lengths, padding, Template, and transport rules still apply. This profile adds no record-acknowledgment or replay protocol. IPFIX Sequence Numbers count exported Data Records; they are not globally unique record identifiers. Exporters MUST NOT replay an already- accounted delta as a new interval without an external reconciliation mechanism. Collectors MUST NOT deduplicate solely on equal count values, millisecond interval labels, or Template IDs. Conversely, a new session or a new Template does not make replayed events new events. Collectors MUST distinguish a valid received partial count from a complete interval total. Meter loss, ambiguous reset, export loss, unresolved replay, or loss of collector state MUST mark the affected coverage incomplete. They MUST NOT report an exhaustive total until event disjointness and complete metering and export coverage are established. An absence of IPFIX Sequence Number gaps alone does not prove meter completeness. A deployment SHOULD use reliable, authenticated, integrity-protected IPFIX transport permitted by [RFC7011]; confidentiality MUST also be provided where the deployment requires it. 8. Deployment and Acceptance A focused deployment consists of an existing network deadline enforcement function, a Metering Process attached to its final drop decision, an IPFIX Exporting Process, and an authorized collector. A local ingress reference avoids inter-node timestamp conversion, but still requires a justified local elapsed-time error bound. A source- to-enforcer budget additionally requires an authenticated source-time Li, et al. Expires 3 May 2027 [Page 10] Internet-Draft IPFIX Latency-Budget Discard IEs October 2026 interpretation and a valid inter-clock bound. An application timeout monitor cannot substitute for either arrangement. Before enabling profile-qualified reporting, an operator MUST establish the measurement and accounting configuration required above, including the behavior on clock invalidity, observation loss, reset, and export interruption. If a device supplies only sampled observations, an undifferentiated queue-drop count, or no justified timing bound, it MUST NOT claim conformance to this profile. The profile does not require that an otherwise incapable device acquire a new forwarding function. Deployment acceptance SHOULD compare independently retained enforcement decisions with exported records using controlled packet traffic. The comparison should cover on-time forwarding, equality, certain expiry, clock invalidity, competing reasons, replica and mirror handling, a policy change during a window, counter reset, export interruption, and Template reuse. It should reconcile each accepted delta to a disjoint set of actual local discards. At least two independently developed collectors should agree on values and rejection cases, including legal reduced-size encodings and reordered Template fields. A purely synthetic trace validates reporting logic; it does not establish the observability or performance of a production device. Acceptance should also measure metering overhead, export volume, and collector state at the intended Flow cardinality and reporting interval. If the instrumentation cannot preserve the defined coverage at that load, the deployment must lower the load or report incomplete coverage. No throughput, latency benefit, particular network-device implementation, or upper-layer application framework integration is implied by this specification. 9. Examples and Required Boundary Behavior The following cases illustrate the normative rules. Durations are in nanoseconds and the stated primary cause is assumed to be verified at the enforcing point. Li, et al. Expires 3 May 2027 [Page 11] Internet-Draft IPFIX Latency-Budget Discard IEs October 2026 +==================+=========================+======================+ | Case | Evidence | Required result | +==================+=========================+======================+ | Certain | B=1000, e=1012, u=5; | Eligible | | expiration | deadline caused discard | | +------------------+-------------------------+----------------------+ | Equal | B=1000, e=1005, u=5 | Not eligible | | boundary | | | +------------------+-------------------------+----------------------+ | Uncertainty | B=1000, e=1002, u=5 | Not eligible | | crosses | | | | boundary | | | +------------------+-------------------------+----------------------+ | Subtraction | B=0, e=1, u=2 | Not eligible; no | | underflow | | wrap | +------------------+-------------------------+----------------------+ | Addition | B=18446744073709551615, | Not eligible; do not | | overflow | e=B, u=1 | compute wrapping B+u | +------------------+-------------------------+----------------------+ | Zero budget | B=0, e=1, u=0; deadline | Eligible only with a | | | caused discard | justified zero error | | | | bound | +------------------+-------------------------+----------------------+ | Unknown | e=1200, B=1000; no | No expiry assertion; | | uncertainty | valid u | no fabricated zero | +------------------+-------------------------+----------------------+ | Different | ACL rejects an already | Retain ACL reason | | primary | late packet | | | cause | | | +------------------+-------------------------+----------------------+ | Forwarded or | No actual deadline- | Not eligible | | predicted | expired discard | | | miss | | | +------------------+-------------------------+----------------------+ | Duplicate | Two notifications of | One increment | | notification | one local discard | | +------------------+-------------------------+----------------------+ | Replica | Two service copies | Two local events; no | | discards | discarded on two | original-packet-loss | | | branches | assertion | +------------------+-------------------------+----------------------+ | Reset during | Final pre-reset count | Incomplete coverage; | | interval | not preserved | fresh accounting | | | | context | +------------------+-------------------------+----------------------+ Table 2: Classification and Accounting Cases Li, et al. Expires 3 May 2027 [Page 12] Internet-Draft IPFIX Latency-Budget Discard IEs October 2026 For 17 qualifying discards of a Flow with B=1000 ns and maximum valid comparison uncertainty 5 ns, one parsed record is shown below. The interval labels are absolute epoch milliseconds. All 17 events must individually have passed their own comparison before aggregation. TBD-DROP and the new IE identifiers are symbolic pending IANA allocation. observationPointId = 7 flowId = 42 forwardingStatus = TBD-DROP (complete status octet) droppedPacketDeltaCount = 17 monitoringIntervalStartMilliSeconds = 1793325600000 monitoringIntervalEndMilliSeconds = 1793325601000 deadlineBudgetNanoseconds = 1000 deadlineComparisonUncertaintyNanoseconds = 5 Eight-octet network-order encodings of quantities: count 17: 00 00 00 00 00 00 00 11 budget 1000: 00 00 00 00 00 00 03 e8 bound 5: 00 00 00 00 00 00 00 05 Profile conformance MUST be verified at both the IPFIX Exporter and Collector. The Exporter MUST preserve primary-cause precedence with IE 89 (forwardingStatus, Status 10b: Dropped) and enforce the clock- uncertainty comparison bound and zero-count uncertainty rule. The Collector MUST distinguish a verified zero-discard monitoring interval from missing export records, an unreceived Options Template, or a counter discontinuity. Conformance tests MUST include: (1) a packet simultaneously denied by access control and arriving after its deadline (which MUST be attributed to policy drop rather than deadline discard), (2) replicated packets discarded on individual branches, and (3) packets whose residence time falls within the clock uncertainty bound. 10. Security Considerations The security considerations of [RFC7011] apply. Forged or replayed discard telemetry can misdirect operational decisions. A collector MUST authenticate and authorize the exporter for the claimed Observation Point and protect the associated profile configuration. Reports received over unprotected transport MUST NOT be used as authoritative input to security-sensitive automated control. Reception of an old report does not make its measurement current. Authenticated export does not prove the truth of a timestamp, error bound, or discard reason. The enforcing implementation MUST validate the provenance and clock context of its timing inputs and reject invalid evidence for this profile. A malicious packet source must Li, et al. Expires 3 May 2027 [Page 13] Internet-Draft IPFIX Latency-Budget Discard IEs October 2026 not be able to supply an untrusted timestamp or budget that is reported as an authoritative policy without the policy's validation. Collectors MUST preserve unknown and incomplete states; they cannot reconstruct hidden per-packet timing evidence from aggregate fields. Flow identifiers, budgets, and timing quality can expose service activity and network design. Access MUST be restricted to authorized consumers, and operators SHOULD minimize retained per-flow detail and retention time. Parsers MUST bound Template, record, diagnostic, and buffering resources. Collectors MUST NOT wait indefinitely for missing context. This reporting profile grants no authority to change packet-discard policies. 11. IANA Considerations 11.1. Forwarding Status Reason IANA is requested to allocate one unassigned complete status value in the "Status 10b: Dropped" registry under "IP Flow Information Export (IPFIX) Entities" [IANA-IPFIX], using its existing Expert Review policy. The associated status is 10 (binary), and the reason occupies the low six bits, as specified in [RFC9710]. No existing assignment or registration policy is changed. +=================+=============================================+ | Registry column | Requested entry | +=================+=============================================+ | Binary | 10 rrrrrr (rrrrrr selected by IANA) | +-----------------+---------------------------------------------+ | Hex | TBD-DROP, the complete octet with status 10 | +-----------------+---------------------------------------------+ | Description | Deadline expired | +-----------------+---------------------------------------------+ | Reference | This document, Sections 3 and 4 | +-----------------+---------------------------------------------+ Table 3: Requested Forwarding Status Entry The meaning is an actual packet discard whose primary cause is certain expiration of its configured time budget under Section 3. It is distinct from IP TTL or Hop Limit expiration, uncertain timing, and predicted future infeasibility. This Internet-Draft selects no numeric value. Li, et al. Expires 3 May 2027 [Page 14] Internet-Draft IPFIX Latency-Budget Discard IEs October 2026 11.2. Information Element Registrations IANA is requested to allocate two Information Elements in the "IPFIX Information Elements" registry under "IP Flow Information Export (IPFIX) Entities", using the existing Expert Review policy and the guidelines in [RFC7013]. Both have status current, revision 0, range 0 through 18446744073709551615, and reference this document. Their registry descriptions are the definitions in Section 6.1 and Section 6.2, respectively. The registration date is the date of allocation. No new subregistry is requested. The Budget IE is named deadlineBudgetNanoseconds. The Uncertainty IE is named deadlineComparisonUncertaintyNanoseconds. +========================+=============+================+ | Property | Budget IE | Uncertainty IE | +========================+=============+================+ | ElementId | TBD-IE1 | TBD-IE2 | +------------------------+-------------+----------------+ | Abstract data type | unsigned64 | unsigned64 | +------------------------+-------------+----------------+ | Data type semantics | quantity | quantity | +------------------------+-------------+----------------+ | Units | nanoseconds | nanoseconds | +------------------------+-------------+----------------+ | Description and | Section 6.1 | Section 6.2 | | additional information | | | +------------------------+-------------+----------------+ Table 4: Requested Information Elements Registration policies use the terminology of [RFC8126]. The additions preserve existing IPFIX scopes, counters, and encoding rules; the rationale for two new quantities is given in Section 6.3. 11.3. Use Before Allocation Experimental implementations MUST NOT transmit an unassigned standard ElementId or forwardingStatus value as though IANA had allocated it. A private experiment MAY use enterprise-specific IEs under its legitimately assigned Private Enterprise Number with explicit collector configuration. Such an experiment must also carry any private deadline classification in an enterprise-specific IE; an enterprise IE does not create a private reason space inside standard forwardingStatus. Standard forwardingStatus can remain at its existing generic dropped value. This is a private experimental mapping, not wire interoperability with the future allocated profile. Li, et al. Expires 3 May 2027 [Page 15] Internet-Draft IPFIX Latency-Budget Discard IEs October 2026 12. References 12.1. Normative References [IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", September 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, . [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements", BCP 184, RFC 7013, DOI 10.17487/RFC7013, September 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9710] Boucadair, M. and B. Claise, "Simple Fixes to the IP Flow Information Export (IPFIX) Entities IANA Registry", RFC 9710, DOI 10.17487/RFC9710, February 2025, . 12.2. Informative References [DEADLINE-FWD] Peng, S., Du, Z., Basu, K., Cheng, Z., Yang, D., and C. Liu, "Deadline Based Deterministic Forwarding", Work in Progress, Internet-Draft, draft-ietf-detnet-deadline- based-forwarding-01, June 2026, . Li, et al. Expires 3 May 2027 [Page 16] Internet-Draft IPFIX Latency-Budget Discard IEs October 2026 [DISCARD-MODEL] Evans, J., Ed., Pylypenko, O., Ed., Haas, J., Kadosh, A., and M. Boucadair, Ed., "Information and Data Models for Packet Discard Reporting", Work in Progress, Internet- Draft, draft-ietf-opsawg-discardmodel-16, July 2026, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . Authors' Addresses Zhiqiang Li China Mobile Beijing China Email: lizhiqiangyjy@chinamobile.com Zongpeng Du China Mobile Beijing China Email: duzongpeng@chinamobile.com Junjie Wang Centec Shanghai China Email: wangjj@centec.com Wei Cheng Centec Shanghai China Email: chengw@centec.com Li, et al. Expires 3 May 2027 [Page 17] Internet-Draft IPFIX Latency-Budget Discard IEs October 2026 Ying Zhao Centec Shanghai China Email: zhaoying@centec.com Chunhao Zhao SAIA Shanghai China Email: chunhao.zhao@sh-aia.com Xun Sun Inesa Shanghai China Email: sunxun@inesa.com Li, et al. Expires 3 May 2027 [Page 18]