IPPM Working Group                                              L. Zhang
Internet-Draft                                                   T. Zhou
Intended status: Standards Track                                  Huawei
Expires: 7 May 2025                                          Gyan Mishra
                                                            Verizon Inc.
                                                         3 November 2024


Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Multi-
                                  path
                      draft-zhang-ippm-stamp-mp-02

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 7 May 2025.

Copyright Notice

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






Zhang, et al.              Expires 7 May 2025                   [Page 1]

Internet-Draft  Simple Two-Way Active Measurement Protoc   November 2024


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Multi-path TLV  . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Multi-path Measurement Procedures . . . . . . . . . . . . . .   4
     3.1.  Session-Sender Procedures . . . . . . . . . . . . . . . .   4
       3.1.1.  Test Packet Generation  . . . . . . . . . . . . . . .   5
     3.2.  Transit node procedures . . . . . . . . . . . . . . . . .   6
       3.2.1.  Packet Operation  . . . . . . . . . . . . . . . . . .   6
       3.2.2.  Packet Forwarding . . . . . . . . . . . . . . . . . .   6
     3.3.  Session-Reflector procedures  . . . . . . . . . . . . . .   6
     3.4.  Test Packet Analysis  . . . . . . . . . . . . . . . . . .   7
   4.  Example of Multi-path Measurement . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

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.




Zhang, et al.              Expires 7 May 2025                   [Page 2]

Internet-Draft  Simple Two-Way Active Measurement Protoc   November 2024


   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.





Zhang, et al.              Expires 7 May 2025                   [Page 3]

Internet-Draft  Simple Two-Way Active Measurement Protoc   November 2024


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

   IOAM: In-band Operation, Administration, and Maintenance

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




Zhang, et al.              Expires 7 May 2025                   [Page 4]

Internet-Draft  Simple Two-Way Active Measurement Protoc   November 2024


3.1.1.  Test Packet Generation

   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                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        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.

   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.




Zhang, et al.              Expires 7 May 2025                   [Page 5]

Internet-Draft  Simple Two-Way Active Measurement Protoc   November 2024


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.

   [RFC8762] defines two kind of Session-Reflector behavior, one is
   stateless and another is stateful.

   When using in stateless mode, the Session Reflector just copy the
   sequence number from the test packet to the reflected test pacekt.

   When using in statefull mode, the Session Reflector need to maintain
   a counter for each available path recored in the IOAM trace option of
   test packet.

   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.




Zhang, et al.              Expires 7 May 2025                   [Page 6]

Internet-Draft  Simple Two-Way Active Measurement Protoc   November 2024


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

   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 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 Session-Sender sequence number for each path.

   *  The analysis node gets all the available paths and their round-
      trip packet loss rate by comparing the Session-Sender 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.






Zhang, et al.              Expires 7 May 2025                   [Page 7]

Internet-Draft  Simple Two-Way Active Measurement Protoc   November 2024


   *  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 the forward and backward packet loss rate
      for each path by comparing the reflected test packets number and
      Reflected sequence number and Session-Sender sequence number.

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

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, 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



Zhang, et al.              Expires 7 May 2025                   [Page 8]

Internet-Draft  Simple Two-Way Active Measurement Protoc   November 2024


   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.

5.  IANA Considerations

   This document defines a new TLV in the registry "STAMP TLV Types"
   registry as follows:

                +=======+================+===============+
                | Value | Description    | Reference     |
                +=======+================+===============+
                | TBA   | Multi-path TLV | This document |
                +-------+----------------+---------------+

                                 Table 1

6.  Security Considerations

   TBD

7.  References

7.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, March 2020,
              <https://www.rfc-editor.org/rfc/rfc8762>.



Zhang, et al.              Expires 7 May 2025                   [Page 9]

Internet-Draft  Simple Two-Way Active Measurement Protoc   November 2024


   [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, January 2021,
              <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, March 1997,
              <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,
              May 2017, <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,
              May 2022, <https://www.rfc-editor.org/rfc/rfc9197>.

7.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, 6 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-gandhi-ippm-
              stamp-ext-hdr-00>.

   [I-D.zhang-ippm-stamp-co-routed-path]
              Zhang, L. and T. Zhou, "Simple Two-Way Active Measurement
              Protocol (STAMP) Extension for Co-routed Bidirectional
              Path", Work in Progress, Internet-Draft, draft-zhang-ippm-
              stamp-co-routed-path-00, 29 June 2024,
              <https://datatracker.ietf.org/doc/html/draft-zhang-ippm-
              stamp-co-routed-path-00>.

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



Zhang, et al.              Expires 7 May 2025                  [Page 10]

Internet-Draft  Simple Two-Way Active Measurement Protoc   November 2024


   Email: zhangli344@huawei.com


   Tianran Zhou
   Huawei
   China
   Email: zhoutianran@huawei.com


   Gyan Mishra
   Verizon Inc.
   United States of America
   Email: gyan.s.mishra@verizon.com






































Zhang, et al.              Expires 7 May 2025                  [Page 11]