Internet-Draft Asymmetrical Packets in STAMP October 2024
Mirsky, et al. Expires 18 April 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-ietf-ippm-asymmetrical-pkts-02
Published:
Intended Status:
Standards Track
Expires:
Authors:
G. Mirsky
Ericsson
E. Ruffini
OutSys
H. Nydell
Cisco Systems
R. Foote
Nokia

Performance Measurement with Asymmetrical Packets in STAMP

Abstract

This document describes an optional extension to a Simple Two-way Active Measurement Protocol (STAMP) that enables the use of STAMP test and reflected packets of variable length during a single STAMP test session. In some use cases, the use of asymmetrical test packets allow for the creation of more realistic flows of test packets and, thus, a closer approximation between active performance measurements and conditions experienced by the monitored application.

Also, the document includes an analysis of challenges related to performance monitoring in a multicast network. It defines procedures and STAMP extensions to achieve more efficient measurements with a lesser impact on a network.

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

Table of Contents

1. Introduction

Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] defined the STAMP base functionalities. STAMP Protocol Optional Extensions [RFC8972] introduces a TLV structure that allows the Session-Sender to include optional instructions for Session-Reflector. New STAMP TLVs can be defined to support the scenarios in [RFC7497], which discusses the coordination of messaging between the source and destination to help deliver one of the fundamental principles of IP performance metric measurements, minimizing the test traffic effect on user flows. In some scenarios, e.g., rate measurements discussed in [RFC7497], it is beneficial not only to use a variable size of the test packets transmitted downstream while controlling length, number, and interpacket interval for reflected test packets.

Measurement of performance metrics in a multicast network using an active measurement method has specific challenges compared to what operators experience monitoring in a unicast network. This document analyzes these challenges, and defines procedures and STAMP extensions to achieve more efficient measurements with a lesser impact on a network.

1.1. Abbreviations

STAMP Simple Two-way Active Measurement Protocol

DoS Denial-of-Service

1.2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Reflected Test Packet Control TLV

This document defines a new optional STAMP extension, Reflected Test Packet Control TLV. The format of the Reflected Test Packet Control TLV is presented in Figure 1.

  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|      Type     |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  Length of the Reflected Packet               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                 Number of the Reflected Packets               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Interval Between the Reflected Packets            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                            Sub-TLVs                           ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Reflected Test Packet Control TLV Format

The interpretation of the fields is as follows:

A Session-Sender MAY include the Reflected Test Packet Control TLV in a STAMP test packet. If the received STAMP test packet includes the Reflected Test Packet Control TLV, the Session-Reflector MUST transmit a sequence of reflected test packets according to the following rules:

2.1. Address Group Sub-TLVs

2.1.1. Layer 2 Address Group Sub-TLV

Layer 2 Address Group sub-TLV: A 16-octet sub-TLV that includes the EUI-48 Address Group Mask and EUI-48 Address Group. The Type value is TBA2 (Section 6.2). The value of the Length field MUST be equal to 12. The format of Layer 2 Address Group sub-TLV is presented in Figure 2.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     EUI-48 Address Group Mask                 |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|                               |
|                       EUI-48 Address Group                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Layer 2 Address Group Sub-TLV Format

The Value field consists of the following fields:

  • EUI-48 Address Group Mask: A six-octet field that represents the bitmask to be applied to the Session-Reflector MAC Address.
  • EUI-48 Address Group: A six-octet field that represents the group this TLV is addressed to. If the Session-Reflector applies EUI-48 Address Group Mask to its MAC Address and the result is different from EUI-48 Address Group, then the Session-Reflector MUST stop processing the received test packet.

2.1.2. Layer 3 Address Group Sub-TLV

Layer 3 Address Group sub-TLV: A variable-length sub-TLV that includes the IP Address Family, IP Network Prefix, and IP Prefix Length. The Type value is TBA3 (Section 6.2). The value of the Length field MUST be equal to 8 or 20. The format of Layer 3 Address Group sub-TLV is presented in Figure 3.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family| Prefix Length |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                       IP Network Prefix                       ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Layer 3 Address Group Sub-TLV Format

The Value field consists of the following fields:

  • Address Family: A one-octet field that indicates the type of IP address contained in the IP Network Prefix field. If that is IPv4 address, then the value MUST be set to 1. For the IPv6 address, the value MUST be set to 2. Other values MUST be considered invalid.
  • Prefix Length: A one-octet unsigned integer field that contains the length, in bits, of the network prefix part of the value in the IP Network Prefix field.
  • Reserved: A two-octet field. The field MUST be zeroed on transmission and ignored on receipt.
  • IP Network Prefix: A variable-length field. Depending on the value of the Address Family field, the field contains either IPv4, or IPv6 address. If the former, the length is four octets; if the latter - 16 octets.

3. Theory of Operation

3.1. Rate Measurement

[RFC7497] defines the problem of access rate measurement in access networks. Essential requirements identified for a test protocol are the ability to control packet characteristics on the tested path, such as asymmetric rate and asymmetric packet size. The Reflected Test Packet Control TLV, defined in Section 2, conforms to the requirements for measuring access rate by providing optional controls of the number of reflected test packets, the size of the reflected packet(s), and the time interval, i.e., rate, in transmitting the sequence of the reflected test packets.

3.2. Active Performance Measurement in Multicast Environment

According to [RFC8972], a STAMP Session is demultiplexed by a Session-Reflector by the tuple that consists of source and destination IP addresses, source and destination UDP port numbers, or the source IP address and STAMP Session Identifier. That is also the case of the monitoring performance of a multicast flow, despite that the destination IP address is multicast. Therefore the behavior of a Session-Reflector upon receiving a STAMP test packet over a multicast tree is as defined in [RFC8762] and [RFC8972]. The Session-Reflector MUST use the source IP address of the received STAMP test packet as the destination IP address of the reflected test packet, and MUST use one of the IP addresses associated with the node as the source IP address for that packet.

The Session-Sender has to pay more attention when sending a multicast STAMP packet. Instead of possibly, receiving a reply from a Session-Reflector may now receive multiple replies from multiple counterparts: its STAMP Session has a 1:N relation. Network traffic is another aspect that needs attention: network congestion may happen if a single packet can generate millions of concurrent replies, all directed to the same endpoint. Adding a Reflected Test Packet Control TLV allows Session-Sender to limit the number of replies. It may do so by selecting Session-Reflectors, for example:

  • Randomly by specifying a Layer 2 Address Group Sub-TLV: for example, setting the EUI-48 Address Group Mask to 0xF and the EUI-48 Address Group to 0x1. As a result, only 1 out of 16 reflectors will reply;
  • Having a specific vendor NIC by specifying a Layer 2 Address Group Sub-TLV with the EUI-48 Address Group Mask set to 0xFFFFFF000000;
  • Belonging to specific IP networks, for example, a subnet dedicated to IPv6 over IPv4 encapsulation by specifying the appropriate Layer 3 Address Group Sub-TLV.

Multicast traffic is also intrinsically asymmetrical, and focus on the return path is usually limited. The Length of the Reflected Packet value can be used to ensure the reflected packet transports all the timestamps and requested information, crucial for the underlying measure, but is as short as possible so as not to flood the network with useless data.

3.3. Using Reflected Test Packet Control TLV in Combination with Other TLVs

[RFC9503] defines the Return Path TLV that, when used in the combination with the Return Address Sub-TLV, allows a Session-Sender to request the reflected packet be sent to a different address from the Session-Sender one. These STAMP extensions could be used in combination with the Reflected Packet Control TLV, defined in this document, to direct the reflected STAMP test packets to a collector of measurement data (according to [RFC7594]) for further processong and network analytics. An example of the use case could be used in the multicast scenario when, for example, the Session-Sender is close to the actual multicast frames generator (for example, a camera transmitting live video) so that the test packets follow the same path as the video stream packets in one direction. The data center where the test data are analyzed could be far away, and it would be better to have reflected packets return there.

For compatibility with [RFC9503], a Session-Sender MUST NOT include a Return Path Control Code Sub-TLV with the Control Code flag set to No Reply Requested in the same test packet as the Reflected Test Packet Control TLV is non-zero. A Session-Reflector that supports both TLVs MUST set the U flag in Return Path and Reflected Test Packet Control TLVs in the reflected STAMP packet. Furthermore, the Session-Reflector SHOULD log a notification to inform an operator about the misconstructed STAMP packet.

4. Security Considerations

Security considerations discussed in [RFC8762],[RFC8972], and [RFC9503] apply to this document. Furthermore, spoofed STAMP test packets with the Reflected Test Packet Control TLV can be exploited to conduct a Denial-of-Service (DoS) attack. Hence, implementations MUST use an identity protection mechanism. For example, verify the information about the source of the STAMP packet against a pre-defined list of trusted nodes. Also, STAMP authentication mode [RFC8762] or HMAC TLV [RFC8972] could be used for a STAMP test session containing the Reflected Test Packet Control TLV.

Furthermore, a DoS attack using the Reflected Test Packet Control TLV might target the STAMP Session-Reflector by overloading it with test packet reflection, e.g., extremely small intervals and/or too many concurrent test sessions. To mitigate that, an implementation that supports the new TLV MUST control the rate and volume of reflection of STAMP test packets by the Session-Reflector.

Considering the potential number of reflected packets that can be generated by a single test packet sent to a multicast address, a Session-Sender SHOULD sign packets using the HMAC TLV when sending such messages. But even with the HMAC TLV, the Reflected Test Packet Control TLV could be exploited for the replay attack. To mitigate that risk, a STAMP Session-Reflector SHOULD use the value of Sequence Number field [RFC8762] of the received STAMP test packet. If that value compared to the received in the previous test packet of the same STAMP test session is not increasing, then the Session-Reflector MUST respond with a single reflected packet, setting the U flag to 1 [RFC8972].

A Session-Sender SHOULD NOT send the next STAMP test packet with the Reflected Test Packet Control TLV before the Session-Reflector is expected to complete transmitting all reflected packets in response to the Reflected Test Packet Control TLV in the previous test packet.

5. Acknowledgments

TBA

6. IANA Considerations

6.1. Reflected Test Packet Control TLV Type

The IANA is requested to assign a new value for the Reflected Test Packet Control TLV from the STAMP TLV Types registry according to Table 1.

Table 1: New Reflected Test Packet Control Type TLV
Value Description Reference
 TBA1 Reflected Test Packet Control This document

6.2. Reflected Test Packet Control TLV Type

The IANA is requested to assign a new value for the Reflected Test Packet Control TLV from the STAMP Sub-TLV Types registry according to Table 2.

Table 2: STAMP sub-TLV Types for the Reflected Test Packet Control TLV
Value Description TLV Used Reference
 TBA2 Layer 2 Address Group Reflected Test Packet Control TLV This document
 TBA3 Layer 3 Address Group Reflected Test Packet Control TLV This document

7. References

7.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8762]
Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, , <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, , <https://www.rfc-editor.org/info/rfc8972>.
[RFC9503]
Gandhi, R., Ed., Filsfils, C., Chen, M., Janssens, B., and R. Foote, "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks", RFC 9503, DOI 10.17487/RFC9503, , <https://www.rfc-editor.org/info/rfc9503>.

7.2. Informative References

[RFC7497]
Morton, A., "Rate Measurement Test Protocol Problem Statement and Requirements", RFC 7497, DOI 10.17487/RFC7497, , <https://www.rfc-editor.org/info/rfc7497>.
[RFC7594]
Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, , <https://www.rfc-editor.org/info/rfc7594>.

Authors' Addresses

Greg Mirsky
Ericsson
Ernesto Ruffini
OutSys
via Caracciolo, 65
20155 Milano
Italy
Henrik Nydell
Cisco Systems
Richard Foote
Nokia