



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  |
   +----------+--------------+--------+--------+--------+--------+
   | <flow>   | 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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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, <https://www.rfc-editor.org/info/rfc9197>.

12.2.  Informative References

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <https://www.rfc-editor.org/info/rfc4303>.

   [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,
              <https://www.rfc-editor.org/info/rfc8126>.

   [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,
              <https://www.rfc-editor.org/info/rfc9326>.

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]
