IPFIX Information Elements for Priority-based Flow Control Telemetry

Introduction specifies Priority-based Flow Control (PFC). 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 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.

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 when, and only when, they appear in all capitals, as shown here.

Applicability 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 . The IEEE PFC MIB defines interface counters for MAC Control request and indication primitives. 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.

PFC Counter Observation Model

Scope and Direction 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.

Priority Semantics 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.

Control-Frame Count Semantics 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 and : 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.

New Information Elements PFC Information Elements

Name	Type	Semantics	Units
pfcPriority	unsigned8	identifier	none
pfcControlFrameTotalCount	unsigned64	totalCounter	frames

gives the complete definitions and registration requests.

Export Model An Options Template Record defines each PFC counter Data Record. All Scope Fields precede the non-Scope Fields, as requires. Received and transmitted counters use separate Options Template Records. The two Options Template Records use different physical-interface fields. PFC Counter Record

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

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 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 requires.

Export Requirements Exporters follow 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 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.

Operational Considerations 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.

Security Considerations The IPFIX security considerations in and 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 . 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.

IANA Considerations This document requests two new Information Elements from IANA. IANA is requested to register them in the "IPFIX Information Elements" registry . The registrations follow and . Registry terminology follows . 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.

pfcPriority

Name:: pfcPriority
Element ID:: TBD1
Description:: A priority index n in the range 0 through 7. The value n identifies bit n of the Priority-based Flow Control class-enable vector and pause-time field n in a PFC frame. This value is not a bitmap. It contains neither the vector nor a pause-time value. It does not identify an IEEE 802.1Q tag Priority Code Point or an internal queue.
Abstract Data Type:: unsigned8
Data Type Semantics:: identifier
Units:: none
Range:: 0-7
Status:: current
Additional Information:: See , Annex 31D, and , Clause 36.
Reference:: This document

pfcControlFrameTotalCount

Name:: pfcControlFrameTotalCount
Element ID:: TBD2
Description:: The total number of qualifying PFC MAC Control frames for one PFC priority, as defined in . The containing Data Record identifies the priority. The counter increments when that priority's class-enable vector bit is one. It counts frames with zero and non-zero pause-time values. One frame can increment counters for multiple priorities. It represents complete qualifying-frame counting, not a count from a packet-sampled subset or an extrapolated estimate. It does not contain pause-time values. In the PFC Counter Record defined in , the physical-interface Information Element identifies received or transmitted direction.
Abstract Data Type:: unsigned64
Data Type Semantics:: totalCounter
Units:: frames
Status:: current
Additional Information:: See , Annex 31D.
Reference:: This document