Internet-Draft Simple Two-Way Active Measurement Protoc October 2024
Zhang, et al. Expires 24 April 2025 [Page]
Workgroup:
IPPM Working Group
Internet-Draft:
draft-zhang-ippm-stamp-mp-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
L. Zhang
Huawei
T. Zhou
Huawei
Gyan Mishra
Verizon Inc.

Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Multi-path

Abstract

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.

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

▲

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. [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  |/
                       +------+         +------+
Figure 1: A multi-path topology

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.

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.

1.2. Terminology

The abbreviations used in this document are:

ECMP: Equal-Cost Multiple Path

UCMP: Unequal-Cost Multiple Path

STAMP: Simple Two-Way Active Measurement Protocol

2. Multi-path TLV

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                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Multi-path TLV

The fields are defined as follows:

STAMP TLV Flags: An eight-bit field. Its format is specified in [RFC8972].

Type: TBA, 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.

3. Multi-path Measurement Procedures

This section describes the procedures of session sender, transit node, and reflector.

3.1. Session-Sender Procedures

The Session-Sender procedures includes two steps, one is the test packet generation and another is the test packet validation.

3.1.1. Test Packet Generation

The test packet generation procedures could be referred from section 4.2 of [RFC8762]. In addition to the packet generation, 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                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of a STAMP Session-Sender Test Packet with Multi-path TLV in Unauthenticated Mode

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.

3.1.2. Test Packet Analysis

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.

3.2. Transit Node Procedures

3.2.1. Packet Operation

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

3.2.2. Packet Forwarding

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.

3.3. Session-Reflector Procedures

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.

In order to measure the round-trip performance of each path, the Session-Reflector MUST add Return Path TLV[RFC9503] to the Reflected packet to make sure that the reflected test packet is forwarded in the same path with test packet. This means the Session-Reflector need to encapsulate the transit node SID list in the Return Path TLV of Reflected test packet according to the IOAM Trace Option in the test packet.

3.4. Example of Multi-path Measurement

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
                            +--------+
Figure 4: Multi-path measurement topology

In Figure 4, the Session-Sender generate a set of test packet with the IOAM Trace Option and Multi-path TLV (M bit = 1), 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 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 will add a Return Path TLV containing the SID list of backward paths based on the IOAM trace option recorded in the test packet.

The transit node will forward the reflected test packets along the path indicated in the Return Path TLV

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.

4. IANA Considerations

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

Table 1
Value Description Reference
TBA Multi-path TLV This document

5. Security Considerations

TBD

6. References

6.1. Normative References

[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/rfc/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/rfc/rfc8972>.
[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/rfc/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/rfc/rfc8174>.
[RFC9197]
Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, , <https://www.rfc-editor.org/rfc/rfc9197>.

6.2. Informative References

[I-D.gandhi-ippm-stamp-ext-hdr]
Gandhi, R. and T. Zhou, "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet Headers", Work in Progress, Internet-Draft, draft-gandhi-ippm-stamp-ext-hdr-00, , <https://datatracker.ietf.org/doc/html/draft-gandhi-ippm-stamp-ext-hdr-00>.
[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/rfc/rfc9503>.

Acknowledgements

The authors would like to thank Ernesto Ruffini, Thomas Graf, Greg Mirsky for the valuable comments to this work.

Authors' Addresses

Li Zhang
Huawei
China
Tianran Zhou
Huawei
China
Gyan Mishra
Verizon Inc.
United States of America