IP Performance Measurement Group T. Zhou Internet-Draft G. Fioccola Intended status: Standards Track Huawei Expires: 25 April 2024 G. Mishra Verizon Inc. H. Yang China Mobile C. Liu China Unicom 23 October 2023 Simple Two-way Active Measurement Protocol (STAMP) Extensions for Hop- by-Hop Data Collection draft-wang-ippm-stamp-hbh-extensions-06 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 25 April 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Zhou, et al. Expires 25 April 2024 [Page 1] Internet-Draft draft-wang-ippm-stamp-hbh-extensions October 2023 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 . . . . . . . . . . . . . . 7 4.4. HbH Interface Errors TLV . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 have defined several optional TLVs to enhance the STAMP base functions. These optional TLVs are defined as updates of the STAMP Optional Extensions [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. Zhou, et al. Expires 25 April 2024 [Page 2] Internet-Draft draft-wang-ippm-stamp-hbh-extensions October 2023 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. Note that [I-D.gandhi-ippm-stamp-ioam] extends STAMP to carry IOAM (In-situ OAM) data fields for HBH and E2E two-way active measurement and telemetry. 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 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]. o------------------------------------------------------------o | Configuration and | | Management | o------------------------------------------------------------o || || || || || || || || || +--------------+ +--------------------+ +-----------------+ |Session-Sender| ... |Intermediate-Node(s)| ... |Session-Reflector| +--------------+ +------------- ------+ +-----------------+ <---------------------------- STAMP ----------------------------> Figure 1: Fig. 2 HbH STAMP Reference Model Zhou, et al. Expires 25 April 2024 [Page 3] Internet-Draft draft-wang-ippm-stamp-hbh-extensions October 2023 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: 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: Fig. 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. Zhou, et al. Expires 25 April 2024 [Page 4] Internet-Draft draft-wang-ippm-stamp-hbh-extensions October 2023 * 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. In the following reference topology, 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 along 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 along the backward path. ====== ====== ====== ====== ====== | | T1--->t1 | | t2--->t3 | | t4--->t5 | | t6--->T2| | | N1 |==========| N2 |==========| N3 |==========| N4 |=========| N5 | | | T4<---t12| |t11<---t10| | t9<---t8 | | t7<---T3| | ====== ====== ====== ====== ====== Figure 3: Fig. 3 Reference Topology Zhou, et al. Expires 25 April 2024 [Page 5] Internet-Draft draft-wang-ippm-stamp-hbh-extensions October 2023 The STAMP Session-Sender (i.e. Node N1) 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: 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: Fig. 4 HbH Loss TLV Format where fields are defined as the following: Zhou, et al. Expires 25 April 2024 [Page 6] Internet-Draft draft-wang-ippm-stamp-hbh-extensions October 2023 * 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. 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 Zhou, et al. Expires 25 April 2024 [Page 7] Internet-Draft draft-wang-ippm-stamp-hbh-extensions October 2023 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: Fig. 5 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. * 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. Zhou, et al. Expires 25 April 2024 [Page 8] Internet-Draft draft-wang-ippm-stamp-hbh-extensions October 2023 * 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. 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: Zhou, et al. Expires 25 April 2024 [Page 9] Internet-Draft draft-wang-ippm-stamp-hbh-extensions October 2023 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: Fig. 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. * 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. Zhou, et al. Expires 25 April 2024 [Page 10] Internet-Draft draft-wang-ippm-stamp-hbh-extensions October 2023 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: Yali Wang Huawei Email: wangyali11@huawei.com 8. Acknowledgements TBD 9. References 9.1. Normative References Zhou, et al. Expires 25 April 2024 [Page 11] Internet-Draft draft-wang-ippm-stamp-hbh-extensions October 2023 [I-D.gandhi-ippm-stamp-ioam] Gandhi, R., "Simple TWAMP (STAMP) Extensions for Hop-By- Hop and Edge-To-Edge Measurements", Work in Progress, Internet-Draft, draft-gandhi-ippm-stamp-ioam-00, 16 August 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, . [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, . 9.2. Informative References [IEEE.1588.2008] "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", . [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, . Authors' Addresses Tianran Zhou Huawei 156 Beijing Rd., Haidian District Beijing China Email: zhoutianran@huawei.com Zhou, et al. Expires 25 April 2024 [Page 12] Internet-Draft draft-wang-ippm-stamp-hbh-extensions October 2023 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 25 April 2024 [Page 13]