IPPM Working Group R. Gandhi, Ed. Internet-Draft Cisco Systems, Inc. Intended status: Standards Track 25 October 2026 Expires: 28 April 2027 Simple Two-Way Active Measurement Protocol (STAMP) Extension for Link CRC Error Measurement draft-gandhi-ippm-stamp-link-crc-00 Abstract The Simple Two-Way Active Measurement Protocol (STAMP), specified in RFC 8762, supports active measurement of network performance. This document defines a STAMP Type-Length-Value (TLV) that reports receive-side link statistics: packets received, packets received with Cyclic Redundancy Check (CRC) errors, and bytes received. The link is identified using the Micro-session ID TLV specified in RFC 9534. These measurements support fiber-quality monitoring to provide SLA assurance. 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 28 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 Gandhi Expires 28 April 2027 [Page 1] Internet-Draft STAMP Link CRC Errors October 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.4. STAMP Reference Topology . . . . . . . . . . . . . . . . 4 3. Link CRC Statistics TLV . . . . . . . . . . . . . . . . . . . 5 4. STAMP Procedures . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Procedure for a Link Aggregation Group . . . . . . . . . 7 4.2. MTU Considerations . . . . . . . . . . . . . . . . . . . 7 4.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Operational Considerations . . . . . . . . . . . . . . . . . 8 5.1. Operational Data Model Parameters . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Networks may experience transmission bit errors due to various factors, such as poor fiber quality. Bit errors can be single-bit errors or occur in bursts. Bit errors in received packets can be detected using a Cyclic Redundancy Check (CRC) [RFC3819]. Forward Error Correction (FEC) may correct transmission errors before CRC validation. Packets that fail CRC validation may be discarded [RFC3819]. Even with efficient CRC and FEC mechanisms, some bit errors may escape detection and correction; these are referred to as residual bit errors [RFC3819]. These bit errors can cause checksum failures in upper-layer protocols such as UDP and TCP, resulting in packet drops. Using active measurement packets to retrieve CRC statistics for data traffic can help operators monitor link quality and provide SLA assurance. This is useful both before a link is deployed in a production network and after it has been deployed. Dark or lighted fiber, Ethernet Private Lines (EPLs), and other Layer 2 circuits are often leased from service providers and require independent quality monitoring. Gandhi Expires 28 April 2027 [Page 2] Internet-Draft STAMP Link CRC Errors October 2026 STAMP, specified in [RFC8762], transmits STAMP-Test packets between a Session-Sender and a Session-Reflector. STAMP packet loss indicates packets not received at the measurement endpoint, but does not identify the cause. CRC errors are one possible cause of loss; queue drops, congestion, other forwarding failures, checksum failures, and malformed packets can also contribute. Consequently, total packet loss experienced by data traffic can be greater than the number of packets reported with link CRC errors. This document defines a STAMP TLV for reporting receive-side CRC statistics associated with a link. The link measured by a STAMP-Test packet is identified using the Micro-session ID TLV and procedures specified in [RFC9534]. The CRC statistics are obtained from the receiving node's link-layer counters for that identified link. The use cases are: * On an active link, CRC statistics for incoming data traffic are obtained from the link's receive counters. Small STAMP-Test packets without the Extra Padding TLV can be sent to solicit the peer's Link CRC Statistics TLV. * On a backup link without customer data traffic, CRC measurements are performed using STAMP-Test packet traffic. Large STAMP-Test packets with the Extra Padding TLV are sent to exercise the link. 2. Conventions and Terminology 2.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.2. Terminology This document uses the terms Session-Sender, Session-Reflector, STAMP-Test packet, and STAMP TLV as defined in [RFC8762] and [RFC8972]. It uses Micro-session ID TLV as defined in [RFC9534]. Gandhi Expires 28 April 2027 [Page 3] Internet-Draft STAMP Link CRC Errors October 2026 2.3. Abbreviations +==============+===========================+===========+ | Abbreviation | Meaning | Reference | +==============+===========================+===========+ | CRC | Cyclic Redundancy Check | [RFC3819] | +--------------+---------------------------+-----------+ | EPL | Ethernet Private Line | [RFC8214] | +--------------+---------------------------+-----------+ | LAG | Link Aggregation Group | [RFC9534] | +--------------+---------------------------+-----------+ | MTU | Maximum Transmission Unit | [RFC3819] | +--------------+---------------------------+-----------+ | STAMP | Simple Two-Way Active | [RFC8762] | | | Measurement Protocol | | +--------------+---------------------------+-----------+ | TLV | Type-Length-Value | [RFC8972] | +--------------+---------------------------+-----------+ Table 1: Abbreviations 2.4. STAMP Reference Topology The STAMP Session-Sender S1 initiates Session-Sender STAMP-Test packets, and the STAMP Session-Reflector R1 transmits the corresponding Session-Reflector STAMP-Test packets, as illustrated in Figure 1. T1 T2 / \ +-------+ Session-Sender Test Packet +-------+ | | - - - - - - - - - - - - - - - -> | | | S1 |==================================| R1 | | |<- - - - - - - - - - - - - - - - | | +-------+ Session-Reflector Test Packet +-------+ \ / T4 T3 STAMP Session-Sender STAMP Session-Reflector Figure 1: STAMP Reference Topology T1 is the transmit timestamp and T4 is the receive timestamp added by S1. T2 is the receive timestamp and T3 is the transmit timestamp added by R1. Gandhi Expires 28 April 2027 [Page 4] Internet-Draft STAMP Link CRC Errors October 2026 3. Link CRC Statistics TLV This document defines the "Link CRC Statistics" TLV (Type=TBD). Its Value is exactly 12 octets and contains three unsigned 32-bit counters in network byte order. The TLV uses the STAMP TLV Flags, Type, and Length fields specified in [RFC8972]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| Type=TBD | Length=12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packets Received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packets Received with CRC Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bytes Received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Link CRC Statistics TLV The fields of the Link CRC Statistics TLV are defined as follows: * STAMP TLV Flags: The flags are used as specified in [RFC8972]. Before transmission, the Session-Sender MUST set the U (Unrecognized) flag to 1 and the M (Malformed) flag to 0. * Type: MUST be set to TBD. * Length: A two-octet field set to 12, indicating that the Value field is 12 octets long. The Session-Sender MUST set the M (Malformed) flag to 0 before transmission. If a Session-Reflector receives this TLV with a Length field value other than 12, it MUST treat the TLV as malformed, set the M flag in the reflected TLV to 1, stop processing extension TLVs, and copy the remainder of the received extended STAMP packet into the reflected packet, following the procedures in Section 4 of [RFC8972]. * Packets Received: The least significant 32 bits of the cumulative count of packets received on the identified link, including packets reported by the link with CRC errors. * Packets Received with CRC Errors: The least significant 32 bits of the cumulative count of packets received on the identified link and reported by the link as having CRC errors. Gandhi Expires 28 April 2027 [Page 5] Internet-Draft STAMP Link CRC Errors October 2026 * Bytes Received: The least significant 32 bits of the cumulative count of octets received on the identified link, including frames reported with CRC errors. The three fields are snapshots of the identified link's cumulative receive counters, sampled at the same time. These counters MUST NOT be reset when the Session-Sender requests or retrieves the TLV. Setting the three counter fields to zero in a request applies only to the fields in that STAMP-Test packet and does not reset the underlying link counters. If a hardware or software counter has a wider range than 32 bits, the value in the TLV is the least significant 32 bits of that counter. A management system MUST calculate interval totals from successive snapshots and account for counter wraparound. The sample time and computation interval MUST be available to the operational data consumer. The CRC counters represent errors reported by the receiving link and are distinct from packet loss measured by STAMP. They do not include packets discarded for reasons other than a reported link CRC error. 4. STAMP Procedures The Link CRC Statistics TLV is carried in STAMP-Test packets as an optional TLV using the procedures in [RFC8972]. A packet MUST NOT contain more than one Link CRC Statistics TLV. The Session-Sender MUST set the three counter fields to 0 in every transmitted request TLV. When a STAMP-Test packet measures a specific member link, the Session-Sender MUST include a Micro-session ID TLV and follow the procedures specified in [RFC9534]. The Sender and Reflector Micro- session IDs identify the respective links; the link on which the Session-Reflector receives the packet is the link whose counters it reports. The Session-Reflector MUST associate the received measurement packet with the link identified by the Micro-session ID. The Session-Reflector MUST update the three counter fields in the reflected Link CRC Statistics TLV with snapshots of the cumulative receive counters for the identified local link for packets received from the Session-Sender. It MUST sample all three counters at the same time. If the Session-Reflector cannot retrieve all three counters for the identified link, it MUST set all three counter fields to 0 in the reflected TLV. A Session-Sender that receives the TLV can use the values to report the Session-Reflector's receive statistics. Gandhi Expires 28 April 2027 [Page 6] Internet-Draft STAMP Link CRC Errors October 2026 When the Session-Reflector does not recognize the TLV, it MUST set the Unrecognized (U) flag as specified in [RFC8972]. A Session- Sender receiving the TLV with the U flag set MUST treat the CRC statistics as unsupported and MUST NOT use the TLV values as valid measurements. 4.1. Procedure for a Link Aggregation Group CRC statistics can differ among the member links of a Link Aggregation Group (LAG). To measure each member separately, a STAMP micro-session is established for each member link. The Micro-session ID TLV specified in [RFC9534] identifies the sender-side and reflector-side member links associated with each micro-session. CRC statistics are reported for each member based on STAMP-Test packets received by the Session-Reflector. The Session-Sender MUST transmit each micro-session's STAMP-Test packets over its associated member link. If the Reflector Micro- session ID is non-zero, the Session-Reflector MUST use it to validate the member link on which the packet was received. If it is zero, the Session-Reflector does not validate the received member link using that field, as specified in [RFC9534]. The Session-Reflector replies over the reflector-side member link associated with the micro- session. That association is determined using the received STAMP- Test packet and local micro-session configuration or the data-plane interface on which the packet arrived, as specified in [RFC9534]. The Session-Sender MUST validate the returned Sender Micro-session ID and MUST validate the Reflector Micro-session ID when it is non-zero. 4.2. MTU Considerations As specified in [RFC8972], Session-Sender and Session-Reflector STAMP-Test packets are symmetric in size. After adding STAMP TLVs, the Session-Sender and Session-Reflector MUST adjust the size of the padding data to ensure that the resulting packets do not exceed the link MTU. Information about the link MTU may be configured, collected through management protocols, or distributed by control protocols. The mechanisms to learn the link MTU are outside the scope of this document. 4.3. Use Cases The packet-generation approach for each use case is as follows: * For an active link, CRC measurements are obtained from the link's receive counters for data traffic. The Session-Sender can send small STAMP-Test packets without the Extra Padding TLV to solicit the peer's current Link CRC Statistics TLV. Gandhi Expires 28 April 2027 [Page 7] Internet-Draft STAMP Link CRC Errors October 2026 * For a backup link without customer data traffic, CRC measurements are performed using STAMP-Test packet traffic. The Session-Sender can use the Extra Padding TLV defined in [RFC8972] to send large STAMP-Test packets that match, but do not exceed, the link MTU. For a LAG, the packet size SHOULD match, but MUST NOT exceed, the MTU of the selected member link. The large-sized padded STAMP-Test packets may be dropped because of CRC errors, therefore, small unpadded STAMP-Test packets can be used to retrieve the counters. 5. Operational Considerations The operational considerations specified in [RFC8762] apply to the procedure and extensions defined in this document. Additional operational considerations are specified in the following subsections. 5.1. Operational Data Model Parameters The operational data model for CRC measurement using STAMP MUST allow reporting the following parameters for STAMP-Test packets received by the Session-Reflector: * Total number of packets received on the identified link during the computation interval. * Total number of packets received with CRC errors on the identified link during the computation interval. * Total number of bytes received on the identified link during the computation interval. The computation interval and the identity of the Session-Reflector receive link MUST be available to a consumer of the operational data. The reported interval totals are calculated from the counter increments observed during that interval, accounting for counter wraparound as necessary. For the Session-Reflector's receive measurements, the operational data model SHOULD allow reporting average, maximum, minimum, and exponential moving average (EMA) CRC metrics over a configurable computation interval. The metric definition, sampling interval, and EMA parameters MUST be made available to the consumer. If a rate is reported, it MUST be calculated from the CRC-error packet count and total packet count for the same interval. Gandhi Expires 28 April 2027 [Page 8] Internet-Draft STAMP Link CRC Errors October 2026 Thresholds MAY be configured for the number of packets with CRC errors and for the number of packets with CRC errors per million packets received by the Session-Reflector. When a computed metric crosses a user-configured threshold, an alarm MAY be generated and event-driven telemetry MAY be triggered. For a LAG, CRC statistics SHOULD be computed and reported separately for each member link. 6. Security Considerations The security considerations specified in [RFC8762] and [RFC8972] apply. Implementations SHOULD authenticate STAMP packets when the measurement environment requires protection against modification or injection. CRC counter values reveal operational information about a link and SHOULD be protected according to the deployment's security policy. 7. IANA Considerations IANA is requested to assign a value to the "Link CRC Statistics" TLV from the IETF Review range of the "STAMP TLV Types" registry under the "Simple Two-way Active Measurement Protocol (STAMP) TLV Types" registry group, as shown in Table 2. +=======+=====================+===============+ | Value | Description | Reference | +=======+=====================+===============+ | TBD | Link CRC Statistics | This document | +-------+---------------------+---------------+ Table 2: STAMP TLV Type 8. References 8.1. Normative References [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, . Gandhi Expires 28 April 2027 [Page 9] Internet-Draft STAMP Link CRC Errors October 2026 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, . [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, "Simple Two-Way Active Measurement Protocol Optional Extensions", RFC 8972, DOI 10.17487/RFC8972, January 2021, . [RFC9534] Li, Z., Zhou, T., Guo, J., Mirsky, G., and R. Gandhi, "Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group", RFC 9534, DOI 10.17487/RFC9534, January 2024, . 8.2. Informative References [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, DOI 10.17487/RFC3819, July 2004, . [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. Rabadan, "Virtual Private Wire Service Support in Ethernet VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, . Acknowledgments The author would like to thank Bertrand Duvivier for the discussion on the requirements. Author's Address Rakesh Gandhi (editor) Cisco Systems, Inc. Canada Email: rgandhi@cisco.com Gandhi Expires 28 April 2027 [Page 10]