| Internet-Draft | Simple Two-Way Active Measurement Protoc | July 2024 |
| Zhang, et al. | Expires 8 January 2025 | [Page] |
STAMP is typically used to perform the measurement of one-way and round-trip performance metrics. However, when using active measurement mechanisms in a multi-path topology, the default forwarding behavior is to go through one path. So, it cannot collect the information of all the paths at one time.¶
This document extends STAM with a Multi-path TLV to implement the multi-path performance measurement, which can help the operators to know the performance of network comprehensively and efficiently.¶
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 8 January 2025.¶
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.¶
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. [I-D.gandhi-ippm-stamp-ext-hdr] extends STAMP[RFC8762] to reflect any IPv6 options and MPLS Network Action Sub-Stacks for hop-by-hop and edge-to-edge active measurements. In section 4 of [I-D.gandhi-ippm-stamp-ext-hdr], it provides an example of reflecting IOAM data fields, in which the IPv6 options with IOAM option-types is carried in the STAMP Session-Sender and Session-Reflector test packets.¶
However, currently the STAMP is typically used to collect the information of a specific path, when using it in a multi-path topology (there are multiple paths form the source node to the destination node and ECMP, UCMP or other multi-path routing strategy is used.), the default forwarding behavior is to go through one path. So, it can’t collect all the path’s information form source node to destination node. An example of active measurement in a multi-path topology is shown as follow:¶
+------+ +------+
/| N3 |---------| N5 |\
/ +------+ +------+ \
+------+ +------+/ \+------+ +------+
| N1 |--->| N2 | | N7 |---->| N8 |
+------+ +------+\ /+------+ +------+
SRC \ +------+ +------+ / DST
\| N4 |-------> | N6 |/
+------+ +------+
In Figure 1, node N1 is the source node, node N8 is the destination node, N2-7 are transit node. Equal-Cost Multiple Path (ECMP) is applied in this topology. So, there are two paths form N1 to N8, one is N1-N2-N3-N5-N7-N8, and the other is N1-N2-N4-N6-N7-N8. When N1 use STAMP to measure the path performance, the test packet is forwarded along one of the paths (for example N1-N2-N4-N6-N7-N8), then the source node just can get one path’s information, however the traffic packets are forwarded in all paths.¶
Although the IPv6 flow label and MPLS entropy label can be constructed variously to try to make packets go through all paths, but the hash algorithm cannot ensure that packets can go through all available paths.¶
This document extends STAM with a Multi-path TLV to implement the multi-path performance measurement, which can help the operators to know the performance of network comprehensively and efficiently.¶
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.¶
This document defines a new TLV in the STAMP test packets:¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are defined as follows:¶
STAMP TLV Flags: An eight-bit field. Its format is specified in [RFC8972].¶
Type: A one-octet field. Need to be allocated by IANA.¶
Length: A two-octet field, set equal to the value 4.¶
M: A one-bit field, A Session-Sender MUST set the value of M filed to 1 When need to perform measurement on all paths.¶
This section describes the procedures of session sender, transit node, and reflector.¶
The Session-Sender procedures includes two steps, one is the test packet generation and another is the test packet validation.¶
The test packet generation procedures could be referred from section 4.2 of [RFC8762]. The session-sender should generate a Multi-path TLV with the M bit set and encapsulate it into the test packet. An example of the format of STAMP Session-Sender test packet with Multi-path TLV in unauthenticated mode is shown 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | SSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| MBZ (28 octets) |
| |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=TBD | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In order to identify different paths, the Test packet is required to collect the paths’ information. Therefore, the IOAM should be used in combination with STAMP. The Session-sender should insert a an IOAM IPv6 HBH option to the test packet to collect the HBH node information. According to [I-D.gandhi-ippm-stamp-ext-hdr], the Session-sender also need to add “Reflected IPv6 Option Data” TLV in the test packet with the size of the IOAM data field’s length and the value field in the TLV initialized to zeros.¶
In order to perform a round trip for a specific path, the Co-routed Bidirectional Path flag [I-D.zhang-ippm-stamp-co-routed-path] in the Return Path Control Code Sub-TLV of Return Path TLV should be set to 1.¶
The test packet analysis node could be a Session-Sender or a Controller.¶
According to [I-D.gandhi-ippm-stamp-ext-hdr], the Session-Sender will receive a Session-Reflector test packet with an Reflected IPv6 Option Data TLV. The content of this TLV is copied from the IPv6 option of Session-Sender test packet.¶
[RFC8762] defines two kind of Session-Reflector behavior, one is stateless and another is stateful.¶
When using stateless mode, the Session-Sender will receive a test packet and the values in the Sequence Number and Session-Sender Sequence Number fields are the same. The test packet analysis node will analysis the test packet in the following procedures:¶
The analysis node determines which test packet the reflected packet belongs to base on the sequence number. The analysis node will receive many reflected test packets with the same Sequence Number.¶
For the reflected test packets with same Sequence Number, the analysis node needs to distinguish the different paths by the node information recorded in the IOAM trace Option in Reflected IPv6 Option Data TLV.¶
The analysis node needs to generate a table for all the paths and record the sequence number for each path.¶
The analysis node gets all the available paths and their packet loss rate by comparing the sequence number and reflected test packets number for each path.¶
The analysis node gets the forward and backward transit delay of each path by comparing the Session-Sender Timestamp and Receive Timestamp or Timestamp of each Session-Reflect test packet.¶
When using stateful mode, the Session-Sender will receive a test packet and the values of the Sequence Number and Session-Sender Sequence Number fields are independent. The test packet analysis node will analysis the test packet in the following procedures:¶
The analysis node determines which test packet the reflected packet belongs to base on the Session-Sender sequence number. The analysis node will receive many reflected test packets with the same Session-Sender sequence number.¶
For the reflected test packets with same Session-Sender sequence number, the analysis node needs to distinguish the different paths by the node information recorded in the IOAM trace Option in Reflected IPv6 Option Data TLV.¶
The analysis node needs to generate a table for all the paths and record the sequence number and Session-Sender sequence number for each path.¶
The analysis node gets all the available paths and their round-trip packet loss rate by counting the sequence number for each path.¶
The analysis node gets the round-trip packet loss rate by comparing the reflected test packets number and Session-Sender sequence number for each path (the forward and backward packet loss can’t be measured because it requires the Session-Reflector maintains different counter for each path).¶
The analysis node gets the forward and backward transit delay of each path by comparing the Session-Sender Timestamp and Receive Timestamp and Timestamp of each Session-Reflect test packet.¶
When the transit node receives a test packet with the IOAM trace option, it needs to add its node ID, ingress interface ID, and egress interface ID to the IOAM trace option of the test packet. For details about the content format, see section 4.4.2 of [RFC9197].¶
When a transit node with multiple paths to the destination node receives a packet with Multi-path bit = 1, it must copy the packet to each egress interface that can reach the destination node.¶
When the transit node has only one path to the destination node, it just needs to forward the packet it received to the egress interface.¶
When a Session-Reflector receives a test packet with Multi-path TLV, it MUST copy the entire IPv6 option including the header into the STAMP "Reflected IPv6 Option Data" TLV in Session-Reflector payload, and reset the M bit of Multi-path TLV to prevent the replication in the backward path.¶
The Session-Reflector also need to check whether there is a Return Path Control Code Sub-TLV with Co-routed Bidirectional Path flag set.¶
If the Co-routed Bidirectional Path flag is set, the Session-Reflector Must send the reflect test packet along the path indicated in the IOAM IPv6 HBH option as described in [I-D.zhang-ippm-stamp-co-routed-path].¶
If the there is no Return Path Control Code Sub-TLV or the Co-routed Bidirectional Path flag is not set, it MUST drop this Multi-path test packet.¶
An example of a Multi-path measurement scenario is illustrated in Figure 4. The figure depicts two endpoints: A STAMP Session-Sender and A Session-Reflector. The “STAMP session” is the bidirectional packet flow between the Session-Sender and Session-Reflector. There are four transit nodes and two routing paths between the Session-Sender and Session-Reflector.¶
+--------+
/| N3 |\
/ +--------+ \
+--------+ +--------+/ Transit \+--------+ +--------+
| N1 |-----| N2 | Node | N5 |-----| N6 |
+--------+ +--------+\ /+--------+ +--------+
STAMP Transit \ +--------+ / Transit STAMP
Session-Sender Node \| N4 |/ Node Session-Reflector
+--------+
In Figure 4, the Session-Sender generate a set of test packet with the IOAM Trace Option, Multi-path TLV (M bit = 1) and Co-routed Bidirectional Path flag set, indicating that these packets are used for multi-path measurement.¶
When the packets arrive at N2, N2 find that there are two paths to the destination node, then it will copy the packet to each outgoing interface of the two paths and add its information (including the node id, ingress interface id and egress interface id) to the IOAM Trace Option. It should be noted that Node Identification, ingoing and outgoing interface Identification of N2 are mandatory for path recovering, other node data defined in section 4.1.1 of [RFC9197] are optional.¶
The following transit nodes just add its node data to the IOAM Trace Option as described in section 4 of [RFC9197].¶
When the test packets arrive at Session-Reflector, it will copy the entire IPv6 option including the header into the STAMP "Reflected IPv6 Option Data" TLV in Session-Reflector payload. The Session-Reflector will also reset the Multi-path flag of Multi-path TLV. In addition, the Session-Reflector SHOULD exact all the route path information from the IOAM IPv6 option and encapsulate it in the SRH of reflected test packet, to perform a strict path forwarding.¶
The transit node will forward the reflected test packets along the path indicated in SRH.¶
When the reflected test packets arrive at the Session-Sender, it will analysis these reflected test packets as the procedures illustrated in section 3.1.2. Therefore, it can get the topology with all paths, the round-trip packet loss and the unidirectional path delay.¶
This document defines a new bit in the registry "IOAM Trace-Flags" registry as follows:¶
| Value | Description | Reference |
|---|---|---|
| Bit X | Multipath Flag | This |
The authors would like to thank Ernesto Ruffini, Thomas Graf, Greg Mirsky for the valuable comments to this work.¶