Skip to main content

Simple Two-way Active Measurement Protocol (STAMP) Extensions for Hop- by-Hop Data Collection
draft-wang-ippm-stamp-hbh-extensions-08

Document Type Active Internet-Draft (individual)
Authors Tianran Zhou , Giuseppe Fioccola , Gyan Mishra , Hongwei Yang , Chang Liu
Last updated 2024-10-16
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-wang-ippm-stamp-hbh-extensions-08
IP Performance Measurement Group                                 T. Zhou
Internet-Draft                                               G. Fioccola
Intended status: Standards Track                                  Huawei
Expires: 19 April 2025                                         G. Mishra
                                                            Verizon Inc.
                                                                 H. Yang
                                                            China Mobile
                                                                  C. Liu
                                                            China Unicom
                                                         16 October 2024

 Simple Two-way Active Measurement Protocol (STAMP) Extensions for Hop-
                         by-Hop Data Collection
                draft-wang-ippm-stamp-hbh-extensions-08

Abstract

   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 performance
   measurement and collection at every node and link along a STAMP test
   packet's delivery path.  It enables Hop-By-Hop measurements in
   addition to the Edge-To-Edge measurements.

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 19 April 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Zhou, et al.              Expires 19 April 2025                 [Page 1]
Internet-Draft    draft-wang-ippm-stamp-hbh-extensions      October 2024

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Operation and Management of HbH STAMP Performance
           Measurements  . . . . . . . . . . . . . . . . . . . . . .   3
   4.  TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . .   4
     4.1.  HbH Delay TLV . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  HbH Loss TLV  . . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  HbH Bandwidth Utilization TLV . . . . . . . . . . . . . .   8
     4.4.  HbH Interface Errors TLV  . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  11
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Simple Two-way Active Measurement Protocol (STAMP) [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.  STAMP Extensions can enhance the STAMP base functions
   with optional TLVs.  These optional TLVs can be defined as updates of
   the STAMP Optional Extensions introduced in [RFC8972].

   In several scenarios it is beneficial to perform Hop-By-Hop (HBH) and
   Edge-To-Edge (E2E) active measurements.  Alternate Marking (AltMark)
   [RFC9341] and In Situ Operations, Administration, and Maintenance
   (IOAM) [RFC9197] are Hybrid Methods, which can be employed to perform
   HBH and E2E active measurements by using STAMP packets and by

Zhou, et al.              Expires 19 April 2025                 [Page 2]
Internet-Draft    draft-wang-ippm-stamp-hbh-extensions      October 2024

   leveraging the existing AltMark and IOAM options.  AltMark and IOAM
   data fields can be encoded in the Options Headers (Hop-by-Hop or
   Destination), according to [RFC8200].  The AltMark IPv6 HBH option
   [RFC9343] and the IOAM IPv6 HBH option [RFC9486] can be coupled with
   a STAMP session and carried in each STAMP test packet to enable HBH
   measurements.  Similarly to IPv6, MPLS packets can carry MPLS Network
   Action (MNA) Sub-Stack as defined in [I-D.ietf-mpls-mna-hdr].
   [I-D.fioccola-ippm-on-path-active-measurements] describes how to use
   STAMP or other active tools in combination with Hybrid Methods to
   perform Hop-By-Hop measurements in addition to the Edge-To-Edge
   measurements.

   This document introduces optional TLVs to STAMP, which enable
   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.  Therefore, the STAMP test packets, which are
   transmitted along a path between a Session-Sender and a Session-
   Reflector to measure only Edge-To-Edge (E2E) performance delay and
   packet loss along that path, can be augmented to measure Hop-By-Hop
   (HbH) parameters.  This document introduces Extensions to STAMP for
   HbH Delay, HbH Loss, HbH Bandwidth Utilization, HbH Interface Errors.

2.  Requirements Language

   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 RFC 2119 [RFC2119],
   RFC 8174 [RFC8174].

3.  Operation and Management of HbH STAMP Performance Measurements

   The next figure presents the STAMP Session-Sender, Intermediate-
   Node(s) and Session-Reflector with a measurement session.  A
   measurement session is also referred to as a STAMP session and it is
   the bidirectional packet flow between one specific Session-Sender and
   one particular Session-Reflector for a time duration.

   The Intermediate-Nodes are nodes which do not necessarily need to
   perform any STAMP processing.  If they support the HbH STAMP
   Extensions defined in this document, they can read and write the HbH
   STAMP Extensions.

   The configuration and management of the STAMP Session-Sender,
   Intermediate-Node(s), Session-Reflector, and sessions are outside the
   scope of this document and can be achieved through various means, as
   mentioned in [RFC8762].

Zhou, et al.              Expires 19 April 2025                 [Page 3]
Internet-Draft    draft-wang-ippm-stamp-hbh-extensions      October 2024

     o------------------------------------------------------------o
     |                     Configuration and                      |
     |                        Management                          |
     o------------------------------------------------------------o
         ||                        ||                        ||
         ||                        ||                        ||
         ||                        ||                        ||
   +--------------+     +--------------------+     +-----------------+
   |Session-Sender| ... |Intermediate-Node(s)| ... |Session-Reflector|
   +--------------+     +------------- ------+     +-----------------+
    <---------------------------- STAMP ---------------------------->

                    Figure 1: HbH STAMP Reference Model

4.  TLV Extensions to STAMP

4.1.  HbH Delay TLV

   STAMP Session-Sender can place the 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
   path.  The Session-Sender MUST set the Length value according to the
   number of explicitly listed intermediate nodes along the path and the
   timestamp formats.  There are several methods to synchronize the
   clock, e.g., Network Time Protocol (NTP) [RFC5905] and IEEE 1588v2
   Precision Time Protocol (PTP) [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.

   The HbH Delay TLV has the following format:

Zhou, et al.              Expires 19 April 2025                 [Page 4]
Internet-Draft    draft-wang-ippm-stamp-hbh-extensions      October 2024

    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| HbH Delay Type|         Length                |
   +---------------+---------------+-------------------------------+
   |                                                               |
   |                     Timestamp Tuple list [1]                  |
   |                                                               |
   |                                                               |
   +---------------------------------------------------------------+
   ~                              ...                              ~
   +---------------------------------------------------------------+
   |                                                               |
   |                     Timestamp Tuple list [n]                  |
   |                                                               |
   |                                                               |
   +---------------------------------------------------------------+

                       Figure 2: HbH Delay TLV Format

   where fields are defined as the following:

   *  STAMP TLV Flags: The STAMP TLV Flags follow the procedures
      described in [RFC8972].

   *  HbH Delay Type: To be assigned by IANA.

   *  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 along the path.

   *  Node Left: A 8-bit unsigned integer, which indicates the number of
      intermediate nodes remaining.  It is the number of explicitly
      listed intermediate nodes still to be visited before reaching the
      destination node.  The Node Left field is set to n-1, where n is
      the number of intermediate nodes.

   *  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

Zhou, et al.              Expires 19 April 2025                 [Page 5]
Internet-Draft    draft-wang-ippm-stamp-hbh-extensions      October 2024

      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.

   The STAMP Session-Sender generates the STAMP test packet with the 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 the egress timestamp [n] field.  The mechanism of
   timestamping and punting packet to control plane is outside the scope
   of this specification.

   When the STAMP Session-Reflector received the test packet with the
   HbH Delay TLV, it MUST copy the HbH Delay TLV into the Session-
   Reflector test packet before its transmission.  Using HbH Delay TLV
   in STAMP testing enables HbH delay measurement.

4.2.  HbH Loss TLV

   STAMP Session-Sender can place the HbH 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
   path.  The Session-Sender MUST set the Length value according to the
   number of explicitly listed intermediate nodes in the 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.

   The HbH Loss TLV has the following format:

Zhou, et al.              Expires 19 April 2025                 [Page 6]
Internet-Draft    draft-wang-ippm-stamp-hbh-extensions      October 2024

    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| HbH Loss Type |         Length                |
   +---------------+---------------+-------------------------------+
   |                                                               |
   |                     Counter Tuple list [1]                    |
   |                                                               |
   |                                                               |
   +---------------------------------------------------------------+
   ~                              ...                              ~
   +---------------------------------------------------------------+
   |                                                               |
   |                     Counter Tuple list [n]                    |
   |                                                               |
   |                                                               |
   +---------------------------------------------------------------+

                       Figure 3: HbH Loss TLV Format

   where fields are defined as the following:

   *  STAMP TLV Flags: The STAMP TLV Flags follow the procedures
      described in [RFC8972].

   *  HbH Loss Type: To be assigned by IANA.

   *  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 along the path.

   *  Node Left: A 8-bit unsigned integer, which indicates the number of
      intermediate nodes remaining.  It is the number of explicitly
      listed intermediate nodes still to be visited before reaching the
      destination node.  The Node Left field is set to n-1, where n is
      the number of intermediate nodes.

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

Zhou, et al.              Expires 19 April 2025                 [Page 7]
Internet-Draft    draft-wang-ippm-stamp-hbh-extensions      October 2024

   The STAMP Session-Sender generates the STAMP test packet with the HbH
   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.

   When the STAMP Session-Reflector received the test packet with the
   HbH Loss TLV, it MUST copy the HbH Loss TLV into the Session-
   Reflector test packet before its transmission.  Using HbH Loss TLV in
   STAMP testing enables packet HbH loss measurement.

4.3.  HbH Bandwidth Utilization TLV

   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 path.
   The Session-Sender MUST set the Length value according to the number
   of explicitly listed intermediate nodes along the 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.

   The HbH Bandwidth Utilization TLV has the following format:

    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| HbH BW U. Type|         Length                |
   +---------------+---------------+-------------------------------+
   |                BW Utilization Tuple list [1]                  |
   |                                                               |
   +---------------------------------------------------------------+
   ~                              ...                              ~
   +---------------------------------------------------------------+
   |                BW Utilization Tuple list [n]                  |
   |                                                               |
   +---------------------------------------------------------------+

               Figure 4: HbH Bandwidth Utilization TLV Format

   where fields are defined as the following:

   *  STAMP TLV Flags: The STAMP TLV Flags follow the procedures
      described in [RFC8972].

   *  HbH BW Utilization Type: To be assigned by IANA.

Zhou, et al.              Expires 19 April 2025                 [Page 8]
Internet-Draft    draft-wang-ippm-stamp-hbh-extensions      October 2024

   *  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 along the path.

   *  Node Left: A 8-bit unsigned integer, which indicates the number of
      intermediate nodes remaining.  It is the number of explicitly
      listed intermediate nodes still to be visited before reaching the
      destination node.  The Node Left field is set to n-1, where n is
      the number of intermediate nodes.

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

   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.

   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 useful to detect
   and troubleshoot the link congestion.

4.4.  HbH Interface Errors TLV

   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 path.  The record of interface errors indicates the quality of
   the interfaces along the path and is helpful to analyze the
   performance degrades associated with the flow.

Zhou, et al.              Expires 19 April 2025                 [Page 9]
Internet-Draft    draft-wang-ippm-stamp-hbh-extensions      October 2024

   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 along the path.  The Interface Errors list [1..n]
   fields MUST be set to zero upon Session-Sender test packets
   transmission.

   The HbH Timestamp Information TLV has the following format:

    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| HbH I.E. Type |         Length                |
   +---------------+---------------+-------------------------------+
   |                   Interface Errors list [1]                   |
   +---------------------------------------------------------------+
   ~                              ...                              ~
   +---------------------------------------------------------------+
   |                   Interface Errors list [n]                   |
   +---------------------------------------------------------------+

                 Figure 5: HbH Interface Errors TLV Format

   where fields are defined as the following:

   *  STAMP TLV Flags: The STAMP TLV Flags follow the procedures
      described in [RFC8972].

   *  HbH Interface Errors Type: To be assigned by IANA.

   *  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 along the path.

   *  Node Left: A 8-bit unsigned integer, which indicates the number of
      intermediate nodes remaining.  It is the number of explicitly
      listed intermediate nodes still to be visited before reaching the
      destination node.  The Node Left field is set to n-1, where n is
      the number of intermediate nodes.

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

Zhou, et al.              Expires 19 April 2025                [Page 10]
Internet-Draft    draft-wang-ippm-stamp-hbh-extensions      October 2024

      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.

   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.

   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 useful to
   detect interface errors from every intermediate nodes.

5.  IANA Considerations

   IANA has created the "STAMP TLV Types" registry for [RFC8972].  IANA
   is requested to allocate values for the following "HbH STAMP" TLV
   Type from the "STAMP TLV Types" registry [RFC8972].

         +============+==========================+===============+
         | Code Point | Description              | Reference     |
         +============+==========================+===============+
         | TBA1       | HbH Delay TLV            | This document |
         +------------+--------------------------+---------------+
         | TBA2       | HbH Loss TLV             | This document |
         +------------+--------------------------+---------------+
         | TBA3       | HbH BW Utilization TLV   | This document |
         +------------+--------------------------+---------------+
         | TBA4       | HbH Interface Errors TLV | This document |
         +------------+--------------------------+---------------+

                                  Table 1

6.  Security Considerations

   This document extensions new optional TLVs to STAMP.  It does not
   introduce any new security risks to STAMP.

7.  Contributors

   The following people made significant contributions to this document:

Zhou, et al.              Expires 19 April 2025                [Page 11]
Internet-Draft    draft-wang-ippm-stamp-hbh-extensions      October 2024

   Yali Wang
   Huawei
   Email: wangyali11@huawei.com

8.  Acknowledgements

   TBD

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <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, July 2017,
              <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, March 2020,
              <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, January 2021,
              <https://www.rfc-editor.org/info/rfc8972>.

   [RFC9197]  Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
              Ed., "Data Fields for In Situ Operations, Administration,
              and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
              May 2022, <https://www.rfc-editor.org/info/rfc9197>.

   [RFC9341]  Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
              and T. Zhou, "Alternate-Marking Method", RFC 9341,
              DOI 10.17487/RFC9341, December 2022,
              <https://www.rfc-editor.org/info/rfc9341>.

Zhou, et al.              Expires 19 April 2025                [Page 12]
Internet-Draft    draft-wang-ippm-stamp-hbh-extensions      October 2024

   [RFC9343]  Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
              Pang, "IPv6 Application of the Alternate-Marking Method",
              RFC 9343, DOI 10.17487/RFC9343, December 2022,
              <https://www.rfc-editor.org/info/rfc9343>.

   [RFC9486]  Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for
              In Situ Operations, Administration, and Maintenance
              (IOAM)", RFC 9486, DOI 10.17487/RFC9486, September 2023,
              <https://www.rfc-editor.org/info/rfc9486>.

9.2.  Informative References

   [I-D.fioccola-ippm-on-path-active-measurements]
              Fioccola, G., "On-Path Telemetry for Active Performance
              Measurements", Work in Progress, Internet-Draft, draft-
              fioccola-ippm-on-path-active-measurements-01, 14 October
              2024, <https://datatracker.ietf.org/doc/html/draft-
              fioccola-ippm-on-path-active-measurements-01>.

   [I-D.ietf-mpls-mna-hdr]
              Rajamanickam, J., Gandhi, R., Zigler, R., Song, H., and K.
              Kompella, "MPLS Network Action (MNA) Sub-Stack Solution",
              Work in Progress, Internet-Draft, draft-ietf-mpls-mna-hdr-
              08, 30 August 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
              mna-hdr-08>.

   [IEEE.1588.2008]
              "IEEE Standard for a Precision Clock Synchronization
              Protocol for Networked Measurement and Control Systems",
              <https://ieeexplore.ieee.org/document/4579760>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

Authors' Addresses

   Tianran Zhou
   Huawei
   156 Beijing Rd., Haidian District
   Beijing
   China
   Email: zhoutianran@huawei.com

Zhou, et al.              Expires 19 April 2025                [Page 13]
Internet-Draft    draft-wang-ippm-stamp-hbh-extensions      October 2024

   Giuseppe Fioccola
   Huawei
   Email: giuseppe.fioccola@huawei.com

   Gyan Mishra
   Verizon Inc.
   Email: gyan.s.mishra@verizon.com

   Hongwei Yang
   China Mobile
   Xibianmen Inner St, 53, Xicheng District
   Beijing
   China
   Email: yanghongwei@chinamobile.com

   Chang Liu
   China Unicom
   Beijing
   China
   Email: liuc131@chinaunicom.cn

Zhou, et al.              Expires 19 April 2025                [Page 14]