Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Bit Error Detection and Bit Error Rate 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 18 October 2025.¶

Copyright Notice

Copyright (c) 2025 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

The Simple Two-Way Active Measurement Protocol (STAMP) is designed to measure various performance metrics in IP networks without relying on a control channel to pre-signal session parameters, as specified in [RFC8762]. STAMP test packets are sent between a Session-Sender and a Session-Reflector to measure delay and packet loss along the path.¶

[RFC8972] introduces optional extensions for STAMP in the form of Type-Length-Value (TLV) objects, including the capability to transmit "Extra Padding Data" within STAMP test packets.¶

Networks may experience transmission bit errors due to various factors, such as poor fiber quality. The bit error can be a single bit error or a burst of bit errors at a time. It is beneficial to detect bit errors and measure the bit error rate (BER) using active measurement packets between two nodes. For accurate bit error detection, transmitting large-sized active measurement packets is preferable, especially on links with low bit error rates. Furthermore, there is a need to transmit test packets at a high rate to detect bit errors on high-capacity links.¶

The STAMP test packets use a UDP header with a checksum field that may be used for checking the integrity of the header and data. The UDP checksum is optional for the IPv4 header and may be set to 0 for the IPv6 header for the STAMP destination UDP port. However, the checksum field does not provide an accurate measurement of bit errors.¶

Authenticated mode provides data integrity protection for the STAMP test packets by adding a Hashed Message Authentication Code (HMAC), such as HMAC-SHA-256 [RFC8762]. However, the authenticated mode does not provide an accurate measurement of bit errors. In addition, the HMAC TLV defined in [RFC8972] for authenticating STAMP TLVs does not include checking the "Extra Padding Data" TLV.¶

This document further augments the STAMP extensions defined in [RFC8972] to enable the detection of bit errors and the measurement of BER within the "Extra Padding Data" of STAMP packets.¶

2. Conventions Used in This Document

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

  STAMP Session-Sender                     STAMP Session-Reflector

3. Overview

The optional extensions for STAMP test packets [RFC8762] are defined in [RFC8762] in the form of TLVs. The Session-Sender transmits optional STAMP TLVs, and the Session-Reflector reflects all received STAMP TLVs from the Session-Sender test packets. [RFC8972] defines an optional TLV extension specifically for transmitting "Extra Padding Data" (Type=1) in the STAMP test packets. The "Extra Padding Data" can be filled using either a predefined fixed pattern or a random pattern of bits [RFC8972].¶

This document defines a procedure to detect bit errors within the "Extra Padding Data" TLV. The process involves the Session-Sender transmitting the extra padding data filled with a predefined bit pattern. The Session-Reflector then checks for bit errors by comparing the received data against the predefined bit pattern. This allows for the detection of a single bit error or a burst of bit errors and the accurate measurement of the bit error rate. The Session-Reflector does not discard the STAMP test packet with bit errors but instead reflects it back to the Session-Sender after correcting the errors. The Session-Reflector also returns the bit error count to the Session-Sender.¶

Bit errors can be detected in both the forward and reverse directions between the Session-Sender and the Session-Reflector using the procedure and extensions defined in this document. The bit error rate is computed as the ratio of the number of bit errors detected to the number of bits transmitted in the extra padding data.¶

As specified in [RFC8972], the Session-Sender and Session-Reflector test packets are symmetric in size. The Session-Sender and Session-Reflector MUST ensure that the resulting test packets do not exceed the path MTU after adding the STAMP TLVs.¶

Note that the procedure and extensions defined in this document does not detect bit errors in the base STAMP packets, packet headers, and STAMP TLVs other than the "Extra Padding Data" TLV.¶

4. STAMP Procedure

This document defines two TLV options for STAMP: "Bit Pattern in Padding Data" STAMP TLV (Type=TBA1) and "Bit Error Count in Padding Data" STAMP TLV (Type=TBA2). An example of STAMP test packet used for detecting bit errors is shown in Figure 2 using "Extra Padding Data" TLV, "Bit Pattern in Padding Data" STAMP TLV, and "Bit Error Count in Padding Data" STAMP TLV.¶

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 Packet RFC 8972                              |
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|     Type=1     |          Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                     Extra Padding                             ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|     Type=TBA1  |          Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                     Bit Pattern in Padding Data               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|     Type=TBA2  |          Length=4            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Bit Error Count in Padding Data           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5. STAMP Extensions

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=TBA1    |         Length                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                  Bit Pattern in Padding Data                  ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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=TBA2    |         Length=4              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Bit Error Count in Padding Data              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6. Security Considerations

The security considerations specified in [RFC8762], [RFC8972], [RFC9534] apply to the procedure and extensions defined in this document.¶

7. IANA Considerations

IANA has created the "STAMP TLV Types" registry for [RFC8972]. IANA is requested to allocate a value for the "Bit Pattern in Padding Data" TLV Type and a value for the "Bit Error Count in Padding Data" TLV Type from the IETF Review TLV range of the same registry.¶

Acknowledgments

The authors would like to thank Ianik Semco and Miloslav Kopka for the discussions on the bit error rate measurements.¶

Authors' Addresses