<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-zhang-ippm-ber-00" category="std" consensus="true" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->
  <front>
    <title>In Situ Operations, Administration, and Maintenance (IOAM) Extension for Bit Error Rate Measurement</title>
    <seriesInfo name="Internet-Draft" value="draft-zhang-ippm-ber-00"/>
    <author initials="L." surname="Zhang" fullname="Li Zhang">
      <organization>Huawei</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>zhangli344@huawei.com</email>
      </address>
    </author>
    <author initials="T." surname="Zhou" fullname="Tianran Zhou">
      <organization>Huawei</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>zhoutianran@huawei.com</email>
      </address>
    </author>
    <date year="2026" month="February" day="28"/>
    <area>OPS Area</area>
    <workgroup>IPPM Working Group</workgroup>
    <keyword>IOAM</keyword>
    <keyword>Bit Error Rate measurement</keyword>
    <abstract>
      <?line 39?>

<t>Networks may experience transmission bit errors due to various factors, such as poor fiber quality, thereby corrupting packets. Merely measuring the end-to-end bit error rate makes it difficult to locate the exact link wich poor quality. Therefore, a measurement method is needed to collect bit error rate information along the entire path to locate the specific linke with poor quality.</t>
      <t>This document extends IOAM with a new Trace-Type and "Interface Bit Error Rate" field to collect the interface error rate along the path. This new Trace-Type is applicable to Pre-allocated Trace, Incremental Trace, and Direct Exporting Option-Type.</t>
    </abstract>
  </front>
  <middle>
    <?line 45?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>In situ Operations, Administration, and Maintenance (IOAM)<xref target="RFC9197"/> collects OAM information within the packet while the packet traverses a particular network domain. IOAM is used to complement mechanisms, such as Ping or Traceroute.</t>
      <t>Networks may experience transmission bit errors due to various factors, such as poor fiber quality, thereby corrupting packets. Although,the bit errors in the received packets can be detected using Cyclic Redundancy Check (CRC) and may be dropped or corrected using Forward Error Correction(FEC). But even with efficient CRC and FEC mechanisms, some bit errors may escape detection and correction (called residual bit error rate), and result in upper-layer checksum failures and packet drops.</t>
      <t><xref target="I-D.gandhi-ippm-stamp-ber"/> arguments the STAMP extensions in <xref target="RFC8972"/> to enable the measurement of end-to-end residual bit error rate within the "Extra Padding" TLV of STAMP packets.</t>
      <t>However, merely measuring the end-to-end bit error rate makes it difficult to locate the exact link with poor quality. Therefore, a measurement method is needed to collect bit error rate information along the entire path to locate the specific linke with poor quality.</t>
      <t>This document extends IOAM with a new Trace-Type and "Interface Bit Error Rate" field to collect the interface error rate along the path. This new Trace-Type is applicable to Pre-allocated Trace, Incremental Trace, and Direct Exporting Option-Type.</t>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>

</section>
      <section anchor="terminology">
        <name>Terminology</name>
        <t>The abbreviations used in this document are:</t>
        <t>IOAM: In situ Operations, Administration, and Maintenance</t>
      </section>
    </section>
    <section anchor="ioam-extension">
      <name>IOAM extension</name>
      <section anchor="extension-to-pre-allocated-and-incremental-trace-option">
        <name>Extension to Pre-allocated and Incremental Trace-Option</name>
        <section anchor="PIH">
          <name>Extension to Pre-allocated and Incremental Trace-Option Header</name>
          <t>The format of IOAM Pre-allocated and Incremental Trace-Option header defined in <xref target="RFC9197"/> is shown as follows:</t>
          <figure anchor="ref-to-fig1">
            <name>IOAM Pre-allocated and Incremental Trace-Option Header</name>
            <artwork><![CDATA[
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Namespace-ID           |NodeLen  | Flags | RemainingLen|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               IOAM Trace-Type                 |  Reserved     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>The IOAM Trace-Type filed is a 24-bit identifier that specifies which data types are used in this node data list. Currently, bit 0 to bit 11 are already occupied, and bit 12 to 21 are not allocated.</t>
          <t>This document requires to allocate a new bit X in the IOAM Trace-Type field:</t>
          <t>Bit X: When set, indicates the presence of bit error rate of the ingress interface in the node data.</t>
        </section>
        <section anchor="extension-to-ioam-node-data-fields">
          <name>Extension to IOAM Node Data Fields</name>
          <t>This document defines a new IOAM node data field, which is called "Interface Bit Error Rate". The format of this field is shown as follows:</t>
          <figure anchor="ref-to-fig2">
            <name>Interface bit error rate field</name>
            <artwork><![CDATA[
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|  RESERVED   |                     BER                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>where:</t>
          <t>A bit: This field represents the Anomalous (A) bit. The A bit is set when the measured value of this parameter exceeds its configured maximum threshold. The A bit is cleared when the measured value falls below its configured reuse threshold. If the A bit is cleared, the sub-TLV represents steady-state link performance.</t>
          <t>RESERVED: This field is reserved for future use. It <bcp14>MUST</bcp14> be set to 0 when sent and <bcp14>MUST</bcp14> be ignored when received.</t>
          <t>Link Bit Error Ratio: This 24-bit field carries Link Bit Error Ratio as a percentage of the total traffic sent over a configurable interval. The basic unit is 0.000003%, where (2^24 - 2) is 50.331642%. This value is the highest link bit error percentage that can be expressed. Therefore, measured values that are larger than the field maximum <bcp14>SHOULD</bcp14> be encoded as the maximum value.</t>
        </section>
      </section>
      <section anchor="extension-for-direct-exporting-option">
        <name>Extension for Direct Exporting Option</name>
        <t>As described in <xref section="3.2" sectionFormat="of" target="RFC9326"/>, the format of this IOAM-Trace-Type of Direct Exporting Option is the same as defined in <xref target="RFC9197"/>. Therefore, the new bit defined in <xref target="PIH"/> is also valid in Direct Exporting Option.</t>
      </section>
    </section>
    <section anchor="IANA">
      <name>IANA Considerations</name>
      <t>This document requests IANA to allocate a bit from the "IOAM Trace-Type" registry:</t>
      <table>
        <thead>
          <tr>
            <th align="left">Value</th>
            <th align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">Bit X</td>
            <td align="left">Bit error rate of ingress interface</td>
            <td align="left">This document</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="Security">
      <name>Security Considerations</name>
      <t>TBD</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC9197">
          <front>
            <title>Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)</title>
            <author fullname="F. Brockners" initials="F." role="editor" surname="Brockners"/>
            <author fullname="S. Bhandari" initials="S." role="editor" surname="Bhandari"/>
            <author fullname="T. Mizrahi" initials="T." role="editor" surname="Mizrahi"/>
            <date month="May" year="2022"/>
            <abstract>
              <t>In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9197"/>
          <seriesInfo name="DOI" value="10.17487/RFC9197"/>
        </reference>
        <reference anchor="I-D.gandhi-ippm-stamp-ber">
          <front>
            <title>Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Residual Bit Error Rate Measurement</title>
            <author fullname="Rakesh Gandhi" initials="R." surname="Gandhi">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Peter Schoenmaker" initials="P." surname="Schoenmaker">
              <organization>Meta Platforms, Inc.</organization>
            </author>
            <author fullname="Richard &quot;Footer&quot; Foote" initials="R. F." surname="Foote">
              <organization>Nokia</organization>
            </author>
            <date day="14" month="November" year="2025"/>
            <abstract>
              <t>   The Simple Two-Way Active Measurement Protocol (STAMP), as defined in
   RFC 8762, along with its optional extensions specified in RFC 8972,
   can be utilized for 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, referred to as residual bit
   errors.  This document further augments the STAMP extensions
   specified in RFC 8972 to enable the measurement of residual bit error
   rate within the "Extra Padding" TLV of STAMP packets.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-gandhi-ippm-stamp-ber-04"/>
        </reference>
        <reference anchor="RFC8972">
          <front>
            <title>Simple Two-Way Active Measurement Protocol Optional Extensions</title>
            <author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
            <author fullname="X. Min" initials="X." surname="Min"/>
            <author fullname="H. Nydell" initials="H." surname="Nydell"/>
            <author fullname="R. Foote" initials="R." surname="Foote"/>
            <author fullname="A. Masputra" initials="A." surname="Masputra"/>
            <author fullname="E. Ruffini" initials="E." surname="Ruffini"/>
            <date month="January" year="2021"/>
            <abstract>
              <t>This document describes optional extensions to Simple Two-way Active Measurement Protocol (STAMP) that enable measurement of performance metrics. The document also defines a STAMP Test Session Identifier and thus updates RFC 8762.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8972"/>
          <seriesInfo name="DOI" value="10.17487/RFC8972"/>
        </reference>
        <reference anchor="RFC9326">
          <front>
            <title>In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting</title>
            <author fullname="H. Song" initials="H." surname="Song"/>
            <author fullname="B. Gafni" initials="B." surname="Gafni"/>
            <author fullname="F. Brockners" initials="F." surname="Brockners"/>
            <author fullname="S. Bhandari" initials="S." surname="Bhandari"/>
            <author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
            <date month="November" year="2022"/>
            <abstract>
              <t>In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, IOAM allows telemetry data to be pushed into data packets while they traverse the network. This document introduces a new IOAM option type (denoted IOAM-Option-Type) called the "IOAM Direct Export (DEX) Option-Type". This Option-Type is used as a trigger for IOAM data to be directly exported or locally aggregated without being pushed into in-flight data packets. The exporting method and format are outside the scope of this document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9326"/>
          <seriesInfo name="DOI" value="10.17487/RFC9326"/>
        </reference>
      </references>
    </references>
    <?line 153?>

<section numbered="false" anchor="Acknowledgements">
      <name>Acknowledgements</name>
      <t>TBD</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1YbW/jxhH+LkD/YSojgJ2agiQ7d2chyVW25dqA32rrLpcG
abEiV9LCFJfZJU9WbN9v6W/pL+szu6RMvRjopT20QCt/MDXcl5lnZp6ZURAE
9ZrNRBL9VcQ6kV3KTC7rNZUa92izTqt10OrUa6HIumSzCMvz4VRZq3SSzVPs
OOsPTuo1YaTo0tX1LfXwVK/NxnhzfX1BP2hzp5Ix/dHoPK3X6rVIh4mYYmNk
xCgLfp2IZByoNJ0GQ2mCVqte00OrY5lJ263X8jQS/qley1QW84UJ3aosp6tU
GpFBD7tLvWiqEmUzL9glWEQXQiWZTEQSSto+u+pd7FD/HgJWnUba0KHKqG8M
nm5wB11IYXMjpzLJ+LYYenVJJvXa3QzXU0B8hntY2Thd3ijybKINtgBbIpXY
Lp036c9sJwu88efqWaINLjrNxUwq/hrqPMnMvEtHE5UIlsipUHGXHFSx2tvf
/8PErW6Gelq9ZsDX6Pz5loESiRHJQvrP36TzzO9duor/Em2mQPmjdD5RyWjp
exAEJIbsiNCBcSmzGSLA0lTMSd7DZUqyQ7AgsUUc0RB4SsbTUpTjnaaPwiid
WxrhGIh3yebhhISlVAP1kUKo0C+5iFU236VsIo0czmGOMXmacbSlIryTmW3C
qUbG88JF/AaL4dQoyHSAf89Xk3GuFHfSEmSRGo1UmMcZaxPrkF+6rffQiGKV
3NFMQSWnT6FJkwasCQCRiMBqWOAZMRGRspRIGcmITw11HEsctqLCAlEAw0lZ
qpwpI2FXNlnRyKYyVNDVKSWhVbaiFbthMMHVyLzcaSM5DSLrAtpvENBrRgN4
TQYDpLVLoMYZ8sfABXIl4hvwgIyXjGBN1GJ5xZxnE1h3hsiBsHQZJCJNYxWK
Yezcf21kIGJvZORX7iLvQ4+miEsRa3kMXKBA/z7Vxvn+KmXs3MnNMiSnKopi
yd+2cE5mdJSHvIol4BP72/jk4eHtzcnRQfvg9dNTiYQlBrXqRAZYJQUEHJY0
m6hYVgW456M0FqEnIIIZiDxhAJNLHjgOaZk0vb8AVm7LCJqmcRlgIdhB2Wkl
V64ZDfjBgQX6zTwe/+mU7MXIhXw82WUAKvcUGMGbEmwSlRsoBIENJUWoCCGH
Q275uKN5iIChGxnlSQSfzEFiMryj7aObox3nLzaP9xmdptgGJVmb6hkn2syE
iYrIPvJvYf32Sf9op0mHOXT7KL0HSTIhKMYaN7gLsGoZdz1dMsjha0ORlsq7
lMbGcHETbYeIcyhkpFUR0Fthgx0fenjLVASEcthigljMgXbIBtt8CpeoGExj
3doipNhs6/yNKD0LjptjvJwoX2lR8qcp11vErTBjxwrWoX876F1ce4LgOHBe
8WH+5uB1B8sRCciBYRG/VY7ToyqxvmBQNRsaKMdG0LWIInijQYPz93yIV6EM
F7bgVM/gB7OL674gm6/y5v/Z/L+Rzbe2kPO/5MpvtnSOnigXY+lxkXQn5wR6
Ax6Ni3e3g8au/0+XV+75pv+nd2c3/WN+vj3tnZ8vHmrFitvTq3fnx89PzzuP
ri4u+pfHfjOktCSqNS56Pza8FY2r68HZ1WXvvOFZreoudMoMyrBAODWSURG2
FoErDGg04j2HR9d//1t7H7n3O+Rep90+QO75L2/ar/fxZTaRRWHSCXLCf4Vn
5jWgL1E9FEdcDPpMFUAGP4Gr7UTPEuK4btZqX//EyPzcpW+HYdre/74QsMFL
whKzJaHDbF2yttmDuEG04ZoFmkvyFaSX9e39uPS9xL0i/PYtUklS0H7z9vta
EUEDaVDfdazH8zJuxHBo5EflGwBfYTe5zjW5nGluDvncvsF30Fs+VRckWyj1
PJys5Qwfs5YwgU8Nv/s3b6dTKSIUk4et67PTpxINT1rMxk7Vzzhu4o+L5Aio
R8/lo+iSVBmDCMYR2EbP/Gz36dMnnj+IWrT+aW+QdTbI9soj2ni9R/v0Db2i
1/SGDj5H5g75ffAv/rlTHkvNLjGO2ZRhOjuuKPx4qSN5jg4DK09iMbb4f8Mz
WALqg/zxS+hSfJxjK7S9+sH6G2ml4VbMff936eJc/dClLRRXLtwjNW6Tm+2/
a3xutPngbSzidtWokeLmiisSdfYDrs0q4uKLimeQ3AjxouCiT0BXjoY2Epkg
/mXDOqZeIoIE3vILYuR4k45y9HFJFqPh5aNbjtfx0G67vSI2UG9OOgzzVMnI
04Fb0OGlHb8s0RktzN1Q340vd5a3lOuKEs9nfSgb53XbUdVdcnG9/9ClH1Ai
yMpsFzsixcf4ng8lyLoJAOm+0r5A4nuBMdbYSk9Q3LlApLmRhpxKHON0zKid
sEZ23UJPFrYwym16htqZsVt4R/E44Brml9sZ17hVGMy5zrc4/2Ps0+Mc7t/2
b973jzcwgP8c9m82yr9sxncWGb9w40roOY/5zJ5xw+Ic1eNVXd92epca6cO3
mF96CWblmOfU7d4OL/bR4PY597vxWybV6SXCbBvnchErmMBB11ALJTpEg88j
BOJOJ9DbLZ+KezXF3JVNcPVEx9HKJWGM/gvrXrpohBC26AARf6tHGwnGqR58
5jNw9exdPy3kw4CnpgoINmPO4QkPGLrJBu2JSwZkuMvSMiKWYMSDKdmefxsd
5Vnu6Q8qZOT6QrSsDB/yuuVNs64p4haneK3GiV4YXg7y7tJz1mQpUZUuFCiI
2esRCmOYjDet56wVbE7IlWC8YKdMc11Az8VDnldKY1zE2hJYN4k48oIDvLOG
wmJxnnhUW80Wf/a+YqJBsNF25y+dfQqos8Ovv2k19/bar/Y7XxUjj/ej8jE3
UeOJtMUc+RzFFUVdpSl+x5D37CuUlaUBczlCrN/B1SHGfO5rlQ8lD1MZgUUr
zccmoY7cIOEjrljgjmvWa2s9Jjv5hWHLJRrouTqPPDzcFr9Y7DU7DLzr6fY6
r56efCiu8C2TeFApRpC/cFuJokXOsfaVzvGnom/8eQkqV3eK4rfUZnID6zpM
TDv8e1Ws3IsX7m0umvHeZY+O0L6jNSgaeXTDLH3aVIrhaev3LNdjF8NGT/1P
GyvFuIGtY54L5o7GHum9C6BHOnYgeyC49xvBTC7F4N7HwH/K/+vfeJFLkg/0
eLhWuNeK9iMtWfNYAgDP5kZl83UQyje+vzo89jv4B9WhCO/87l54l+gZSvK4
mMgftlZFT479k3w6hHXRdw3wn5VM7Ysj/wGTunvbiRoAAA==

-->

</rfc>
