IPFIX Export of Buffer Snapshots

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 29 April 2027.¶

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

Buffer measurements taken during a short congestion event can describe different resource sets and different sample instants. A collector receiving two records for one queue cannot treat them as evidence that two distinct queues were measured. Similarly, a complete transport stream cannot establish whether the device successfully read every object in its configured monitoring scope.¶

The interoperability problem addressed here is the interpretation of a multi-object snapshot between independently implemented IPFIX Exporting and Collecting Processes. This document defines a shared interpretation of object identity, acquisition counts, sampling span, and finalization. It uses the IPFIX protocol and information model [RFC7011] [RFC7012].¶

The proposed profile is appropriate when IPFIX is already the export channel and the receiver needs these snapshot properties. Deployments using an existing management interface with adequate grouping and timing semantics need not add another export protocol. Independent deployment demand for this profile remains to be established.¶

2. Requirements Language

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD 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. Terminology and Scope

IPFIX terms follow [RFC7011] and [RFC7012]. A buffer object is an egress queue, ingress priority group, shared buffer pool, or headroom pool with defined occupancy accounting. A snapshot scope is a finite set of distinct objects frozen at the start of one capture attempt.¶

N is the number of objects in the frozen scope. C is the number of distinct objects successfully captured before acquisition ends. D is the number of distinct object records accepted by the collector before final metadata. The metadata declares N and C; the collector derives D.¶

A snapshot is identified by (Transport Session, Observation Domain ID, snapshotId). A seal is the single final Snapshot Metadata Options Data Record. It closes the export of that identifier. Capture-complete is an exporter assertion that C equals N. Delivery-complete is a collector result that the sealed records are internally consistent and D equals C.¶

These properties are distinct from inventory-verified coverage, simultaneous sampling, measurement precision, and authenticity of the exporter. Neither counts nor transport reliability prove that a compromised exporter sampled the asserted objects.¶

Metering Process     Exporting Process       Collecting Process
freeze scope N       ordered TCP stream      buffer distinct keys
capture C objects -> object(k), ...       -> validate and count D
finalize metadata    metadata(k) [seal]   -> close k; emit result
                     next snapshot k+1      retain closed-ID floor

4. Object Identity and Accounting

Within one Transport Session and Observation Domain, the canonical key is (bufferObjectType, applicable interface index, bufferObjectIndex). For types without interface scope the interface component is absent. Indices need not be contiguous. Type and interface scope are part of the key; an object index alone is insufficient.¶

The exporter MUST ensure that each key denotes one resource and one accounting interpretation for the Transport Session. If a key is reassigned, an interface index is reused, or its accounting interpretation changes, the exporter MUST establish a new Transport Session before exporting the changed meaning. Adding or removing keys between snapshot scopes does not change the meanings of surviving keys.¶

Snapshot scope membership MUST be frozen before acquisition and MUST contain no duplicate keys. Every captured object MUST belong to that scope. N and C alone do not identify uncaptured objects. A collector requiring inventory-verified coverage MUST obtain an independently provisioned scope inventory, bind it to the relevant session and capture attempt, and compare the received keys with it. This profile does not transport that inventory or negotiate its version.¶

bufferOccupancyOctets is a gauge of currently accounted buffer storage, not a traffic counter, watermark, capacity, or threshold. bufferAccountingGranularity is the nonzero accounting quantum in octets. An exact cell counter with quantum G is exported as allocated cells multiplied by G. A quantum of one permits octet resolution but does not prove estimator accuracy. The approximateOccupancy flag qualifies an estimated measurement even when its quantum is one.¶

Each occupancy MUST be a multiple of its stated quantum. An estimator MUST be expressed in that same accounting unit and flagged approximate; the exporter MUST document its rounding and estimation method. Values that overflow unsigned64 MUST be omitted from acquisition, reducing C, rather than wrapped or saturated without qualification. Overlapping queue and pool measurements MUST NOT be summed unless an external accounting model establishes that the quantities are disjoint.¶

5. Capture Contract

At the start of each attempt the exporter MUST allocate a nonzero snapshotId greater than every previously allocated identifier in the same Transport Session and Observation Domain. Identifiers MUST NOT wrap or be reused. If monotonic allocation or object identity cannot be preserved after restart, the exporter MUST open a new session. Allocation need not be contiguous; identifier gaps MUST NOT be interpreted as a count of physical events or lost snapshots.¶

Acquisition MUST finish or terminate before any record for the snapshot is exported. Metadata and the captured object set MUST then remain immutable. The exporter MUST preserve 0 <= C <= N and set incompleteCapture if and only if C < N. C MUST NOT be reduced later to conceal an export-queue drop. Empty scopes are permitted: N=C=0 describes an empty selection, not successful observation of any resource.¶

Capture MUST NOT change live packet counters, queue admission, scheduling, ECN marking, PFC behavior, or discard policy. Implementations SHOULD bound capture work and export rate so observation does not materially impair forwarding. Trigger suppression and coalescing MAY occur before an attempt starts; their local policy MUST be documented.¶

6. Ordered IPFIX Export Profile

This profile MUST use IPFIX over TCP as specified in [RFC7011]. UDP and SCTP are outside this profile. Exporters and collectors MUST support TLS for IPFIX and SHOULD use mutually authenticated TLS 1.3 [RFC8446] on deployments that support it. Plain TCP is permissible only under a deployment security policy that supplies equivalent protection and access control.¶

The profile is configured out of band at both peers. It defines no new IPFIX version or transport negotiation. Before IANA assignment, experiments MUST use enterprise-specific IEs under an appropriate Private Enterprise Number and an explicitly agreed mapping. Symbolic TBD labels are not wire identifiers. An endpoint MUST NOT infer this profile solely from numeric experimental identifiers used by another enterprise.¶

7. Collector State and Validation

A collector MUST parse and process this profile in stream order even if internal workers run concurrently. For each Observation Domain it maintains a closed-ID floor F (initially zero), at most one active identifier K, and a bounded map of accepted object keys for K. F represents identifiers that MUST NOT be reopened. This requires no retained object cache for completed snapshots.¶

Before allocating state, the collector MUST enforce configured limits on sessions, Observation Domains per session, records and bytes per active snapshot, processing rate, and reassembly duration. It MUST NOT allocate memory proportional to an untrusted N or C. Limits and incomplete-result reasons MUST be exposed to the application.¶

For each accepted object, the collector MUST validate the type-specific interface rule, nonzero granularity, and occupancy divisibility by granularity. Identical duplicates are compared by decoded required fields and counted once; optional context is not part of the count. A duplicate with a different required value MUST invalidate the active snapshot. An unrecognized object type prevents interpreted delivery completeness; the collector MUST close that snapshot as unsupported and retire its identifier.¶

At a seal the collector MUST check C<=N, incompleteCapture==(C<N), the span/flag combinations in Section 5.1, and the C=0 timestamp rule. If D>C it MUST report invalid. If D<C it MUST report incomplete delivery. If D=C and all checks pass it MUST report delivery-complete. A seal received before its purported objects closes as incomplete; later records for it MUST NOT revive it.¶

Unknown trigger values are descriptive context and do not invalidate an otherwise well-formed snapshot. Unknown flag bits are semantic qualifications: the collector MAY report the structural D=C result, but MUST label the result unsupported-qualified and MUST NOT report unqualified delivery or acquisition completeness. This version has no negotiated extension that relaxes its validation rules.¶

A result MUST separately expose delivery status, exporter-asserted acquisition status (complete, partial, or empty scope), simultaneity/span, approximation, and any inventory verification. N>0,C=0 with valid metadata is complete delivery of a failed capture, never a report that N objects have zero occupancy. C=N without an inventory check is a source assertion plus consistency check, not independent proof of scope coverage.¶

Closed results are immutable under this profile. Records with k<=F are diagnostic violations and MUST NOT reopen, complete, or silently replace an archived result. A collector MAY terminate a session after such a violation. Finality applies to the accepted sealed prefix, not to the truthfulness of a peer that later violates the protocol. This explicit rule replaces indefinite post-delivery conflict retention.¶

8. Information Element Definitions

The following proposed IEs use the specification template of [RFC7012] and review guidance of [RFC7013]. All have status current and reference this document. IANA identifiers remain TBD until assigned. Units are taken from the existing IPFIX units registry; object counts use none, not a newly invented objects unit.¶

9. Flag Masks

snapshotFlags is encoded as an unsigned16 in network byte order. The numeric masks below are authoritative. If bits are displayed from most significant to least significant, masks 0x0008 through 0x0001 occupy displayed positions 12 through 15. This display convention does not follow from byte order alone.¶

For C=0, approximateOccupancy MUST be clear. For simultaneous C>0 capture the span MUST be zero. These rules make the defined flags and span mutually checkable without asserting anything about uncaptured objects.¶

10. Examples and Implementation Checks

A conforming implementation test SHOULD include two Observation Domains interleaving on one TCP stream, Template replacement rules, session restart with the same numeric snapshotId, timeout followed by a late seal, memory-cap exhaustion, unknown flags, malformed interface fields, and count overflow. Tests of the state machine alone do not demonstrate hardware capture accuracy or independent interoperability.¶

11. IANA Considerations

IANA is requested to register the ten IEs in Section 8 in the IPFIX Information Elements registry [IANA-IPFIX]. No existing IE allocation is changed. Numeric TBD values MUST NOT be transmitted as if assigned.¶

12. Security Considerations

The IPFIX security considerations in [RFC7011] apply. Occupancy and trigger reports can reveal workload timing, topology, and resource stress. Export destinations MUST be authorized. Implementations MUST support transport protection, apply access controls, and limit retention according to deployment policy. TLS authenticates a peer and protects its messages; it cannot make a compromised exporter truthful.¶

N, C, identifiers, and rate are untrusted inputs. The collector limits in Section 7 are mandatory. A peer can deliberately send a very large identifier, which retires smaller identifiers for that session; this affects only that authenticated session and Observation Domain. It MUST NOT affect another exporter or session. Replay from an earlier session MUST NOT be merged with current reassembly state.¶

The absence of a snapshot or an incomplete result MUST NOT be interpreted as absence of congestion. Trigger suppression, an overloaded exporter, and resource limits can bias the observations. Using the telemetry to drive control decisions requires independent safeguards; this document defines no automatic congestion-control response.¶

Authors' Addresses