Simple Two-way Active Measurement Protocol (STAMP) Extensions for Hop- by-Hop Data Collection
draft-wang-ippm-stamp-hbh-extensions-07
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Tianran Zhou , Giuseppe Fioccola , Gyan Mishra , Hongwei Yang , Chang Liu | ||
| Last updated | 2024-04-24 | ||
| 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-07
IP Performance Measurement Group T. Zhou
Internet-Draft G. Fioccola
Intended status: Standards Track Huawei
Expires: 26 October 2024 G. Mishra
Verizon Inc.
H. Yang
China Mobile
C. Liu
China Unicom
24 April 2024
Simple Two-way Active Measurement Protocol (STAMP) Extensions for Hop-
by-Hop Data Collection
draft-wang-ippm-stamp-hbh-extensions-07
Abstract
This document describes how to use Simple Two-way Active Measurement
Protocol (STAMP) test packets in combination with Hybrid Methods to
perform Hop-By-Hop measurements in addition to the Edge-To-Edge
measurements. It also defines optional TLVs which are carried in
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.
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 26 October 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhou, et al. Expires 26 October 2024 [Page 1]
Internet-Draft draft-wang-ippm-stamp-hbh-extensions April 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. IPv6 HBH option with STAMP . . . . . . . . . . . . . . . . . 4
4.1. Alternate-Marking . . . . . . . . . . . . . . . . . . . . 5
4.2. IOAM . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 6
5.1. HbH Delay TLV . . . . . . . . . . . . . . . . . . . . . . 6
5.2. HbH Loss TLV . . . . . . . . . . . . . . . . . . . . . . 7
5.3. HbH Bandwidth Utilization TLV . . . . . . . . . . . . . . 9
5.4. HbH Interface Errors TLV . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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].
Zhou, et al. Expires 26 October 2024 [Page 2]
Internet-Draft draft-wang-ippm-stamp-hbh-extensions April 2024
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
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].
This document also 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 26 October 2024 [Page 3]
Internet-Draft draft-wang-ippm-stamp-hbh-extensions April 2024
o------------------------------------------------------------o
| Configuration and |
| Management |
o------------------------------------------------------------o
|| || ||
|| || ||
|| || ||
+--------------+ +--------------------+ +-----------------+
|Session-Sender| ... |Intermediate-Node(s)| ... |Session-Reflector|
+--------------+ +------------- ------+ +-----------------+
<---------------------------- STAMP ---------------------------->
Figure 1: HbH STAMP Reference Model
4. IPv6 HBH option with STAMP
As defined in [RFC7799], Hybrid Methods are characterized by the
augmentation or modification of the stream of interest. AltMark and
IOAM are two examples of Hybrid Methods. For IPv6, [RFC9343] and
[RFC9486] define the IPv6 HBH options of AltMark and IOAM
respectively.
The STAMP Session-Sender initiates a Session-Sender test packet and
the STAMP Session-Reflector transmits a reply Session-Reflector test
packet. The STAMP Session-Sender also adds the IPv6 HBH option in
the Session-Sender test packets to enable HBH measurements in the
forward direction. Intermediate nodes do not perform any STAMP
processing, but must support the IPv6 HBH option related methodology.
The Session-Reflector also adds the IPv6 HBH option in the reply
Session-Reflector test packets to enable HBH in the backward
direction as well.
+------------------------------------+
| IPv6 Header |
+------------------------------------+
| IPv6 HBH Option |
+------------------------------------+
| UDP Header |
+------------------------------------+
| STAMP Packet |
+------------------------------------+
Figure 2: STAMP Test Packet with IPv6 HbH Option
The previous figure represents an example STAMP test packet, which
includes an IPv6 HBH option. The intermediate nodes do not perform
any STAMP processing but can read and handle the IPv6 HBH Option if
they are configured to do so.
Zhou, et al. Expires 26 October 2024 [Page 4]
Internet-Draft draft-wang-ippm-stamp-hbh-extensions April 2024
4.1. Alternate-Marking
The Alternate Marking method can be used in combination with STAMP.
[RFC9343] defines the Hop-by-Hop Options Header and the Destination
Options Header to carry AltMark data fields.
The STAMP Session-Sender and Session-Reflector add the AltMark IPv6
HBH option [RFC9343] to the STAMP test packets. The intermediate
nodes must support Alternate Marking and can apply the methodology
according to [RFC9341] to perform loss and delay measurements. For
Alternate Marking, the source node is the only one that writes the
IPv6 HBH Option while the intermediate nodes can only read the IPv6
HBH Option, without modifying the packet.
The addition of the AltMark IPv6 HBH option augments the STAMP active
measurements by enabling HBH measurements together with the usual E2E
measurements. It is worth highlighting that this approach is not
adding any new functionalities to STAMP, but it is only leveraging
the existing AltMark mechanisms to measure the performance of
intermediate nodes and links that STAMP test packets traverse.
it is possible to use YANG [I-D.ydt-ippm-alt-mark-yang] to configure
and IPFIX [I-D.gfz-opsawg-ipfix-alt-mark] or YANG Push to report
AltMark telemetry information from each intermediate node to a
collector.
4.2. IOAM
IOAM can be used in combination with STAMP. [RFC9486] defines the
Hop-by-Hop Options Header and the Destination Options Header to carry
IOAM data fields.
The STAMP Session-Sender and Session-Reflector test packets carry the
IOAM IPv6 HBH option for recording and collecting HBH and E2E
operational and telemetry information for active measurement. The
intermediate nodes must support IOAM and process the IOAM data
fields. For IOAM, the source node and the intermediate nodes modify
the IPv6 HBH Option to include the needed information.
[I-D.gandhi-ippm-stamp-ext-hdr] extends STAMP to reflect back from
the Session-Reflector to the Session-Sender any IPv6 options and MPLS
Network Action Sub-Stacks for hop-by-hop and edge-to-edge active
measurements.
It is also be possible to use IPFIX/YANG Push/IOAM DEX to report
AltMark telemetry information from each intermediate node to a
collector.
Zhou, et al. Expires 26 October 2024 [Page 5]
Internet-Draft draft-wang-ippm-stamp-hbh-extensions April 2024
5. TLV Extensions to STAMP
5.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:
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 3: 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.
Zhou, et al. Expires 26 October 2024 [Page 6]
Internet-Draft draft-wang-ippm-stamp-hbh-extensions April 2024
* 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
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.
5.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
Zhou, et al. Expires 26 October 2024 [Page 7]
Internet-Draft draft-wang-ippm-stamp-hbh-extensions April 2024
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:
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 4: 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
Zhou, et al. Expires 26 October 2024 [Page 8]
Internet-Draft draft-wang-ippm-stamp-hbh-extensions April 2024
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.
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.
5.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 5: HbH Bandwidth Utilization TLV Format
Zhou, et al. Expires 26 October 2024 [Page 9]
Internet-Draft draft-wang-ippm-stamp-hbh-extensions April 2024
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.
* 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.
Zhou, et al. Expires 26 October 2024 [Page 10]
Internet-Draft draft-wang-ippm-stamp-hbh-extensions April 2024
5.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.
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 6: 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.
Zhou, et al. Expires 26 October 2024 [Page 11]
Internet-Draft draft-wang-ippm-stamp-hbh-extensions April 2024
* 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
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.
6. 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].
Zhou, et al. Expires 26 October 2024 [Page 12]
Internet-Draft draft-wang-ippm-stamp-hbh-extensions April 2024
+============+==========================+===============+
| 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
7. Security Considerations
This document extensions new optional TLVs to STAMP. It does not
introduce any new security risks to STAMP.
8. Contributors
The following people made significant contributions to this document:
Yali Wang
Huawei
Email: wangyali11@huawei.com
9. Acknowledgements
TBD
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, 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>.
Zhou, et al. Expires 26 October 2024 [Page 13]
Internet-Draft draft-wang-ippm-stamp-hbh-extensions April 2024
[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>.
[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>.
10.2. Informative References
[I-D.gandhi-ippm-stamp-ext-hdr]
Gandhi, R. and T. Zhou, "Simple Two-Way Active Measurement
Protocol (STAMP) Extensions for Reflecting STAMP Packet
Headers", Work in Progress, Internet-Draft, draft-gandhi-
ippm-stamp-ext-hdr-00, 6 February 2024,
<https://datatracker.ietf.org/doc/html/draft-gandhi-ippm-
stamp-ext-hdr-00>.
[I-D.gfz-opsawg-ipfix-alt-mark]
Graf, T., Fioccola, G., Zhou, T., Milan, F., and M. Nilo,
"IPFIX Alternate-Marking Information", Work in Progress,
Internet-Draft, draft-gfz-opsawg-ipfix-alt-mark-00, 23
October 2023, <https://datatracker.ietf.org/doc/html/
draft-gfz-opsawg-ipfix-alt-mark-00>.
Zhou, et al. Expires 26 October 2024 [Page 14]
Internet-Draft draft-wang-ippm-stamp-hbh-extensions April 2024
[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-
04, 21 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-hdr-04>.
[I-D.ydt-ippm-alt-mark-yang]
Graf, T., Wang, M., Fioccola, G., Zhou, T., Min, X., Jun,
G., Nilo, M., and L. Han, "A YANG Data Model for the
Alternate Marking Method", Work in Progress, Internet-
Draft, draft-ydt-ippm-alt-mark-yang-01, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ydt-ippm-alt-
mark-yang-01>.
[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>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
Authors' Addresses
Tianran Zhou
Huawei
156 Beijing Rd., Haidian District
Beijing
China
Email: zhoutianran@huawei.com
Giuseppe Fioccola
Huawei
Email: giuseppe.fioccola@huawei.com
Gyan Mishra
Verizon Inc.
Email: gyan.s.mishra@verizon.com
Zhou, et al. Expires 26 October 2024 [Page 15]
Internet-Draft draft-wang-ippm-stamp-hbh-extensions April 2024
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 26 October 2024 [Page 16]