Internet-Draft STAMP for Residual Bit Error Rate October 2026
Gandhi, et al. Expires 21 April 2027 [Page]
Workgroup:
IPPM Working Group
Internet-Draft:
draft-ietf-ippm-stamp-ber-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
R. Gandhi, Ed.
Cisco Systems, Inc.
P. Schoenmaker
Meta Platforms, Inc.
R. Foote
Nokia
L. Zhang
Huawei Technologies

Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Residual Bit Error Rate Measurement

Abstract

The Simple Two-Way Active Measurement Protocol (STAMP), specified in RFC 8762, along with its optional extensions specified in RFC 8972, supports active measurement. Networks may experience transmission bit errors due to various factors, including poor fiber quality. Even with efficient CRC and FEC mechanisms, some bit errors may escape detection and correction; these are referred to as residual bit errors. This document further augments the STAMP extensions specified in RFC 8972 to enable the measurement of the residual bit error rate within the "Extra Padding" TLV of STAMP-Test packets.

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 21 April 2027.

▲

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 the "Extra Padding" (Type=1) TLV within STAMP-Test packets.

Networks may experience transmission bit errors due to various factors, such as poor fiber quality. These errors can corrupt packets. Bit errors can be single-bit errors or occur in bursts. Bit errors in the received packets can be detected using a Cyclic Redundancy Check (CRC) [RFC3819]. Packets with CRC failures may be dropped, or their errors may be corrected using Forward Error Correction (FEC) [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. Measuring the residual bit error rate (also called bit error ratio) (BER) [RFC3385] using active measurement packets between two nodes is beneficial for detecting service degradation. For accurate residual BER measurement, transmitting large active measurement packets is preferable, especially on links with low bit error rates. Furthermore, there is a need to transmit active measurement packets at a high rate to measure residual BER on high-capacity links.

STAMP-Test packets are transported over UDP. The UDP checksum can be used to check the integrity of the header and payload. However, the checksum field does not provide an accurate measurement of bit errors.

Authenticated mode provides data integrity protection for 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 verify the integrity of the "Extra Padding" TLV.

This document further augments the STAMP extensions defined in [RFC8972] to enable the measurement of residual bit error rate within the "Extra Padding" TLV of STAMP-Test packets.

2. Conventions Used in This Document

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 terms defined in [RFC8762], specifically Session-Sender, Session-Reflector, STAMP-Test packet, and symmetric.

This document uses terms defined in [RFC8972], specifically STAMP TLV Flags and Sub-TLVs.

2.3. Abbreviations

Table 1: Abbreviations
Abbreviation Meaning Reference
BER Bit Error Rate [RFC3385]
CRC Cyclic Redundancy Check [RFC3819]
FEC Forward Error Correction [RFC3819]
MTU Maximum Transmission Unit [RFC8200]
STAMP Simple Two-Way Active Measurement Protocol [RFC8762]
TLV Type-Length-Value [RFC8972]

2.4. STAMP Reference Topology

In the STAMP reference topology shown in Figure 1, the STAMP Session-Sender S1 initiates Session-Sender test packets, and the STAMP Session-Reflector R1 transmits Session-Reflector test packets.

                  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 a transmit timestamp, and T4 is a receive timestamp added by node S1. T2 is a receive timestamp, and T3 is a transmit timestamp added by node R1.

3. Overview

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

This document defines a procedure to measure residual BER within the "Extra Padding" TLV. The process involves the Session-Sender transmitting padding data filled with a predefined bit pattern. The Session-Reflector then checks for bit errors by comparing the received padding data against the predefined bit pattern. This allows the detection of a single bit error or a burst of bit errors and the measurement of residual BER. The Session-Reflector does not discard a Session-Sender test packet with bit errors but instead corrects the bit errors and reflects the packet back to the Session-Sender. The Session-Reflector also returns the bit error count in the reflected Session-Reflector test packet.

Residual BER is measured in both directions between the Session-Sender and the Session-Reflector using the procedure and extensions defined in this document. Residual BER is calculated using the number of bit errors detected and the number of bits received, both in the padding data.

3.1. UDP Checksum

The UDP checksum is used to check the integrity of received STAMP-Test packets at the Session-Sender and the Session-Reflector. When STAMP is used to measure residual BER, the UDP checksum MUST be set to zero in IPv4 and IPv6 STAMP-Test packets to disable UDP checksum verification. This prevents the Session-Sender and the Session-Reflector from dropping packets when bit errors cause UDP checksum verification to fail.

When the UDP checksum is zero, the UDP layer does not detect corruption of the STAMP-Test payload. Implementations MUST perform the specified STAMP packet and session validation, including checks of packet format, session identification, sequence number field, timestamp fields, and TLV structure and length, and MUST discard packets that fail those checks. These checks detect some invalid packets but do not provide general integrity protection: corruption that leaves a packet valid, including changes to measurement fields or TLV values, may go undetected and affect the measurement. Thus, a session using a zero UDP checksum without authenticated STAMP has no general assurance that its measurement information is intact. The integrity of those fields in STAMP-Test packets can be verified using the authentication mode with HMAC mechanism defined in [RFC8762] and [RFC8972].

3.2. Bit Errors Outside the Extra Padding TLV

The procedure and extensions defined in this document measure residual BER only in the "Extra Padding" TLV; they do not check the rest of the STAMP-Test packet, including its headers and other STAMP TLVs. It is possible that bit errors may affect those fields of STAMP-Test packets, causing packet verification failures. Such STAMP-Test packets are generally reported using a different measurement metric, such as packet loss.

4. Residual BER in Padding TLV Extension

This document defines a "Residual BER in Padding" TLV (Type=TBD1) for STAMP. Its Value consists of a four-octet bit error count followed by a sequence of sub-TLVs. Each sub-TLV has the STAMP TLV Flags, Type, Length, and Value fields defined in [RFC8972]. The format of the "Residual BER in Padding" TLV is shown in Figure 2.

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=TBD1    |         Length                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Bit error count (4 octets)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                         Sub-TLVs                              ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Residual BER in Padding TLV

The fields of the "Residual BER in Padding" TLV are defined as follows:

The "Residual BER in Padding" TLV contains a bit error count and MAY contain one "Bit Pattern in Padding" sub-TLV (Type=TBA1), and MAY contain one "Maximum Bit Error Burst Size in Padding" sub-TLV (Type=TBA2).

4.1. Bit Pattern in Padding Sub-TLV

The "Bit Pattern in Padding" sub-TLV is optional and is carried within the "Residual BER in Padding" TLV. Its format is shown in Figure 3.

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                                ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Bit Pattern in Padding Sub-TLV

The fields of the "Bit Pattern in Padding" sub-TLV are defined as follows:

  • STAMP TLV Flags: The STAMP TLV Flags follow the procedures specified in [RFC8972].

  • Type: MUST be set to TBA1.

  • Length: A two-octet field equal to the length of the Value field, in octets. The length of the Value field MUST be a multiple of 4 octets.

  • Bit pattern: The repeated bit pattern that MUST be used in the "Extra Padding" TLV.

4.2. Maximum Bit Error Burst Size in Padding Sub-TLV

The "Maximum Bit Error Burst Size in Padding" sub-TLV is optional and is carried within the "Residual BER in Padding" TLV. Its format is shown in Figure 4.

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              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Maximum bit error burst size                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Maximum Bit Error Burst Size in Padding Sub-TLV

The fields of the "Maximum Bit Error Burst Size in Padding" sub-TLV are defined as follows:

  • STAMP TLV Flags: The STAMP TLV Flags follow the procedures specified in [RFC8972].

  • Type: MUST be set to TBA2.

  • Length: A two-octet field set to 4, indicating that the Value field is 4 octets long.

  • Maximum bit error burst size: The maximum number of consecutive bit errors in the padding data within the "Extra Padding" TLV.

5. STAMP Procedure for Residual BER Measurement

The "Residual BER in Padding" TLV is carried by Session-Sender test packets and Session-Reflector test packets for residual BER measurement.

An example of a STAMP-Test packet using the "Extra Padding" TLV and "Residual BER in Padding" TLV for measuring residual BER is shown in Figure 5.

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-Test Packet RFC 8972                    |
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|   Type=1      |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                   Extra Padding                               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
|STAMP TLV Flags|   Type=TBD1   |           Length=20           | T
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L
|                   Bit error count                             | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
|STAMP TLV Flags|   Type=TBA1   |           Length=4            | S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ u
|                   Bit pattern                                 | b
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
|STAMP TLV Flags|   Type=TBA2   |           Length=4            | L
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V
|                   Maximum bit error burst size                | s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
Figure 5: Example STAMP-Test Packet to Measure Residual BER

5.1. STAMP Session-Sender

When a STAMP Session-Sender is configured to measure residual BER, it adds an "Extra Padding" (Type=1) TLV and one "Residual BER in Padding" (Type=TBD1) TLV to Session-Sender test packets. The "Residual BER in Padding" TLV contains a bit error count and MAY contain one "Bit Pattern in Padding" sub-TLV (Type=TBA1) and one "Maximum Bit Error Burst Size in Padding" sub-TLV (Type=TBA2). A Session-Sender test packet MUST NOT contain more than one "Extra Padding" TLV or more than one "Residual BER in Padding" TLV.

The Session-Sender MUST add an "Extra Padding" TLV [RFC8972] when it adds a "Residual BER in Padding" TLV to a Session-Sender test packet.

If the "Bit Pattern in Padding" sub-TLV is present, the length of its Value field MUST be a multiple of 4 octets, and its data MUST contain the bit pattern employed in the "Extra Padding" TLV. The length of the padding data MUST be an integer multiple of the length of the bit pattern to ease implementation.

The bit error count MUST be set to 0 by the Session-Sender.

The maximum bit error burst size in the "Maximum Bit Error Burst Size in Padding" sub-TLV MUST be set to 0 by the Session-Sender.

The integrity of the "Residual BER in Padding" TLV, including its sub-TLVs, can be protected using the HMAC mechanisms defined in [RFC8972].

If the Session-Sender receives the "Residual BER in Padding" TLV or any of its sub-TLVs with the U flag (Unrecognized) set to 1 in the corresponding STAMP TLV Flags, it assumes that the Session-Reflector does not support residual BER measurement. The Session-Sender therefore disables residual BER measurement but continues with the other STAMP measurements such as delay and loss.

5.1.1. MTU Considerations

As specified in [RFC8972], the Session-Sender test packets and Session-Reflector test packets are symmetric in size. The Session-Sender and Session-Reflector MUST adjust the size of the padding data after adding the STAMP TLVs to ensure that the resulting packets do not exceed the path MTU. Information about the path MTU of the nodes may be configured, collected through management protocols, or distributed by control protocols, such as Path MTU Discovery for IPv6 [RFC8201]. The mechanisms to learn the path MTU of nodes in the path are out of scope for this document.

5.1.2. Bit Pattern Considerations

The bit pattern in the "Bit Pattern in Padding" sub-TLV may itself contain bit errors. This can result in a measurement error due to a mismatch between the bit pattern and the padding data. One way to avoid this issue is for the Session-Sender and Session-Reflector to use the locally configured bit pattern or the default bit pattern of "0xFF00FF00", which is repeated in the padding data. In this case, the "Bit Pattern in Padding" sub-TLV is not transmitted in STAMP-Test packets.

5.2. STAMP Session-Reflector

When the Session-Reflector receives a Session-Sender test packet with a "Residual BER in Padding" TLV, it MUST check the padding data in the "Extra Padding" TLV against the expected bit pattern, counting each mismatching bit as a bit error. If the "Bit Pattern in Padding" sub-TLV is absent, the Session-Reflector uses the locally configured or default bit pattern.

The Session-Reflector MUST set the bit error count to the number of detected bit errors and reflect the "Residual BER in Padding" TLV back to the Session-Sender in a Session-Reflector test packet. If no bit errors are detected, the value remains 0.

If the "Maximum Bit Error Burst Size in Padding" sub-TLV is present, the Session-Reflector MUST update it with the maximum number of consecutive bits that do not match the expected bit pattern. If no bit errors are detected, the value remains 0.

The Session-Reflector corrects the padding data in the "Extra Padding" TLV to match the expected bit pattern and reflects the corrected "Extra Padding" TLV and the updated "Residual BER in Padding" TLV to the Session-Sender in a Session-Reflector test packet. The corrected padding data is used to measure residual BER in the reverse direction.

If the Session-Reflector does not recognize the "Residual BER in Padding" TLV, it MUST return that TLV with the U flag (Unrecognized) set to 1 in its STAMP TLV Flags. If it recognizes the "Residual BER in Padding" TLV but does not recognize one of its sub-TLVs, it MUST return that sub-TLV with the U flag set to 1 in the sub-TLV's STAMP TLV Flags, as specified in [RFC8972].

5.2.1. STAMP TLV Conformant Check

Following the procedure specified in [RFC10052], the Session-Reflector MUST set the Conformant Reflected Packet STAMP TLV flag to 1 in the STAMP TLV Flags of the reflected "Residual BER in Padding" TLV in the following cases:

  • If a Session-Reflector receives a Session-Sender test packet with a "Residual BER in Padding" TLV but without an "Extra Padding" TLV, with more than one "Extra Padding" TLV or "Residual BER in Padding" TLV, or with a "Residual BER in Padding" TLV whose Length field is less than 4 octets.

  • If the "Residual BER in Padding" TLV contains more than one "Bit Pattern in Padding" sub-TLV or more than one "Maximum Bit Error Burst Size in Padding" sub-TLV.

  • If the length of the extra padding data is not an integer multiple of the length of the bit pattern.

  • If the "Bit Pattern in Padding" sub-TLV is present and its value length is not a multiple of 4 octets.

Networks may experience transmission bit errors differently for different link members of a Link Aggregation Group (LAG). The procedure and extensions defined in this document are equally applicable to measuring residual BER in both directions of each individual member of the LAG.

To measure delay on LAG member links, a separate STAMP micro-session is created for each member of the LAG. The STAMP extension for the "Micro-Session ID" TLV, as defined in [RFC9534], is used to identify each member link of the LAG associated with the STAMP micro-session at the Session-Sender and the Session-Reflector. The Session-Reflector replies on the same member of the LAG in the reverse direction based on the information in the received STAMP-Test packet and on either the local configuration for the micro-session or the information from the data plane where the STAMP-Test packet was received.

Note that in order to obtain a good approximation of the residual BER measurement, it is RECOMMENDED to transmit STAMP-Test packets with padding data so that the packet size matches, but does not exceed, the link MTU.

6. 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.1. Configuration Data Model Parameters

The configuration data model for the residual BER measurement using STAMP MUST allow the setting of the following parameters:

  • Padding size (number of octets, which is an integer multiple of the padding bit pattern size in octets)

  • Padding bit pattern (of variable length, in 4-octet units)

  • Transmit interval for STAMP-Test packets

  • Computation interval as a multiple of the transmit interval for reporting residual BER measurements

6.2. Operational Data Model Parameters

The operational data model for the residual BER measurement using STAMP MUST allow the reporting of the following parameters:

Forward direction (near-end) residual BER measurement:

  • Total number of STAMP-Test packets received in the computation interval.

  • Total number of STAMP-Test packets received with a non-zero bit error count in the "Residual BER in Padding" TLVs in the computation interval.

  • Sum of the number of bits in the padding data of all received STAMP-Test packets in the computation interval.

  • Sum of the bit error counts reported in the "Residual BER in Padding" TLVs of all received STAMP-Test packets in the computation interval.

  • Maximum and average bit error burst sizes in the "Maximum Bit Error Burst Size in Padding" sub-TLVs of all received STAMP-Test packets in the computation interval.

Reverse direction (far-end) residual BER measurement:

  • Total number of STAMP-Test packets received in the computation interval.

  • Total number of STAMP-Test packets received with bit errors in the computation interval.

  • Sum of the number of bits in the padding data of all received STAMP-Test packets in the computation interval.

  • Sum of the number of bit errors in all received STAMP-Test packets in the computation interval.

  • Maximum and average bit error burst sizes in all received STAMP-Test packets in the computation interval.

Thresholds may be configured for the following forward- and reverse-direction residual BER metrics, measured over the computation interval:

  • Number of bit errors per million bits received

  • Number of STAMP-Test packets with bit errors per million packets received

When a computed metric crosses a user-configured threshold, an alarm may be generated and event-driven telemetry may be triggered.

7. Security Considerations

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

8. Implementation Status

Editorial note: Please remove this section prior to publication.

8.1. Open Source Implementation

An open-source implementation of the Simple Two-Way Active Measurement Protocol ([RFC8762]) is available in Teaparty.

  • https://github.com/cerfcast/teaparty

An implementation of the solution specified in this document is available at the following location:

  • https://github.com/cerfcast/teaparty/commit/592558a38dbcf9b273acb2a2fe8ab0d8f16d0709

Additionally, there is support for residual BER in the Wireshark dissector:

  • https://github.com/cerfcast/teaparty/commit/608b9e89fce2f25ed88eaa367d0bacc693845da2

Contact:

William Hawkins

University of Cincinnati

Email: hawkinsw@obs.cr

8.2. Cisco Implementation

An implementation of the solution defined in this document is available in IOS XR Software Release 26.1.1 for the Cisco 8000 Series.

- https://www.cisco.com/c/en/us/td/docs/iosxr/cisco8000/segment-routing/26xx/configuration/guide/b-segment-routing-cg-cisco8000-26xx/configuring-performance-measurement.html#link-residual-bit-error-rate-measurement-using-stamp

9. IANA Considerations

IANA is requested to assign a value to the "Residual BER in Padding" 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.

Table 2: STAMP TLV Type
Value Description Reference
TBD1 Residual BER in Padding This document

IANA is requested to assign values to the "Bit Pattern in Padding" and "Maximum Bit Error Burst Size in Padding" sub-TLVs from the IETF Review range of the "STAMP Sub-TLV Types" registry under the "Simple Two-way Active Measurement Protocol (STAMP) TLV Types" registry group, as shown in Table 3.

Table 3: STAMP Sub-TLV Types
Value Description Used in Reference
TBA1 Bit Pattern in Padding Residual BER in Padding This document
TBA2 Maximum Bit Error Burst Size in Padding Residual BER in Padding This document

10. References

10.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[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, , <https://www.rfc-editor.org/info/rfc3819>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <https://www.rfc-editor.org/info/rfc8200>.
[RFC8762]
Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, , <https://www.rfc-editor.org/info/rfc8762>.
[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, , <https://www.rfc-editor.org/info/rfc8972>.
[RFC10052]
Mirsky, G., Ruffini, E., Nydell, H., Foote, R., and W. Hawkins, "Performance Measurement with Asymmetrical Traffic Using the Simple Two-Way Active Measurement Protocol (STAMP)", RFC 10052, DOI 10.17487/RFC10052, , <https://www.rfc-editor.org/info/rfc10052>.

10.2. Informative References

[RFC3385]
Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, "Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations", RFC 3385, DOI 10.17487/RFC3385, , <https://www.rfc-editor.org/info/rfc3385>.
[RFC8201]
McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, , <https://www.rfc-editor.org/info/rfc8201>.
[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, , <https://www.rfc-editor.org/info/rfc9534>.

Acknowledgments

The authors would like to thank Ianik Semco and Miloslav Kopka for discussions about bit error rate measurement. The authors would also like to thank Ruediger Geib, Zhenqiang Li, Carsten Rossenhoevel, Ernesto Ruffini, and Xiao Min for reviewing this document and providing many useful comments and suggestions. The authors would also like to thank William Hawkins for implementing the solution defined in this document and providing many useful suggestions.

Authors' Addresses

Rakesh Gandhi (editor)
Cisco Systems, Inc.
Canada
Peter Schoenmaker
Meta Platforms, Inc.
United Kingdom
Richard Foote
Nokia
Li Zhang
Huawei Technologies
China