RFC 9534

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

📅 published January 2024, from ietf

okay bestie, this is RFC 9534 💖 It's a Standards Track document, which means it's an actual Internet Standard in the making 💅 It was written by Z. Li (China Mobile), T. Zhou (Huawei), J. Guo (ZTE Corp.), G. Mirsky (Ericsson), and R. Gandhi (Cisco Systems, Inc.). It's dated January 2024, the ISSN is 2070-1721, and the title block doesn't list anything it obsoletes or updates ✨

Here's the table of contents, so you can see the whole layout 🌸

Table of Contents

   1.  Introduction
     1.1.  Requirements Language
   2.  Micro Sessions on a LAG
   3.  Member Link Validation
     3.1.  Micro-session ID TLV
     3.2.  Micro STAMP-Test Procedures
   4.  Applicability
   5.  IANA Considerations
   6.  Security Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Acknowledgements
   Authors' Addresses

Abstract 🎀

okay so this document extends Simple Two-way Active Measurement Protocol (STAMP) so you can measure performance on every member link of a Link Aggregation Group (LAG) 🔥 Why is that iconic? Because knowing the measured metrics of each member link lets operators enforce a performance-based traffic steering policy across those member links. main character energy for sure 👑

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9534.

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

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.

1. Introduction ✨

okay so a Link Aggregation Group (LAG), as defined in [IEEE802.1AX], lets you bundle multiple physical links into one single logical link 🧚 The bundle gets you higher bandwidth and better resiliency, because if one physical member link fails, the logical link can keep forwarding traffic over the rest of the operational physical member links. not me being impressed 😭

Usually, when traffic goes over a LAG, a hash-based mechanism is used to load balance it across the LAG member links. But the link delay can vary between member links because they can take different transport paths, especially when a LAG is used in a wide area network 🌍 So if you want low-latency service for time-sensitive traffic, you need to explicitly steer traffic across the member links based on link delay, loss, and so on. That needs a solution that measures the performance metrics of each member link of a LAG. Then the measured metrics can work together with Layer 2 bundle member link attributes advertisement [RFC8668] for traffic steering. it's giving teamwork 🫶

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 gives you 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 measure the performance of a member link using a specially constructed 5-tuple. The session can also measure an average of some or all member links of the LAG, by varying one or more elements of that 5-tuple. But without knowing about each member link, a STAMP test session can't measure the performance of every physical member link 🙈

This document extends STAMP so it can measure performance 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.

1.1. 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. Micro Sessions on a LAG 🍓

okay so this document is about the scenario where a LAG directly connects two nodes. Figure 1 shows an example, with a LAG made of four links connecting nodes A and B. The goal is to measure the performance of each link of the LAG 🌸

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

Figure 1: Performance Measurement on a LAG

To measure the performance metrics of every member link of a LAG, you need to set up multiple sessions, one session for each member link, between the two endpoints that the LAG connects 🧚 These sessions are called "micro sessions" for the rest of this document. Even though micro sessions are really STAMP sessions set up 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. 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 an 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 gives a detailed description of 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, because it improves the accuracy of network delay measurement by minimizing the impact of egress queuing delays on the measurement 🦋

okay this is the validation part, and it's a big deal 🔥 Test packets MUST carry member link information in the Micro-session ID TLV introduced in this section, for validation checks. The micro Session-Sender verifies whether the test packet is received from the expected member link. It also verifies whether the packet is sent from the expected member link at the Reflector side. The micro Session-Reflector verifies whether the test packet is received from the expected member link 👑

3.1. Micro-session ID TLV 💜

The STAMP TLV mechanism [RFC8972] extends STAMP test packets with one or more optional TLVs. This document defines the TLV Type (value 11) for the Micro-session ID TLV. It carries the micro STAMP Session-Sender member link identifier and the Session-Reflector member link identifier, in the Sender Micro-session ID field and the Reflector Micro-session ID field respectively. Here's the format, bestie 🌈

       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 = 11    |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Sender Micro-session ID   |   Reflector Micro-session ID  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Micro-session ID TLV

Here's what each field does 🍓

  • Type (1 octet in length): this field is defined to indicate that this TLV is a Micro-session ID TLV. Value 11 has been allocated by IANA (Section 5) 🎀
  • Length (2 octets in length): this field is defined to carry the length of the Value field in octets. The Length field value MUST be 4 ✨
  • Sender Micro-session ID (2 octets in length): this field is defined to carry the LAG member link identifier of the Sender side. In the future, it may be used generically to cover use cases beyond LAGs. The value of this field MUST be unique within a STAMP session at the Session-Sender 🦋
  • Reflector Micro-session ID (2 octets in length): this field is defined to carry the LAG member link identifier of the Reflector side. In the future, it may be used generically to cover use cases beyond LAGs. The value of this field MUST be unique within a STAMP session at the Session-Reflector 💅

3.2. Micro STAMP-Test Procedures 🧪

okay so the micro STAMP-Test is basically a copycat of the STAMP procedures from Section 4 of STAMP [RFC8762], just with a few extra rules on top. 💅

The micro STAMP Session-Sender MUST send the micro STAMP-Test packets over the member link that the session is tied to. ✨ You can set up which Sender and Reflector member links go with which micro STAMP session by augmenting the STAMP YANG [STAMP-YANG] data model. The detailed augmentation is out of scope for this doc, so that's a different story. 🎀

When the Session-Sender sends a test packet, it MUST fill the Sender Micro-session ID field with the member link identifier for that micro STAMP session. 🦋 If the Session-Sender knows the Reflector member link identifier, the Reflector Micro-session ID field MUST be set. If it doesn't know it, the Reflector Micro-session ID field MUST be zero. 🌸 The Reflector member link identifier can come from preconfiguration or be learned from the data plane (for example, from the reflected test packet). This document doesn't say how to get it, so that part's up to you, bestie. 🫶

When the micro STAMP Session-Reflector gets a test packet and the Reflector Micro-session ID is not zero, it MUST use the Reflector member link identifier to check whether that identifier is associated with the micro STAMP session. 🔥 If that validation fails, the test packet MUST be discarded, no exceptions 💀. If the Reflector Micro-session ID is zero, it will not be verified. If every validation passes, the Session-Reflector sends a reflected test packet back to the Session-Sender. 💖 The micro STAMP Session-Reflector MUST put the Sender and Reflector member link identifiers that are associated with the micro STAMP session into the Sender Micro-session ID and Reflector Micro-session ID fields, respectively. The Sender member link identifier gets copied over from the received test packet. 🧚

When a micro Session-Sender receives a reflected test packet, it MUST use the Sender Micro-session ID to check that the reflected test packet actually came in on the expected member link. 👑 If that validation fails, the test packet MUST be discarded. The micro Session-Sender MUST also use the Reflector Micro-session ID to validate the Reflector's behavior, and if that validation fails, the test packet MUST be discarded. Main character energy for the validation checks 😭✨

Two modes of the STAMP Session-Reflector, stateless and stateful, describe the expected behavior, as explained in Section 4 of STAMP [RFC8762]. The micro STAMP-Test supports both stateless and stateful modes too 🌈. The fun twist is that the micro STAMP-Test doesn't add any extra state on top of STAMP, so anything related to the Micro-session ID is stateless. Lowkey iconic 🙈

4. Applicability ✨

The micro STAMP Session-Sender sends micro Session-Sender packets that carry the Micro-session ID TLV. 🎀 The micro Session-Reflector checks whether a test packet came in from the member link tied to the correct micro STAMP session, but only 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 into the micro Session-Reflector packet. It then sets the Reflector Micro-session ID field to the member link identifier associated with the micro STAMP session. 🦋 When the micro Session-Reflector packet shows up, the micro Session-Sender uses the Sender Micro-session ID to confirm that it arrived from the member link tied to the right micro STAMP session. The micro Session-Sender also uses the Reflector Micro-session ID to validate the Reflector's behavior. It's giving double-checking, and I'm here for it 🫶

5. IANA Considerations 📋

IANA has allocated the following STAMP TLV Type for the Micro-session ID TLV in the "STAMP TLV Types" registry [RFC8972]: 🌸

           +=======+==================+===============+
           | Value | Description      | Reference     |
           +=======+==================+===============+
           | 11    | Micro-session ID | This Document |
           +-------+------------------+---------------+

                   Table 1: New STAMP TLV Type

6. Security Considerations 🔐

⚠️ Serious bestie moment: this part is important, so read it carefully.

The STAMP extension defined in this document is meant for deployment in the LAG scenario, where the Session-Sender and Session-Reflector are directly connected. 🔥 Because of that, it's assumed that any node taking part in a STAMP operation has already verified the integrity of the LAG connection and the identity of its one-hop-away peer node. No skipping that step, periodt 💀

This document doesn't introduce any additional security issues. The security mechanisms defined in [RFC8762] and [RFC8972] apply to this document too, so they're still very much in the picture 🛡️✨

7. References 📚

7.1. Normative References 💜

7.2. Informative References 🌷

Acknowledgements 🫶

The authors would like to thank Mach Chen, Min Xiao, Fang Xin, Marcus Ihlar, and Richard Foote for their valuable comments on this work. Thank you all, you're the real MVPs 🏆💖

Authors' Addresses 🌍

Zhenqiang Li
China Mobile
No. 29 Finance Avenue
Xicheng District
Beijing
China
Email: li_zhenqiang@hotmail.com


Tianran Zhou
Huawei
China
Email: zhoutianran@huawei.com


Jun Guo
ZTE Corp.
China
Email: guo.jun2@zte.com.cn


Greg Mirsky
Ericsson
United States of America
Email: gregimirsky@gmail.com


Rakesh Gandhi
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com
📦 where this page comes from