<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-wang-ippm-stamp-hbh-extensions-04"
     ipr="trust200902">
  <front>
    <title abbrev="draft-wang-ippm-stamp-hbh-extensions">Simple Two-way
    Active Measurement Protocol Extensions for Hop-by-Hop OAM Data
    Collection</title>

    <author fullname="Tianran Zhou" initials="T." surname="Zhou">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beijing Rd., Haidian District</street>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>zhoutianran@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Giuseppe Fioccola" initials="G." surname="Fioccola">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>giuseppe.fioccola@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Gyan Mishra" initials="G." surname="Mishra">
      <organization>Verizon Inc.</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>gyan.s.mishra@verizon.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Hongwei Yang" initials="H." surname="Yang">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street>Xibianmen Inner St, 53, Xicheng District</street>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>yanghongwei@chinamobile.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Chang Liu" initials="C." surname="Liu">
      <organization>China Unicom</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>liuc131@chinaunicom.cn</email>

        <uri/>
      </address>
    </author>

    <date year="2023"/>

    <workgroup>IP Performance Measurement Group</workgroup>

    <abstract>
      <t>This document defines optional TLVs which are carried in Simple
      Two-way Active Measurement Protocol (STAMP) test packets to enhance the
      STAMP based functions. Such extensions to STAMP enable OAM data
      measurement and collection at every node and link along a STAMP test
      packet's delivery path without maintaining a state for each configured
      STAMP-Test session at every devices.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>,
	  <xref target="RFC8174">RFC 8174</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Simple Two-way Active Measurement Protocol (STAMP) <xref
      target="RFC8762"/> enables the measurement of both one-way and
      round-trip performance metrics, such as delay, delay variation, and
      packet loss. In the STAMP session, the bidirectional packet flow is
      transmitted between STAMP Session-Sender and STAMP Session-Reflector.
      The STAMP Session-Reflector receives test packets transmitted from
      Session-Sender and acts according to the configuration. However, the
      performance of intermediate nodes and links that STAMP test packets
      traverse are invisible. In addition, the STAMP instance must be
      configured at every intermediate node to measure the performance per
      node and link that test packets traverse, which increases the complexity
      of OAM in large-scale networks.</t>

      <t>STAMP Extensions have defined several optional TLVs to enhance the
      STAMP base functions. These optional TLVs are defined as updates of the
      STAMP Optional Extensions <xref target="RFC8972"/>. This document
      extents optional TLVs to STAMP, which enables performance measurement at
      every intermediate node and link along a STAMP test packet's delivery
      path, such as measurement of delay, delay variation, packet loss, and
      record of link errors and route information.</t>
    </section>

    <section title="Terminology">
      <t>Following are abbreviations used in this document:</t>

      <t>STAMP: Simple Two-way Active Measurement Protocol.</t>

      <t>IOAM: In-situ OAM.</t>

      <t>HbH: Hop-by-Hop.</t>
    </section>

    <section title="TLV Extensions to STAMP">
	
      <section title="IOAM-Tracing-Data TLV">
        <t>STAMP Session-Sender can place the IOAM-Tracing-Data TLV in
        Session-Sender test packets to record the IOAM tracing data at every
        IOAM capable node along the Session-Sender test packet's
        forward-delivery path. As STAMP uses symmetrical packets, the
        Session-Sender MUST set the Length value as a multiple of 4 octets
        according to the number of nodes and the IOAM-Trace-Type (i.e. a
        24-bit identifier which specifies which data types are used in the
        node data list <xref target="RFC9197"/>). And the
        node-data-copied-list fields MUST be set to zero upon Session-Sender
        test packets transmission and ignored upon receipt.</t>

        <t>The IOAM-Tracing-Data TLV has the following format:</t>

        <t><figure align="center" title="Fig. 1 IOAM-Tracing-Data TLV Format">
            <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
+-------------------------------+-------------------------------+
|   IOAM-Tracing-Data Type      |            Length             |
+---------------------------------------------------------------+
|                    node-data-copied-list [0]                  |
+---------------------------------------------------------------+
|                    node-data-copied-list [1]                  |
+---------------------------------------------------------------+
~                               ...                             ~
+---------------------------------------------------------------+
|                    node-data-copied-list [n]                  |
+---------------------------------------------------------------+

]]></artwork>
          </figure></t>

        <t>where fields are defined as the following:</t>

        <t><list style="symbols">
            <t>IOAM-Tracing-Data Type: To be assigned by IANA.</t>

            <t>Length: A 2-octet field that indicates the length of the value
            field in octets and equal to a multiple of 4 octets dependent on
            the number of nodes and IOAM-Trace-Type bits.</t>

            <t>node-data-copied-list [0..n]: A variable-length field, which
            record the copied content of each node data element determined by
            the IOAM-Trace-Type. The order of packing the data fields in each
            node data element follows the bit order of the IOAM-Trace-Type
            field (see section 4.4.1 of <xref target="RFC9197"/>). The last node
			data element in this list is the node data of the first IOAM trace
			capable node in the path.</t>
          </list></t>

        <t>In an IOAM domain, the STAMP Session-Sender and the STAMP
        Session-Reflector MAY be configured as the IOAM encapsulating node and
        the IOAM decapsulating node. The STAMP Session-Sender (i.e. the IOAM
        encapsulating node) generates the test packet with the IOAM Tracing
        Data TLV. For applying the IOAM Trace-Option functionalities to the
        Session-Sender test packet, the Session-Sender must inserts the "trace
        option header" and allocate an node-data-list array <xref target="RFC9197"/>
		into "option data" fields of Hop-by-Hop Options header in IPv6 packets
		<xref target="I-D.ietf-ippm-ioam-ipv6-options"/>, and sets the corresponding
        bits in the IOAM-Trace-Type. Also, the STAMP Session-Sender allocates
        a node-data-copied-list array in the optional IOAM-Tracing-Data TLV to
        store OAM data retrieved from every IOAM transit node along the
        Session-Sender test packet's delivery path.</t>

        <t>When the STAMP Session-Reflector (i.e. the IOAM decapsulating node)
        received the STAMP Session-Sender test packet with the
        IOAM-Tracing-Data TLV, it MUST copy the node-data-list array into the
        node-data-copied-list array carried in the Session-Reflector test
        packet before transmission and MUST remove the IOAM-Data-Fields.
        Hence, carrying IOAM-Tracing-Data TLV in STAMP test packets enables
        OAM data collection and measurement at every node and link.</t>

        <t>Also the STAMP Session-Reflector MAY be configured as IOAM
        encapsulating node to apply the IOAM Trace-Option functionalities to
        the Session-Reflector test packet. Hence, OAM data collection and
        measurement can be also enabled at every node and link along the
        Session-Reflector test packet's backward delivery path. When the
        reflected packet arrives at the Session-Sender, it can be either
        locally processed or sent to the centralized controller.</t>
      </section>

      <section title="Forward HbH Delay TLV">
        <t>STAMP Session-Sender can place the Forward HbH Delay TLV in
        Session-Sender test packets to record the ingress timestamp and the
        egress timestamp at every intermediate nodes along the Session-Sender
        test packet's forward path. The Session-Sender MUST set the Length
        value according to the number of explicitly listed intermediate nodes
        in the forward path and the timestamp formats. There are several
        methods to synchronize the clock, e.g., Network Time Protocol (NTP)
        <xref target="RFC5905"/> and IEEE 1588v2 Precision Time Protocol (PTP)
        <xref target="IEEE.1588.2008"/>. For example, if a 64-bit timestamp
        format defined in NTP is used, the Length value MUST be set as a
        multiple of 16 octets. The Timestamp Tuple list [1..n] fields MUST be
        set to zero upon Session-Sender test packets transmission.</t>

        <t>The Forward HbH Delay TLV has the following format:</t>

        <t><figure align="center" title="Fig. 2 Forward HbH Delay TLV Format">
            <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
+-------------------------------+---------------+---------------+
|   Forward HbH Delay Type      |     Length    |    Node Left  |
+-------------------------------+---------------+---------------+
|                                                               |
|                     Timestamp Tuple list [1]                  |
|                                                               |
|                                                               |
+---------------------------------------------------------------+
~                              ...                              ~
+---------------------------------------------------------------+
|                                                               |
|                     Timestamp Tuple list [n]                  |
|                                                               |
|                                                               |
+---------------------------------------------------------------+
]]></artwork>
          </figure></t>

        <t>where fields are defined as the following:</t>

        <t><list style="symbols">
            <t>Forward HbH Delay Type: To be assigned by IANA.</t>

            <t>Length: A 8-bit field that indicates the length of the value
            portion in octets and MUST be a multiple of 16 octets according to
            the number of explicitly listed intermediate nodes in the forward
            path.</t>

            <t>Node Left: A 8-bit unsigned integer, which indicates the number
            of intermediate nodes remaining. That is, number of explicitly
            listed intermediate nodes still to be visited before reaching the
            destination node in the forward path. The Node Left field is set
            to n-1, where n is the number of intermediate nodes.</t>

            <t>Timestamp Tuple list [1..n]: A variable-length field, which
            record the timestamp when the Session-Sender test packet is
            received at the ingress of the n-th intermediate node and the
            timestamp when the Session-Sender test packet is sent at egress of
            the n-th intermediate node. For example, if a 64-bit timestamp
            format defined in NTP is used, the length of each Timestamp Tuple
            (ingress timestamp [n], egress timestamp [n]) must be 16 octets.
            The Timestamp Tuple list is encoded starting from the last
            intermediate node which is explicitly listed. That is, the first
            element of the Timestamp Tuple list [1] records the timestamps
            when the Session-Sender test packet received and forwarded at the
            last intermediate node of a explicit path, the second element
            records the penultimate Timestamp Tuple when the Session-Sender
            test packet received and forwarded at the penultimate intermediate
            node of a explicit path, and so on.</t>
          </list></t>

        <t>In the following reference topology, Node N1, N2, N3, N4 and N5 are
        SRv6 capable nodes. Node N1 is the STAMP Session-Sender and Node N5 is
        the STAMP Session-Reflector. T1 is the Timestamp taken by the
        Session-Sender (i.e. N1) at the start of transmitting the test packet.
        T2 is the Receive Timestamp when the test packet was received by the
        Session-Reflector (i.e. N5). T3 is the Timestamp taken by the
        Session-Reflector at the start of transmitting the test packet. T4 is
        the Receive Timestamp when the test packet was received by the
        Session-Sender. Timestamp tuples (t1,t2), (t3,t4) and (t5,t6) are the
        timestamps when the test packet received and transmitted by sequence
        of intermediate nodes in the forward path. Timestamp Tuples (t7,t8),
        (t9,t10) and (t11,t12) are the timestamps when the test packet
        received and transmitted by sequence of intermediate nodes in the
        backward path.</t>

        <t><figure align="center" title="Fig. 3 Reference Topology">
            <artwork><![CDATA[
======          ======          ======          ======         ======
|    | T1--->t1 |    | t2--->t3 |    | t4--->t5 |    | t6--->T2|    |
| N1 |==========| N2 |==========| N3 |==========| N4 |=========| N5 |
|    | T4<---t12|    |t11<---t10|    | t9<---t8 |    | t7<---T3|    |
======          ======          ======          ======         ======
]]></artwork>
          </figure></t>

        <t>The STAMP Session-Sender (i.e. Node N1) generates the STAMP test
        packet with the Forward HbH Delay TLV. When an intermediate node
        receives the STAMP test packet, the node punts the packet to control
        plane and fills the ingress timestamp [n] filed in the Timestamp Tuple
        list [n]. Then the time taken by the intermediate node transmitting
        the test packet is recorded in to egress timestamp [n] field. The
        mechanism of timestamping and punting packet to control plane is
        outside the scope of this specification.</t>

        <t>When the STAMP Session-Reflector received the test packet with the
        Forward HbH Delay TLV, it MUST copy the Forward HbH Delay TLV into the
        Session-Reflector test packet before its transmission. Using Forward
        HbH Delay TLV in STAMP testing enables delay measurement per link in
        the forward path.</t>
      </section>

      <section title="Backward HbH Delay TLV">
        <t>STAMP Session-Sender can place the Backward HbH Delay TLV in
        Session-Sender test packets to record the ingress timestamp and egress
        timestamp when Session-Reflector test packets are received and sent at
        every intermediate nodes in the backward path. The Session-Sender MUST
        set the Length value according to the number of explicitly listed
        intermediate nodes in the backward path and the timestamp formats.
        There are several methods to synchronize the clock, e.g., Network Time
        Protocol (NTP) <xref target="RFC5905"/> and IEEE 1588v2 Precision Time
        Protocol (PTP) <xref target="IEEE.1588.2008"/>. For example, if a
        64-bit timestamp format defined in NTP is used, the Length value MUST
        be set as a multiple of 16 octets. The Timestamp Tuple list [1..n]
        fields MUST be set to zero upon Session-Sender test packets
        transmission and ignored upon receipt.</t>

        <t>The Backward HbH Delay TLV has the following format:</t>

        <t><figure align="center" title="Fig. 4 Backward HbH Delay TLV Format">
            <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
+-------------------------------+---------------+---------------+
|   Backward HbH Delay Type     |     Length    |    Node Left  |
+-------------------------------+---------------+---------------+
|                                                               |
|                     Timestamp Tuple list [1]                  |
|                                                               |
|                                                               |
+---------------------------------------------------------------+
~                              ...                              ~
+---------------------------------------------------------------+
|                                                               |
|                     Timestamp Tuple list [n]                  |
|                                                               |
|                                                               |
+---------------------------------------------------------------+

]]></artwork>
          </figure></t>

        <t>where fields are defined as the following:</t>

        <t><list style="symbols">
            <t>Backward HbH Delay Type: To be assigned by IANA.</t>

            <t>Length: A 8-bit field that indicates the length of the value
            portion in octets and will be a multiple of 16 octets dependent on
            the number of explicitly listed intermediate nodes in the backward
            path.</t>

            <t>Node Left: A 8-bit unsigned integer, which indicates the number
            of intermediate nodes remaining. That is, number of explicitly
            listed intermediate nodes still to be visited before reaching the
            destination node in the backward path. The Node Left field is set
            to n-1, where n is the number of intermediate nodes.</t>

            <t>Timestamp Tuple list [1..n]: A variable-length field, which
            record the timestamp when the reflected test packet is received at
            the ingress of the n-th intermediate node and the timestamp when
            the reflected test packet is sent at egress of the n-th
            intermediate node. For example, if a 64-bit timestamp format
            defined in NTP is used, the length of each Timestamp tuple
            (ingress timestamp [n], egress timestamp [n]) must be 16 octets.
            The Timestamp Tuple list is encoded starting from the last
            intermediate node which is explicitly listed. That is, the first
            element of the Timestamp Tuple list [1] records the timestamps
            when the reflected test packet received and forwarded at the last
            intermediate node of a explicit path, the second element records
            the penultimate Timestamp Tuple when the reflected test packet
            received and forwarded at the penultimate intermediate node of a
            explicit path, and so on.</t>
          </list></t>

        <t>When the STAMP Session-Reflector received the Session-Sender test
        packet with the Backward HbH Delay TLV, it MUST copy the Backward HbH
        Delay TLV into the Session-Reflector test packet.</t>

        <t>When an intermediate node receives the reflected test packet, the
        node sends the packet to control plane and fills the ingress timestamp
        [n] filed of Backward HbH Delay TLV. Then the time taken by the
        intermediate node transmitting the test packet is recorded in to
        egress timestamp [n] field of Backward HbH Delay TLV. Using Backward
        HbH Delay TLV in STAMP testing enables delay measurement per link in
        the backward path.</t>
      </section>

      <section title="HbH Direct Loss TLV">
        <t>STAMP Session-Sender can place the HbH Direct Loss TLV in
        Session-Sender test packets to record the number of Session-Sender
        test packets received at and transmitted by every intermediate nodes
        along the forward path. The Session-Sender MUST set the Length value
        according to the number of explicitly listed intermediate nodes in the
        forward path. A Counter Tuple is composed of a 64-bit Receive Counter
        field and a 64-bit Transmit Counter field. The Counter Tuple list
        [1..n] fields MUST be set to zero upon Session-Sender test packets
        transmission.</t>

        <t>The HbH Direct Loss TLV has the following format:</t>

        <t><figure align="center" title="Fig. 5 HbH Direct Loss TLV Format">
            <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
+-------------------------------+---------------+---------------+
|     HbH Direct Loss Type      |     Length    |    Node Left  |
+-------------------------------+---------------+---------------+
|                                                               |
|                     Counter Tuple list [1]                    |
|                                                               |
|                                                               |
+---------------------------------------------------------------+
~                              ...                              ~
+---------------------------------------------------------------+
|                                                               |
|                     Counter Tuple list [n]                    |
|                                                               |
|                                                               |
+---------------------------------------------------------------+

]]></artwork>
          </figure></t>

        <t>where fields are defined as the following:</t>

        <t><list style="symbols">
            <t>HbH Direct Loss Type: To be assigned by IANA.</t>

            <t>Length: A 8-bit field that indicates the length of the value
            portion in octets and will be a multiple of 16 octets dependent on
            the number of explicitly listed intermediate nodes in the forward
            path.</t>

            <t>Node Left: A 8-bit unsigned integer, which indicates the number
            of intermediate nodes remaining. That is, number of explicitly
            listed intermediate nodes still to be visited before reaching the
            destination node in the forward path. The Node Left field is set
            to n-1, where n is the number of intermediate nodes.</t>

            <t>Counter Tuple list [1..n]: A variable-length field, which
            record the Receive Counter and the Transmit Counter when the test
            packet is received at and transmitted by the n-th intermediate
            node. The Counter Tuple list is encoded starting from the last
            intermediate node which is explicitly listed. That is, the first
            element of the Counter Tuple list [1] records the Receive Counter
            and the Transmit Counter when the test packet is received at and
            transmitted by the last intermediate node of a explicit path, the
            second element records the penultimate Counter Tuple when the test
            packet received and forwarded at the penultimate intermediate node
            of a explicit path, and so on.</t>
          </list></t>

        <t>The STAMP Session-Sender generates the STAMP test packet with the
        HbH Direct Loss TLV. When an intermediate node receives the STAMP test
        packet, the node punts the packet to control plane and writes the
        Receive Counter [n] and the Transmit Counter [n] at the Counter Tuple
        list [n] in the Session-Sender test packet. The mechanism of punting
        packet to control plane is outside the scope of this
        specification.</t>

        <t>When the STAMP Session-Reflector received the test packet with the
        HbH Direct Loss TLV, it MUST copy the HbH Direct Loss TLV into the
        Session-Reflector test packet before its transmission. Using HbH
        Direct Loss TLV in STAMP testing enables packet loss measurement per
        node/link in the forward path.</t>
      </section>

      <section title="HbH Bandwidth Utilization TLV">
        <t>STAMP Session-Sender can place the HbH Bandwidth Utilization (BW
        Utilization) TLV in Session-Sender test packets to record the ingress
        and egress BW Utilization at every intermediate nodes along the
        forward path. The Session-Sender MUST set the Length value according
        to the number of explicitly listed intermediate nodes in the forward
        path. A BW Utilization Tuple is composed of a 32-bit ingress BW
        Utilization field and a 32-bit egress BW Utilization field. The BW
        Utilization Tuple list [1..n] fields MUST be set to zero upon
        Session-Sender test packets transmission.</t>

        <t>The HbH Bandwidth Utilization TLV has the following format:</t>

        <t><figure align="center"
            title="Fig. 6 HbH Bandwidth Utilization TLV Format">
            <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
+-------------------------------+---------------+---------------+
|    HbH BW Utilization Type    |     Length    |    Node Left  |
+-------------------------------+---------------+---------------+
|                BW Utilization Tuple list [1]                  |
|                                                               |
+---------------------------------------------------------------+
~                              ...                              ~
+---------------------------------------------------------------+
|                BW Utilization Tuple list [n]                  |
|                                                               |
+---------------------------------------------------------------+

]]></artwork>
          </figure></t>

        <t>where fields are defined as the following:</t>

        <t><list style="symbols">
            <t>HbH BW Utilization Type: To be assigned by IANA.</t>

            <t>Length: A 8-bit field that indicates the length of the value
            portion in octets and will be a multiple of 8 octets dependent on
            the number of explicitly listed intermediate nodes in the forward
            path.</t>

            <t>Node Left: A 8-bit unsigned integer, which indicates the number
            of intermediate nodes remaining. That is, number of explicitly
            listed intermediate nodes still to be visited before reaching the
            destination node in the forward path. The Node Left field is set
            to n-1, where n is the number of intermediate nodes.</t>

            <t>BW Utilization Tuple list [1..n]: A variable-length field,
            which record the ingress and egress bandwidth utilization when the
            test packet is received at and transmitted by the n-th
            intermediate node. The BW Utilization Tuple list is encoded
            starting from the last intermediate node which is explicitly
            listed. That is, the first element of the BW Utilization Tuple
            list [1] records the ingress and the egress bandwidth utilization
            when the test packet is received at and transmitted by the last
            intermediate node of a explicit path, the second element records
            the penultimate BW Utilization Tuple when the test packet received
            at and transmitted by the penultimate intermediate node of a
            explicit path, and so on.</t>
          </list></t>

        <t>The STAMP Session-Sender generates the STAMP test packet with the
        HbH BW Utilization TLV. When an intermediate node receives the STAMP
        test packet, the node punts the packet to control plane and writes the
        ingress and egress bandwidth utilization at the BW Utilization Tuple
        list [n] in the Session-Sender test packet. The mechanism of punting
        packet to control plane is outside the scope of this
        specification.</t>

        <t>When the STAMP Session-Reflector received the test packet with the
        HbH BW Utilization TLV, it MUST copy the HbH BW Utilization TLV into
        the Session-Reflector test packet before its transmission. The HbH BW
        Utilization TLV carried in STAMP test packet is usable to detect and
        troubleshoot the link congestion in the forward path.</t>
      </section>

      <section title="HbH Timestamp Information TLV">
        <t>STAMP Session-Sender can place the HbH Timestamp Information TLV in
        Session-Sender test packets to record the ingress and egress Timestamp
        Information at every intermediate nodes along the forward path. The
        Timestamp Information includes the source of clock synchronization and
        the method of timestamp obtainment. There are several types of clock
        synchronization source, e.g., NTP, PTP. The method of timestamp
        obtainment may be from control plane (e.g. NTP) or from data plane
        (e.g. PTP).</t>

        <t>A Timestamp Info Tuple is composed of a 8-bit ingress clock source
        field, a 8-bit ingress timestamp obtainment field, a 8-bit egress
        clock source field, and a 8-bit egress timestamp obtainment field. The
        Session-Sender MUST set the Length value according to the number of
        explicitly listed intermediate nodes in the forward path. The
        Timestamp Info Tuple list [1..n] fields MUST be set to zero upon
        Session-Sender test packets transmission.</t>

        <t>The HbH Timestamp Information TLV has the following format:</t>

        <t><figure align="center"
            title="Fig. 6 HbH Timestamp Information TLV Format">
            <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
+-------------------------------+---------------+---------------+
|    HbH Timestamp Info Type    |     Length    |    Node Left  |
+-------------------------------+---------------+---------------+
|                Timestamp Info Tuple list [1]                  |
+---------------------------------------------------------------+
~                              ...                              ~
+---------------------------------------------------------------+
|                Timestamp Info Tuple list [n]                  |
+---------------------------------------------------------------+

]]></artwork>
          </figure></t>

        <t>where fields are defined as the following:</t>

        <t><list style="symbols">
            <t>HbH Timestamp Info Type: To be assigned by IANA.</t>

            <t>Length: A 8-bit field that indicates the length of the value
            portion in octets and will be a multiple of 4 octets dependent on
            the number of explicitly listed intermediate nodes in the forward
            path.</t>

            <t>Node Left: A 8-bit unsigned integer, which indicates the number
            of intermediate nodes remaining. That is, number of explicitly
            listed intermediate nodes still to be visited before reaching the
            destination node in the forward path. The Node Left field is set
            to n-1, where n is the number of intermediate nodes.</t>

            <t>Timestamp Info Tuple list [1..n]: A variable-length field,
            which record the source of clock synchronization and the method of
            timestamp obtainment at the ingress and egress when the test
            packet is received at and transmitted by the n-th intermediate
            node. The Timestamp Info Tuple list is encoded starting from the
            last intermediate node which is explicitly listed. That is, the
            first element of the Timestamp Info Tuple list [1] records the
            source of clock synchronization and the method of timestamp
            obtainment at the ingress and egress when the test packet is
            received at and transmitted by the last intermediate node of a
            explicit path, the second element records the penultimate
            Timestamp Info Tuple when the test packet received at and
            transmitted by the penultimate intermediate node of a explicit
            path, and so on.</t>
          </list></t>

        <t>The STAMP Session-Sender generates the STAMP test packet with the
        HbH Timestamp Information TLV. When an intermediate node receives the
        STAMP test packet, the node punts the packet to control plane and
        writes the source of clock synchronization and the method of timestamp
        obtainment at the Timestamp Info Tuple list [n] in the Session-Sender
        test packet. The mechanism of punting packet to control plane is
        outside the scope of this specification.</t>

        <t>When the STAMP Session-Reflector received the test packet with the
        HbH Timestamp Information TLV, it MUST copy the HbH Timestamp
        Information TLV into the Session-Reflector test packet before its
        transmission. The HbH Timestamp Information TLV carried in STAMP test
        packet is usable to query timestamp information from every nodes in
        the forward path.</t>

        <t>Note that the source of clock synchronization, NTP or PTP, is part
        of configuration of the Session-Sender/Reflector or a particular test
        session <xref target="RFC8762"/>. This draft recommends every
        intermediate nodes to be configured to use the same source of clock
        synchronization.</t>
      </section>

      <section title="HbH Interface Errors TLV">
        <t>STAMP Session-Sender can place the HbH Interface Errors TLV in
        Session-Sender test packets to record the errors detected on the
        interface of every intermediate node used to receive the packet along
        the forward path. The record of interface errors indicates the quality
        of the interfaces along the forward path and is helpful to analyze the
        performance degrades associated with the flow.</t>

        <t>A Interface Errors is a 32 bits unsigned integer field. This field
        records the Bit Error Rate (BER) or number of packet drop due to
        Cyclic Redundancy Check (CRC) errors. The Session-Sender MUST set the
        Length value according to the number of explicitly listed intermediate
        nodes in the forward path. The Interface Errors list [1..n] fields
        MUST be set to zero upon Session-Sender test packets transmission.</t>

        <t>The HbH Timestamp Information TLV has the following format:</t>

        <t><figure align="center"
            title="Fig. 6 HbH Timestamp Information TLV Format">
            <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
+-------------------------------+---------------+---------------+
|   HbH Interface Errors Type   |     Length    |    Node Left  |
+-------------------------------+---------------+---------------+
|                   Interface Errors list [1]                   |
+---------------------------------------------------------------+
~                              ...                              ~
+---------------------------------------------------------------+
|                   Interface Errors list [n]                   |
+---------------------------------------------------------------+

]]></artwork>
          </figure></t>

        <t>where fields are defined as the following:</t>

        <t><list style="symbols">
            <t>HbH Interface Errors Type: To be assigned by IANA.</t>

            <t>Length: A 8-bit field that indicates the length of the value
            portion in octets and will be a multiple of 4 octets dependent on
            the number of explicitly listed intermediate nodes in the forward
            path.</t>

            <t>Node Left: A 8-bit unsigned integer, which indicates the number
            of intermediate nodes remaining. That is, number of explicitly
            listed intermediate nodes still to be visited before reaching the
            destination node in the forward path. The Node Left field is set
            to n-1, where n is the number of intermediate nodes.</t>

            <t>Interface Errors list [1..n]: A variable-length field, which
            record the errors detected on the interface of the n-th
            intermediate node used to receive the packet along the forward
            path. The Interface Errors list is encoded starting from the last
            intermediate node which is explicitly listed. That is, the first
            element of the Interface Errors list [1] records the interface
            errors when the test packet is received at the last intermediate
            node of a explicit path, the second element records the
            penultimate interface errors when the test packet received at the
            penultimate intermediate node of a explicit path, and so on.</t>
          </list></t>

        <t>The STAMP Session-Sender generates the STAMP test packet with the
        HbH Interface Errors TLV. When an intermediate node receives the STAMP
        test packet, the node punts the packet to control plane and writes the
        errors at the Interface Errors list [n] in the Session-Sender test
        packet. The mechanism of punting packet to control plane is outside
        the scope of this specification.</t>

        <t>When the STAMP Session-Reflector received the test packet with the
        HbH Interface Errors TLV, it MUST copy the HbH Interface Errors TLV
        into the Session-Reflector test packet before its transmission. The
        HbH Interface Errors TLV carried in STAMP test packet is usable to
        detect interface errors from every intermediate nodes along the
        forward path.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>IANA is requested to allocate values for the following TLV Type from
      the "STAMP TLV Type" registry <xref target="RFC8972"/>.</t>

      <t/>

      <texttable align="center">
        <ttcol>Code Point</ttcol>

        <ttcol>Description</ttcol>

        <ttcol>Reference</ttcol>

        <c>TBA1</c>

        <c>IOAM Tracing Data TLV</c>

        <c>This document</c>

        <c>TBA2</c>

        <c>Forward HbH Delay TLV</c>

        <c>This document</c>

        <c>TBA3</c>

        <c>Backward HbH Delay TLV</c>

        <c>This document</c>

        <c>TBA4</c>

        <c>HbH Direct Loss TLV</c>

        <c>This document</c>

        <c>TBA5</c>

        <c>HbH BW Utilization TLV</c>

        <c>This document</c>

        <c>TBA6</c>

        <c>HbH Timestamp Information TLV</c>

        <c>This document</c>

        <c>TBA7</c>

        <c>HbH Interface Errors TLV</c>

        <c>This document</c>
      </texttable>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document extensions new optional TLVs to STAMP. It does not
      introduce any new security risks to STAMP.</t>
    </section>

    <section title="Contributors">
      <t>The following people made significant contributions to this
      document:</t>

      <t><figure>
          <artwork><![CDATA[
Yali Wang
Huawei
Email: wangyali11@huawei.com
]]></artwork>
        </figure></t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBD</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
	  
      <?rfc include="reference.RFC.8174"?>

      <reference anchor="RFC8762"
                 target="https://datatracker.ietf.org/doc/rfc8762/">
        <front>
          <title>Simple Two-Way Active Measurement Protocol</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC8972"
                 target="https://datatracker.ietf.org/doc/rfc8972/">
        <front>
          <title>Simple Two-way Active Measurement Protocol Optional
          Extensions</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="I-D.ietf-ippm-ioam-ipv6-options"
                 target="https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-ipv6-options/">
        <front>
          <title>In-situ OAM IPv6 Options</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC9197"
                 target="https://datatracker.ietf.org/doc/rfc9197/">
        <front>
          <title>Data Fields for In-situ OAM</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
    </references>

    <references title="Informative References">
      <reference anchor="RFC5905"
                 target="https://www.rfc-editor.org/info/rfc5905">
        <front>
          <title>Network Time Protocol Version 4: Protocol and Algorithms
          Specification</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="IEEE.1588.2008"
                 target="https://ieeexplore.ieee.org/document/4579760">
        <front>
          <title>IEEE Standard for a Precision Clock Synchronization Protocol
          for Networked Measurement and Control Systems</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
