IPPM Z. Li Internet-Draft Z. Du Intended status: Standards Track China Mobile Expires: 1 September 2026 W. Cheng J. Wang G. Zhang Centec Networks 28 February 2026 Packet-Triggered Statistics Reporting for In-situ OAM draft-li-ippm-ioam-packet-triggered-reporting-00 Abstract This document defines a packet-triggered statistics reporting extension for In-situ Operations, Administration, and Maintenance (IOAM). The extension specifies a 2-bit Cycle Identifier field that enables receiving nodes to trigger statistics reporting based on observed Cycle ID transitions in received packets. This document defines the Cycle ID field format, node processing procedures, and keepalive packet generation rules. 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 1 September 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. Li, et al. Expires 1 September 2026 [Page 1] Internet-Draft IOAM Packet-Triggered Reporting February 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Cycle ID Field Format . . . . . . . . . . . . . . . . . . . . 4 4.1. Cycle ID Value Definitions . . . . . . . . . . . . . . . 5 5. Encapsulating Node Procedures . . . . . . . . . . . . . . . . 5 5.1. Cycle ID Assignment . . . . . . . . . . . . . . . . . . . 5 5.2. Statistics Maintenance . . . . . . . . . . . . . . . . . 6 5.3. Statistics Reporting . . . . . . . . . . . . . . . . . . 6 5.4. Keepalive Packet Generation . . . . . . . . . . . . . . . 7 5.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 8 6. Transit Node Procedures . . . . . . . . . . . . . . . . . . . 8 6.1. Packet Processing . . . . . . . . . . . . . . . . . . . . 8 6.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 8 7. Decapsulating Node Procedures . . . . . . . . . . . . . . . . 9 7.1. State Maintenance . . . . . . . . . . . . . . . . . . . . 9 7.2. Report Triggering . . . . . . . . . . . . . . . . . . . . 9 7.3. Keepalive Packet Processing . . . . . . . . . . . . . . . 9 7.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 10 8. Cycle ID State Machine . . . . . . . . . . . . . . . . . . . 10 9. Manageability Considerations . . . . . . . . . . . . . . . . 11 9.1. Configuration Parameters . . . . . . . . . . . . . . . . 11 9.2. Monitoring and Statistics . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11.1. IOAM Option-Type Registry . . . . . . . . . . . . . . . 12 11.2. IOAM Cycle ID Flags Registry . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Processing Examples . . . . . . . . . . . . . . . . 13 A.1. Normal Operation . . . . . . . . . . . . . . . . . . . . 13 A.2. Keepalive Generation . . . . . . . . . . . . . . . . . . 14 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Li, et al. Expires 1 September 2026 [Page 2] Internet-Draft IOAM Packet-Triggered Reporting February 2026 1. Introduction In-situ Operations, Administration, and Maintenance (IOAM) [RFC9197] records operational and telemetry information within user data packets while they traverse a network path. Alternate marking methods for packet loss measurement rely on periodic color changes to delineate measurement intervals. This document specifies a packet-triggered reporting extension that uses a four-value Cycle Identifier (Cycle ID) field. Receiving nodes observe Cycle ID transitions in arriving packets and use these transitions to trigger statistics reporting. This document defines the Cycle ID field encoding, procedures for encapsulating and decapsulating nodes, and the generation of keepalive packets to maintain measurement continuity. The scope of this document is limited to the definition of the Cycle ID field and associated node behaviors. The transport of IOAM data and the encapsulation in specific protocols (e.g., IPv6, NSH, GRE) are outside the scope of this document. 1.1. 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. 2. Terminology This document uses the terminology defined in [RFC9197]. The following additional terms are used in this document: Cycle Identifier (Cycle ID): A 2-bit field that identifies the measurement interval to which a packet belongs. Valid values are 0, 1, 2, and 3. Keepalive Packet: A packet generated by the encapsulating node when no user data packets are transmitted during a measurement interval, ensuring at least one packet per interval reaches the decapsulating node. Encapsulating Node: The IOAM node that inserts the Cycle ID field into packets entering the IOAM domain. Decapsulating Node: The IOAM node that processes the Cycle ID field and triggers statistics reporting upon Cycle ID transitions. Li, et al. Expires 1 September 2026 [Page 3] Internet-Draft IOAM Packet-Triggered Reporting February 2026 Transit Node: An IOAM node that processes packets within the IOAM domain, updating statistics based on the Cycle ID. Measurement Interval: The time period associated with a single Cycle ID value during which packet statistics are accumulated. 3. Protocol Overview This section provides a non-normative overview of packet-triggered statistics reporting. The encapsulating node assigns a Cycle ID value (0-3) to each packet based on the current measurement interval. The Cycle ID value increments sequentially (0, 1, 2, 3, 0, ...) as measurement intervals advance. When the decapsulating node receives a packet with a Cycle ID different from the previously received Cycle ID, it triggers the reporting of statistics accumulated during the earlier interval. To ensure that statistics reporting is triggered even during periods of no user traffic, the encapsulating node generates keepalive packets when no user data packets have been transmitted during an interval transition. +---------------+ +---------------+ | Encapsulating | Cycle ID in IOAM Header | Decapsulating | | Node | ---------------------------> | Node | +---------------+ +---------------+ | | | 1. Assign Cycle ID | | 2. Maintain per-cycle counters | | 3. Generate keepalive if needed | | | | 1. Detect Cycle ID change | 2. Trigger stats report | 3. Update local Cycle ID Figure 1: Packet-Triggered Reporting Overview 4. Cycle ID Field Format The Cycle ID field is carried within the IOAM Option-Type header. The field format is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cycle ID |K| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Li, et al. Expires 1 September 2026 [Page 4] Internet-Draft IOAM Packet-Triggered Reporting February 2026 Figure 2: Cycle ID Field Format The fields are defined as follows: Cycle ID (2 bits): Identifies the measurement interval. Valid values are 0, 1, 2, and 3. The Cycle ID MUST increment sequentially modulo 4 (i.e., 0 -> 1 -> 2 -> 3 -> 0). K (Keepalive Flag, 1 bit): When set to 1, indicates that this packet is a keepalive packet. When set to 0, indicates a user data packet. The K flag MUST be set to 0 for user data packets. Reserved (29 bits): Reserved for future use. MUST be set to zero on transmission. MUST be ignored on reception. 4.1. Cycle ID Value Definitions The following Cycle ID values are defined: +=======+========+========================+ | Value | Binary | Description | +=======+========+========================+ | 0 | 00 | Measurement Interval 0 | +-------+--------+------------------------+ | 1 | 01 | Measurement Interval 1 | +-------+--------+------------------------+ | 2 | 10 | Measurement Interval 2 | +-------+--------+------------------------+ | 3 | 11 | Measurement Interval 3 | +-------+--------+------------------------+ Table 1: Cycle ID Values 5. Encapsulating Node Procedures This section specifies the normative procedures for encapsulating nodes. 5.1. Cycle ID Assignment The encapsulating node MUST maintain a current Cycle ID value for each IOAM flow. The encapsulating node MUST assign the current Cycle ID value to all packets belonging to that flow. The encapsulating node MUST increment the Cycle ID value at the beginning of each new measurement interval. The increment operation MUST be performed modulo 4: Li, et al. Expires 1 September 2026 [Page 5] Internet-Draft IOAM Packet-Triggered Reporting February 2026 new_cycle_id = (current_cycle_id + 1) mod 4 The duration of a measurement interval is a local configuration parameter. The default measurement interval duration is 1 second. Implementations SHOULD support configurable measurement interval durations in the range of 100 milliseconds to 60 seconds. 5.2. Statistics Maintenance The encapsulating node MUST maintain per-flow, per-Cycle-ID statistics counters. At minimum, the following counters MUST be maintained: * Packet count: The number of packets transmitted with each Cycle ID value * Byte count: The total bytes transmitted with each Cycle ID value The encapsulating node MUST maintain statistics for all four Cycle ID values (0, 1, 2, 3) simultaneously. +----------+--------------+--------+--------+--------+--------+ | Flow ID | Current | Cyc 0 | Cyc 1 | Cyc 2 | Cyc 3 | | | Cycle ID | Stats | Stats | Stats | Stats | +----------+--------------+--------+--------+--------+--------+ | | 0|1|2|3 | pkt/ | pkt/ | pkt/ | pkt/ | | | | byte | byte | byte | byte | +----------+--------------+--------+--------+--------+--------+ Figure 3: Per-Flow Statistics Structure 5.3. Statistics Reporting The encapsulating node MUST report statistics with a two-interval delay relative to the current Cycle ID. This delay ensures that all packets from a given interval have been processed before reporting. The reporting relationship is defined as follows: Li, et al. Expires 1 September 2026 [Page 6] Internet-Draft IOAM Packet-Triggered Reporting February 2026 +==================+================================+ | Current Cycle ID | Report Statistics for Cycle ID | +==================+================================+ | 0 | 2 | +------------------+--------------------------------+ | 1 | 3 | +------------------+--------------------------------+ | 2 | 0 | +------------------+--------------------------------+ | 3 | 1 | +------------------+--------------------------------+ Table 2: Statistics Reporting Schedule The reporting schedule MAY be expressed as: report_cycle_id = (current_cycle_id + 2) mod 4 5.4. Keepalive Packet Generation The encapsulating node MUST generate a keepalive packet when a Cycle ID transition occurs and no user data packets were transmitted during the ending interval. The encapsulating node MUST track whether at least one user data packet has been transmitted during each measurement interval. The encapsulating node SHOULD implement this tracking using a per-flow, per-Cycle-ID flag. Upon Cycle ID transition, if the tracking flag indicates no user data packets were transmitted during the ending interval, the encapsulating node MUST generate and transmit a keepalive packet with the following properties: * The Cycle ID field MUST be set to the ending interval's Cycle ID value * The K flag MUST be set to 1 * The packet SHOULD use a cached packet template from the flow, if available * The packet MAY be a minimal probe packet if no template is available Keepalive packets MUST NOT be counted in the packet statistics for packet loss calculation. Implementations MUST distinguish keepalive packets from user data packets in statistics counters. Li, et al. Expires 1 September 2026 [Page 7] Internet-Draft IOAM Packet-Triggered Reporting February 2026 5.5. Error Handling If the encapsulating node is unable to insert the Cycle ID field due to insufficient header space, the node MUST forward the packet without IOAM information and SHOULD increment an error counter. If the encapsulating node detects an invalid Cycle ID value in its local state (i.e., a value outside the range 0-3), the node MUST reset the Cycle ID to 0 and SHOULD log the error condition. 6. Transit Node Procedures This section specifies the normative procedures for transit nodes. 6.1. Packet Processing A transit node that supports packet-triggered reporting MUST perform the following operations for each received packet containing a Cycle ID field: 1. Parse the Cycle ID field from the IOAM header 2. Validate that the Cycle ID value is in the range 0-3 3. Update the statistics counter corresponding to the parsed Cycle ID value 4. Forward the packet according to normal forwarding procedures Transit nodes MUST NOT modify the Cycle ID field or the K flag. Transit nodes SHOULD NOT maintain timers for statistics reporting. Transit nodes MAY trigger local statistics reporting based on observed Cycle ID transitions, using the same procedures as decapsulating nodes. 6.2. Error Handling If a transit node receives a packet with an invalid Cycle ID value (outside the range 0-3), the node MUST forward the packet without updating statistics and SHOULD increment an error counter. If a transit node receives a packet with a malformed Cycle ID field (e.g., truncated header), the node SHOULD forward the packet according to local policy and MUST increment an error counter. Li, et al. Expires 1 September 2026 [Page 8] Internet-Draft IOAM Packet-Triggered Reporting February 2026 7. Decapsulating Node Procedures This section specifies the normative procedures for decapsulating nodes. 7.1. State Maintenance The decapsulating node MUST maintain the following per-flow state: * Last received Cycle ID: The Cycle ID value from the most recently received packet * Per-Cycle-ID statistics counters: Packet and byte counts for each of the four Cycle ID values * Initialization flag: Indicates whether the flow has received its first packet Upon receiving the first packet for a flow, the decapsulating node MUST set the initialization flag and record the received Cycle ID as the last received Cycle ID. The decapsulating node MUST NOT trigger statistics reporting for the first received packet. 7.2. Report Triggering For each received packet after initialization, the decapsulating node MUST compare the packet's Cycle ID with the last received Cycle ID. If the Cycle ID values differ, the decapsulating node MUST: 1. Trigger statistics reporting for the interval that ended two cycles before the newly received Cycle ID, calculated as: report_cycle_id = (received_cycle_id + 2) mod 4 2. Update the last received Cycle ID to the newly received value 3. Update the statistics counter for the newly received Cycle ID If the Cycle ID values are equal, the decapsulating node MUST update only the statistics counter for the current Cycle ID. 7.3. Keepalive Packet Processing When the decapsulating node receives a packet with the K flag set to 1, the node MUST: * Process the Cycle ID for report triggering as specified in Section 7.2 Li, et al. Expires 1 September 2026 [Page 9] Internet-Draft IOAM Packet-Triggered Reporting February 2026 * NOT include the keepalive packet in packet loss statistics * Optionally discard the packet after processing if no further forwarding is required 7.4. Error Handling If the decapsulating node receives a packet with an invalid Cycle ID value, the node MUST discard the Cycle ID information from that packet, MUST NOT trigger statistics reporting based on that packet, and SHOULD increment an error counter. If the decapsulating node detects a Cycle ID sequence gap (e.g., transition from 0 to 2, skipping 1), the node SHOULD log this condition and MAY trigger reporting for all skipped intervals. The specific behavior for sequence gaps is implementation-defined. 8. Cycle ID State Machine The Cycle ID transitions through four states in a fixed sequence. The state machine is defined as follows: Interval Timer Expiry +-----+ +-----+ | | +------------------> | | | 0 | | | 1 | | | <-+ | | +-----+ | +-----+ ^ | | | | Interval | Interval | | Timer | Timer | | Expiry | Expiry | | v +-----+ | +-----+ | | | | | | 3 | <-+ | 2 | | | +------------------> | | +-----+ Interval Timer +-----+ Expiry Figure 4: Cycle ID State Machine The Cycle ID value MUST transition in the sequence: 0 -> 1 -> 2 -> 3 -> 0 (repeating). No other transition sequences are valid. The transition from one Cycle ID value to the next MUST occur only at measurement interval boundaries as determined by the encapsulating node's local timer. Li, et al. Expires 1 September 2026 [Page 10] Internet-Draft IOAM Packet-Triggered Reporting February 2026 9. Manageability Considerations 9.1. Configuration Parameters Implementations supporting this specification SHOULD expose the following configuration parameters: * Measurement interval duration (default: 1 second, range: 100ms - 60s) * Keepalive generation enable/disable (default: enabled) * Per-flow statistics reporting destination * Error counter thresholds for alarming 9.2. Monitoring and Statistics Implementations SHOULD provide access to the following operational statistics: * Per-flow, per-Cycle-ID packet and byte counters * Keepalive packets generated (per flow) * Keepalive packets received (per flow) * Cycle ID errors detected * Cycle ID sequence gaps detected 10. Security Considerations The security considerations of [RFC9197] apply to this extension. The following additional considerations are specific to the Cycle ID mechanism. The Cycle ID field is a 2-bit value that indicates the measurement interval. An on-path attacker could modify the Cycle ID value, causing incorrect statistics reporting at the decapsulating node. Implementations operating outside a single administrative trust domain SHOULD protect IOAM data integrity using mechanisms such as those described in [RFC9197] Section 5. Li, et al. Expires 1 September 2026 [Page 11] Internet-Draft IOAM Packet-Triggered Reporting February 2026 The keepalive packet generation mechanism could be abused by an attacker who suppresses user data packets, causing the encapsulating node to generate keepalive packets continuously. Implementations SHOULD monitor keepalive generation rates and alert operators when abnormal patterns are detected. Statistics counters maintained by transit and decapsulating nodes are local state and are not exposed in the data plane. Access to these counters through management interfaces SHOULD be protected by authentication and authorization mechanisms. 11. IANA Considerations 11.1. IOAM Option-Type Registry This document requests IANA to allocate a new Option-Type from the "IOAM Option-Type" registry defined in [RFC9197]. +=======+======================+=================+ | Value | Description | Reference | +=======+======================+=================+ | TBD1 | IOAM Cycle ID Option | [This Document] | +-------+----------------------+-----------------+ Table 3: IOAM Option-Type Allocation Request 11.2. IOAM Cycle ID Flags Registry This document requests IANA to create a new registry titled "IOAM Cycle ID Flags" under the "In-situ OAM (IOAM)" registry group. The registry contains 1-bit flags. The initial contents of the registry are: +==============+======+================+=================+ | Bit Position | Name | Description | Reference | +==============+======+================+=================+ | 0 | K | Keepalive Flag | [This Document] | +--------------+------+----------------+-----------------+ Table 4: IOAM Cycle ID Flags Registry Future assignments in this registry require Standards Action [RFC8126]. 12. References 12.1. Normative References Li, et al. Expires 1 September 2026 [Page 12] Internet-Draft IOAM Packet-Triggered Reporting February 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, . 12.2. Informative References [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [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, . [RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T. Mizrahi, "In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting", RFC 9326, DOI 10.17487/RFC9326, November 2022, . Appendix A. Processing Examples This appendix provides non-normative examples of packet-triggered reporting behavior. A.1. Normal Operation Consider a flow with continuous traffic. The encapsulating node operates with a 1-second measurement interval: Li, et al. Expires 1 September 2026 [Page 13] Internet-Draft IOAM Packet-Triggered Reporting February 2026 Time (s) Cycle ID Encap Action Decap Action -------- -------- ------------------ ------------------ 0.0-1.0 0 Assign CID=0 Receive CID=0 Count packets Count packets (Initialize) 1.0-2.0 1 Assign CID=1 Receive CID=1 Count packets Trigger: report CID=3 (No data for CID=3) Count packets 2.0-3.0 2 Assign CID=2 Receive CID=2 Report CID=0 stats Trigger: report CID=0 Count packets Count packets 3.0-4.0 3 Assign CID=3 Receive CID=3 Report CID=1 stats Trigger: report CID=1 Count packets Count packets A.2. Keepalive Generation Consider a flow with intermittent traffic where no packets are transmitted during Cycle ID=1: Time (s) Cycle ID Traffic Encap Action -------- -------- -------- --------------------------- 0.0-1.0 0 Present Assign CID=0, count packets 1.0-2.0 1 None Generate keepalive (CID=1, K=1) 2.0-3.0 2 Present Assign CID=2, count packets Acknowledgements TBD Authors' Addresses Zhiqiang Li China Mobile 32 Xuanwumen West Street Beijing 100053 China Email: lizhiqiangyjy@chinamobile.com Zongpeng Du China Mobile 32 Xuanwumen West Street Li, et al. Expires 1 September 2026 [Page 14] Internet-Draft IOAM Packet-Triggered Reporting February 2026 Beijing 100053 China Email: duzongpeng@chinamobile.com Wei Cheng Centec Networks Suzhou 215000 China Email: chengw@centec.com Junjie Wang Centec Networks Suzhou 215000 China Email: wangjj@centec.com Guoying Zhang Centec Networks Suzhou 215000 China Email: zhanggy@centec.com Li, et al. Expires 1 September 2026 [Page 15]