Simple Two-Way Active Measurement Protocol (STAMP) Extension for Co-routed Bidirectional 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 31 December 2024.¶

Copyright Notice

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.¶

Table of Contents

1. Introduction

Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] is an active performance measurement test protocol, which enables measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss.¶

Based on that, [RFC8972] specifies the use of optional extensions that use Type-Length-Value (TLV) encoding，these extensions enhance the STAMP base functions.¶

[RFC9503] specifies Simple Two-Way Active Measurement Protocol (STAMP) extensions for SR networks, which can transmit the reply test packet on a specific return path. This extension requires the Session-Sender to indicate the return path explicitly in the Return Path TLV.¶

However, in some scenarios, the Session-Sender can’t know the return path in advance, but it requires the return path to be the same as the forward path to do a round-trip performance measurement for a path.¶

This document extends STAM Return Path TLV with a Co-routed Bidirectional Path flag to implement the round-trip performance measurement for a specific path.¶

2. Motivation

When the STAMP is used to locate a network failure or measure network performance, it is usually required to ensure that the forward path is consistent with the return path, so as to obtain stable performance data or locate a fault quickly. However, the existing measurement manner cannot ensure that the forward path is consistent with a return path. Consider a scenario with LAG links, as shown in Figure 1:¶

+------+    +------+ 10% packet loss rate +------+     +------+
|  N1  |----|  N2  |======================|  N3  |-----|  N4  |
+------+    +------+ 0% packet loss rate  +------+     +------+
  SRC                                                    DST

There are four nodes in the topology, and N1 connect to N2 by one physical link, N2 connect to N3 by two physical links, N3 connect to N4 by one Link. The packet loss rate of the first link between N2 and N3 is 10%, and the second link is 0%.¶

Node N1 want to measure the packet loss between N1 and N4, and it does not know that there are two links between N2 and N3.¶

N1 send a set of test packets, when these packets arrive at N2, half of them will be forward by the first link and the others are forwarded by the second link. The reflected packets are forwarded with the same rule.¶

The result is that N1 find the packet loss rate of both forward path and backward path are 5%. However, there is one route path with 0 packet loss which can be used for forwarding.¶

3. Co-routed Bidirectional Path Flag

This document defines a new flag in the STAMP Return Path Control Code Sub-TLV in Return Path TLV:¶

Bit X: Co-routed Bidirectional Path flag.¶

When Co-routed Bidirectional Path flag in Control Code Sub-TLV is set to 1 in the Session-Sender test packet, the Session-Sender MUST insert the IOAM IPv6 option in the test packet.¶

When the transit node receives a test packet with Co-routed Bidirectional Path flag set and has an IOAM IPv6 option, it MUST insert its ingress interface id, node id and egress id to the IOAM IPv6 option in the test packet.¶

When the transit node receives a test packet with Co-routed Bidirectional Path flag set, but no IOAM IPv6 option in the test packet, it SHOULD drop this test packet.¶

When the Session-Reflector receives a test packet with Co-routed Bidirectional Path flag set and has IOAM IPv6 option, it SHOULD exact all the route path information from the IOAM IPv6 option and encapsulate it in the SRH of reflected test packet. Thereby, the reflected packet will be transit along the path same as the forward path.¶

When the Session-Reflector receives a test packet with Co-routed Bidirectional Path flag set, but no IOAM IPv6 option, it SHOULD drop this test packet.¶

4. IANA Considerations

This document defines a new bit in the registry "IOAM Trace-Flags" registry as follows:¶

5. Security Considerations

TBD¶

Acknowledgements

Authors' Addresses