Simple Two-Way Active Measurement Protocol (STAMP) Extension for Link CRC Error Measurement

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

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

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

                  T1                            T2
                 /                                \
        +-------+ Session-Sender Test Packet       +-------+
        |       | - - - - - - - - - - - - - - - -> |       |
        |  S1   |==================================|  R1   |
        |       |<- - - - - - - - - - - - - - - -  |       |
        +-------+    Session-Reflector Test Packet +-------+
                 \                                /
                  T4                            T3

      STAMP Session-Sender                STAMP Session-Reflector

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                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

• 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.¶

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

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

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

Acknowledgments

The author would like to thank Bertrand Duvivier for the discussion on the requirements.¶

Author's Address