| Internet-Draft | IPFIX PFC Telemetry | October 2026 |
| Dogra, et al. | Expires 29 April 2027 | [Page] |
Priority-based Flow Control (PFC) pauses Ethernet traffic by priority. This document defines two IP Flow Information Export (IPFIX) Information Elements and an Options Template record pattern for per-priority totals of received and transmitted PFC control frames.¶
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 (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.¶
[IEEE8021Q] specifies Priority-based Flow Control (PFC). [IEEE8023] specifies the PFC MAC Control frame format. A PFC frame contains a 16-bit class-enable vector and eight 16-bit pause-time fields, one for each priority. The lower eight vector bits select the corresponding pause-time fields. PFC applies to a physical link and a priority. It does not identify an IP Flow.¶
Existing IPFIX Information Elements identify Observation Points, physical interfaces, and observation times. They do not identify a PFC vector position or count PFC control frames for that position. This document defines only those missing elements.¶
The PFC counter Data Records defined in Section 6 carry pfcPriority and pfcControlFrameTotalCount. A collector can correlate these records with separately exported IPFIX Flow Records that describe traffic. The traffic Flow Records do not need to contain the new PFC Information Elements. This correlation requires a common device, physical interface, time, and known traffic-to-priority mapping. It cannot prove that a Flow caused PFC activity.¶
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.¶
Existing management interfaces can report PFC configuration, state, and counters. Their coverage depends on the supported data model and implementation. YANG-Push can report applicable operational data [RFC8641]. The IEEE PFC MIB [IEEE-PFC-MIB] defines interface counters for MAC Control request and indication primitives. [RFC8038] provides a mechanism to export those MIB objects through IPFIX.¶
This specification provides a common format for deployments that use existing IPFIX infrastructure. It uses IPFIX observation, interface, template, transport, and collector functions.¶
Each record identifies one Observation Point, one physical interface, one PFC priority, one direction, and one observation time. A received-frame record uses ingressPhysicalInterface (252). A transmitted-frame record uses egressPhysicalInterface (253). A record MUST NOT contain both physical-interface Information Elements.¶
For a physical interface that belongs to a Link Aggregation Group, the record MUST identify that member interface. An exporter MUST NOT use an aggregate Link Aggregation Group counter for this record.¶
pfcPriority contains an unsigned8 priority index n, with valid values from 0 through 7. The value n identifies bit n of the PFC class-enable vector and pause-time field n in a PFC frame. It is not a bitmap and does not contain the vector or a pause-time value. For example, a value of 3 identifies bit 3 and pause-time field 3.¶
An exporter MUST NOT substitute dot1qPriority (244) or an internal queue index for pfcPriority. A collector needs the applicable device, interface, and time-dependent mapping to correlate the priority with traffic. That mapping does not change the fixed association between bit n and pause-time field n.¶
For received frames, the source counts valid PFC frames observed from the link before local enablement, policy, or watchdog processing. For transmitted counts, the exporter MUST count only valid PFC frames that it can confirm were emitted on the link. An internal generation request does not prove transmission. Transmission does not prove peer reception or execution of the pause request.¶
The source MUST count every qualifying frame at the specified physical interface and Observation Point. An exporter MUST NOT substitute a count from a packet-sampled subset or an extrapolated estimate for pfcControlFrameTotalCount.¶
For each set class-enable bit, the source increments the counter for that priority once. It counts zero-quanta resume requests and non-zero pause or refresh requests. It does not increment a counter for a clear class-enable bit, regardless of the pause-time value. One frame can increment counters for multiple priorities. A collector MUST NOT report the sum of different priority counters as a count of unique wire frames.¶
A qualifying frame meets the MAC Control and PFC requirements in [IEEE8023] and [IEEE8021Q]: receive-validation requirements for received frames, or transmit-format requirements for transmitted frames. The exporter MUST NOT count frames that fail these requirements, including frames with a detected frame-check-sequence error or an incorrect MAC Control EtherType or PFC opcode. Reserved-field and pause-time-field treatment follows those IEEE specifications. This document defines no additional rejection rules. If the source cannot distinguish qualifying from non-qualifying frames, the exporter MUST NOT use that source for pfcControlFrameTotalCount.¶
| Name | Type | Semantics | Units |
|---|---|---|---|
| pfcPriority | unsigned8 | identifier | none |
| pfcControlFrameTotalCount | unsigned64 | totalCounter | frames |
Section 10 gives the complete definitions and registration requests.¶
An Options Template Record defines each PFC counter Data Record. All Scope Fields precede the non-Scope Fields, as [RFC7011] requires. Received and transmitted counters use separate Options Template Records. The two Options Template Records use different physical-interface fields.¶
| Role | Information Element | Requirement |
|---|---|---|
| Scope | observationPointId (138) | REQUIRED |
| Scope | ingressPhysicalInterface (252) for received, or egressPhysicalInterface (253) for transmitted | REQUIRED, exactly one |
| Scope | pfcPriority | REQUIRED |
| Data | observationTimeMilliseconds (323) | REQUIRED |
| Data | pfcControlFrameTotalCount | REQUIRED |
[RFC5477] defines observationTimeMilliseconds. Its value is the closest available time when the source counter was read. It is not the record export time.¶
The PFC Counter Record reports a total, not a copy of a PFC frame. It contains no class-enable vector or pause-time values. The total can include frames with different pause-time values and does not measure elapsed paused time.¶
pfcControlFrameTotalCount is the counter value at observationTimeMilliseconds. The counter starts at zero when its measurement source initializes. It counts independently of export. It wraps after 2^64 - 1, as the totalCounter semantic in Section 3.2.2 of [RFC7012] requires. A counter reset starts a new epoch at zero.¶
The required fields do not identify a counter reset or a counter epoch. An increase does not prove that no reset occurred. A decrease can result from a reset or a wrap. The observation time and IPFIX Transport Session do not establish epoch continuity.¶
The required PFC Counter Record does not provide the information needed for an exact interval count. A Collecting Process MUST NOT report an exact interval count from two readings without reliable information beyond the required fields. To report such a count, the Collecting Process MUST confirm that both readings refer to the same scoped counter instance. It MUST also confirm that no reset occurred and fewer than 2^64 increments occurred between the observation times. If these conditions hold, the interval count is the later value minus the earlier value, modulo 2^64. Otherwise, the interval count is unknown. A rate based on an unknown interval count is also unknown. This document does not define an epoch Information Element or a method to provide the additional information.¶
The fields listed in the PFC Counter Record table MUST occur exactly once in their specified roles, with exactly one of the two physical-interface Information Elements. The order of the listed Scope Fields and the order of the listed non-Scope Fields are not significant. Collecting Processes MUST accept Templates with additional Information Elements. They MUST also accept message streams with records from other Templates, as Section 9.2 of [RFC7013] requires.¶
Exporters follow [RFC7011] for Template lifecycle and field handling. Before IANA assigns Element IDs, experiments use enterprise-specific Information Elements under an appropriate Private Enterprise Number. The TBD values in this document are not wire values. Experiments that cross an administrative or implementation boundary SHOULD export Information Element Type Records, as Section 3.9 of [RFC5610] specifies. They can also communicate equivalent type information out of band.¶
If the source counter is narrower than 64 bits, the exporter MUST account for its wraps. It MUST distinguish a source reset from a wrap. The exported unsigned64 value must have the totalCounter behavior defined above. If the exporter cannot meet these requirements, it MUST NOT export that source as pfcControlFrameTotalCount.¶
A zero value is a valid counter reading. It does not prove that no qualifying frames occurred because the counter can wrap. A missing record gives no count. A collector MUST NOT treat a missing record as a zero value.¶
Reporting frequency controls export volume and time resolution for correlation. The number of physical interfaces, priorities, and directions also affects export volume. Operators SHOULD select an export path that remains available when PFC pauses the monitored priority.¶
The IPFIX security considerations in [RFC7011] and [RFC7012] apply. PFC telemetry can reveal physical topology, service-priority use, congestion hot spots, and workload timing. Exporters and Collecting Processes SHOULD authenticate one another. They SHOULD protect the confidentiality and integrity of the telemetry. They SHOULD apply appropriate authorization and retention controls. TLS or DTLS deployments MUST follow the current BCP 195 recommendations in [RFC9325].¶
Authentication of the IPFIX Transport Session authenticates the Exporting Process. It does not authenticate a counted PFC frame. An unauthorized peer can send a syntactically valid frame. A counter increase does not prove genuine congestion. High-impact remediation SHOULD require other operational evidence.¶
This document requests two new Information Elements from IANA. IANA is requested to register them in the "IPFIX Information Elements" registry [IANA-IPFIX]. The registrations follow [RFC7012] and [RFC7013]. Registry terminology follows [RFC9710]. IANA is requested to assign values from the unassigned Element ID range 128 through 32767. The RFC Editor is requested to replace TBD1 and TBD2 with these values. "This document" below refers to the resulting RFC.¶