RFC 9534: Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group

Abstract

This document extends Simple Two-way Active Measurement Protocol (STAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce a performance-based traffic steering policy across the member links.¶

1. Introduction

A Link Aggregation Group (LAG), as defined in [IEEE802.1AX], provides mechanisms to combine multiple physical links into a single logical link. This logical link offers higher bandwidth and better resiliency because, if one of the physical member links fails, the aggregate logical link can continue to forward traffic over the remaining operational physical member links.¶

Usually, when forwarding traffic over a LAG, a hash-based mechanism is used to load balance the traffic across the LAG member links. The link delay might vary between member links because of different transport paths, especially when a LAG is used in a wide area network. To provide low-latency service for time-sensitive traffic, we need to explicitly steer the traffic across the LAG member links based on the link delay, loss, and so on. That requires a solution to measure the performance metrics of each member link of a LAG. Hence, the measured performance metrics can work together with Layer 2 bundle member link attributes advertisement [RFC8668] for traffic steering.¶

According to the classifications in [RFC7799], Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] is an active measurement method, and it can complement passive and hybrid methods. It provides a mechanism to measure both one-way and round-trip performance metrics, like delay, delay variation, and packet loss. A STAMP test session over the LAG can be used to measure the performance of a member link using a specially constructed 5-tuple. The session can be used to measure an average of some or all member links of the LAG by varying one or more elements of that 5-tuple. However, without the knowledge of each member link, a STAMP test session cannot measure the performance of every physical member link.¶

This document extends STAMP to implement performance measurement on every member link of a LAG. It can provide the same metrics as One-Way Active Measurement Protocol (OWAMP) [RFC4656] and Two-Way Active Measurement Protocol (TWAMP) [RFC5357] can measure, such as delay, jitter, and packet loss.¶

2. Micro Sessions on a LAG

This document addresses the scenario where a LAG directly connects two nodes. An example of this is in Figure 1, where the LAG consisting of four links connects nodes A and B. The goal is to measure the performance of each link of the LAG.¶

                  +---+                       +---+
                  |   |-----------------------|   |
                  | A |-----------------------| B |
                  |   |-----------------------|   |
                  |   |-----------------------|   |
                  +---+                       +---+

To measure the performance metrics of every member link of a LAG, multiple sessions (one session for each member link) need to be established between the two endpoints that are connected by the LAG. These sessions are called "micro sessions" in the remainder of this document. Although micro sessions are in fact STAMP sessions established on member links of a LAG, test packets of micro sessions MUST carry member link information for validation.¶

All micro sessions of a LAG share the same Sender IP Address and Receiver IP Address. As for the UDP port, the micro sessions may share the same Sender Port and Receiver Port pair or each micro session may be configured with a different Sender Port and Receiver Port pair. From the operational point of view, the former is simpler and is RECOMMENDED.¶

Test packets of a micro session MUST carry the member link information for validation checks. For example, when a micro STAMP Session-Sender receives a reflected test packet, it checks whether the test packet is from the expected member link. The member link information is encoded in the Micro-session ID TLV introduced in Section 3, which also provides a detailed description about member link validation.¶

A micro STAMP Session-Sender MAY include the Follow-Up Telemetry TLV [RFC8972] to request information from the micro Session-Reflector. This timestamp might be important for the micro Session-Sender, as it improves the accuracy of network delay measurement by minimizing the impact of egress queuing delays on the measurement.¶

4. Applicability

The micro STAMP Session-Sender sends micro Session-Sender packets with the Micro-session ID TLV. The micro Session-Reflector checks whether a test packet is received from the member link associated with the correct micro STAMP session if the Reflector Micro-session ID field is set. When reflecting, the micro STAMP Session-Reflector copies the Sender Micro-session ID from the received micro Session-Sender packet to the micro Session-Reflector packet and sets the Reflector Micro-session ID field with the member link identifier that is associated with the micro STAMP session. When receiving the micro Session-Reflector packet, the micro Session-Sender uses the Sender Micro-session ID to check whether the packet is received from the member link associated with the correct micro STAMP session. The micro Session-Sender also use the Reflector Micro-session ID to validate the Reflector's behavior.¶

7. References