Skip to main content

Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing Networks
draft-ietf-spring-stamp-srpm-11

Document Type Active Internet-Draft (spring WG)
Authors Rakesh Gandhi , Clarence Filsfils , Daniel Voyer , Mach Chen , Richard "Footer" Foote
Last updated 2024-02-02
Replaces draft-gandhi-spring-stamp-srpm, draft-gandhi-spring-enhanced-srpm
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-spring-stamp-srpm-11
SPRING Working Group                                      R. Gandhi, Ed.
Internet-Draft                                               C. Filsfils
Intended status: Informational                       Cisco Systems, Inc.
Expires: 5 August 2024                                          D. Voyer
                                                             Bell Canada
                                                                 M. Chen
                                                                  Huawei
                                                                R. Foote
                                                                   Nokia
                                                         2 February 2024

Performance Measurement Using Simple Two-Way Active Measurement Protocol
                  (STAMP) for Segment Routing Networks
                    draft-ietf-spring-stamp-srpm-11

Abstract

   Segment Routing (SR) leverages the source routing paradigm.  SR is
   applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6
   (SRv6) data planes.  This document describes procedures for
   Performance Measurement in SR networks using Simple Two-Way Active
   Measurement Protocol (STAMP) defined in RFC 8762 and its optional
   extensions defined in RFC 8972 and further augmented in RFC 9503.
   The procedure described is used for links, end-to-end SR paths
   (including SR Policies and SR Flexible Algorithm IGP paths) as well
   as Layer-3 and Layer-2 services in SR networks, and is applicable to
   both SR-MPLS and SRv6 data planes.

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 5 August 2024.

Gandhi, et al.            Expires 5 August 2024                 [Page 1]
Internet-Draft       Using STAMP for Segment Routing       February 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  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Reference Topology  . . . . . . . . . . . . . . . . . . .   6
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Example STAMP Reference Model . . . . . . . . . . . . . .   8
   4.  Delay Measurement in SR Networks  . . . . . . . . . . . . . .   9
     4.1.  Session-Sender Test Packet  . . . . . . . . . . . . . . .   9
       4.1.1.  Session-Sender Test Packet for Links  . . . . . . . .  10
       4.1.2.  Session-Sender Test Packet for SR-MPLS Policies . . .  10
       4.1.3.  Session-Sender Test Packet for SRv6 Policies  . . . .  12
       4.1.4.  Session-Sender Test Packet for SR Flexible Algorithm
               IGP Path  . . . . . . . . . . . . . . . . . . . . . .  13
       4.1.5.  Session-Sender Test Packet for P2MP SR Policies . . .  14
       4.1.6.  Session-Sender Test Packet for Layer-3 Service over SR
               Path  . . . . . . . . . . . . . . . . . . . . . . . .  14
       4.1.7.  Session-Sender Test Packet for Layer-2 Service over SR
               Path  . . . . . . . . . . . . . . . . . . . . . . . .  15
     4.2.  Session-Reflector Test Packet . . . . . . . . . . . . . .  16
       4.2.1.  One-Way Measurement Mode  . . . . . . . . . . . . . .  17
       4.2.2.  Two-Way Measurement Mode  . . . . . . . . . . . . . .  18
   5.  Loopback Measurement Mode in SR Networks  . . . . . . . . . .  20
     5.1.  Loopback Measurement Mode STAMP Packet Processing . . . .  21
     5.2.  Loopback Measurement Mode for Links . . . . . . . . . . .  22
     5.3.  Loopback Measurement Mode for SR-MPLS Paths . . . . . . .  23
       5.3.1.  Reverse SR-MPLS Path  . . . . . . . . . . . . . . . .  23
       5.3.2.  Reverse IP/UDP Path . . . . . . . . . . . . . . . . .  24
     5.4.  Loopback Measurement Mode for SRv6 Paths  . . . . . . . .  24
       5.4.1.  Reverse SRv6 Path . . . . . . . . . . . . . . . . . .  25
       5.4.2.  Reverse IP/UDP Path . . . . . . . . . . . . . . . . .  25

Gandhi, et al.            Expires 5 August 2024                 [Page 2]
Internet-Draft       Using STAMP for Segment Routing       February 2024

     5.5.  Loopback Measurement Mode for Layer-3 Service over SR
           Path  . . . . . . . . . . . . . . . . . . . . . . . . . .  25
       5.5.1.  Loopback Measurement Mode for Layer-3 Service over
               SR-MPLS Path  . . . . . . . . . . . . . . . . . . . .  25
       5.5.2.  Loopback Measurement Mode for Layer-3 Service over SRv6
               Path  . . . . . . . . . . . . . . . . . . . . . . . .  26
     5.6.  Loopback Measurement Mode for Layer-2 Service over SR
           Path  . . . . . . . . . . . . . . . . . . . . . . . . . .  26
       5.6.1.  Loopback Measurement Mode for Layer-2 Service over
               SR-MPLS Path  . . . . . . . . . . . . . . . . . . . .  26
       5.6.2.  Loopback Measurement Mode for Layer-2 Service over SRv6
               Path  . . . . . . . . . . . . . . . . . . . . . . . .  26
   6.  Loopback Measurement Mode with Timestamp and Forward Function
           in SR Networks  . . . . . . . . . . . . . . . . . . . . .  27
     6.1.  Loopback Measurement Mode with Timestamp and Forward
           Function for SR-MPLS Paths  . . . . . . . . . . . . . . .  28
       6.1.1.  Timestamp and Forward Network Action Assignment . . .  29
       6.1.2.  Node Capability for MNA Sub-Stack with Opcode
               MNA.TSF . . . . . . . . . . . . . . . . . . . . . . .  29
     6.2.  Loopback Measurement Mode with Timestamp and Forward
           Function for SRv6 Paths . . . . . . . . . . . . . . . . .  30
       6.2.1.  Timestamp and Forward Endpoint Function Assignment  .  31
       6.2.2.  Node Capability for Timestamp and Forward Endpoint
               Function  . . . . . . . . . . . . . . . . . . . . . .  31
   7.  Packet Loss Measurement in SR Networks  . . . . . . . . . . .  31
   8.  Direct Measurement in SR Networks . . . . . . . . . . . . . .  31
   9.  ECMP Measurement in SR Networks . . . . . . . . . . . . . . .  32
   10. STAMP Session State . . . . . . . . . . . . . . . . . . . . .  32
   11. Additional STAMP Test Packet Processing Rules . . . . . . . .  33
     11.1.  TTL  . . . . . . . . . . . . . . . . . . . . . . . . . .  33
     11.2.  IPv6 Hop Limit . . . . . . . . . . . . . . . . . . . . .  33
     11.3.  Router Alert Option  . . . . . . . . . . . . . . . . . .  33
     11.4.  IPv6 Flow Label  . . . . . . . . . . . . . . . . . . . .  33
     11.5.  UDP Checksum . . . . . . . . . . . . . . . . . . . . . .  34
   12. Implementation Status . . . . . . . . . . . . . . . . . . . .  34
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  34
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  35
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  35
     15.2.  Informative References . . . . . . . . . . . . . . . . .  36
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  39
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  40
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  40

Gandhi, et al.            Expires 5 August 2024                 [Page 3]
Internet-Draft       Using STAMP for Segment Routing       February 2024

1.  Introduction

   Segment Routing (SR) leverages the source routing paradigm and
   greatly simplifies network operations for Software Defined Networks
   (SDNs).  SR is applicable to both Multiprotocol Label Switching (SR-
   MPLS) and IPv6 (SRv6) data planes [RFC8402].  SR takes advantage of
   the Equal-Cost Multipaths (ECMPs) between source and transit nodes,
   between transit nodes and between transit and destination nodes.  SR
   Policies as defined in [RFC9256] are used to steer traffic through a
   specific, user-defined paths using a stack of Segments.  A
   comprehensive SR Performance Measurement (PM) toolset is one of the
   essential requirements to measure network performance to provide
   Service Level Agreements (SLAs).

   The Simple Two-Way Active Measurement Protocol (STAMP) provides
   capabilities for the measurement of various performance metrics in IP
   networks [RFC8762] without the use of a control channel to pre-signal
   session parameters.  [RFC8972] defines optional extensions, in the
   form of TLVs, for STAMP.  [RFC9503] augments that framework to define
   STAMP extensions for SR networks.

   This document describes procedures for Performance Measurement in SR
   networks using STAMP defined in [RFC8762] and its optional extensions
   defined in [RFC8972] and further augmented in [RFC9503].  The
   procedure described is used for links, end-to-end SR paths [RFC8402]
   (including SR Policies [RFC9256] and SR Flexible Algorithm (Flex-
   Algo) IGP paths [RFC9350]) as well as Layer-3 (L3) and Layer-2 (L2)
   services in SR networks, and is applicable to both SR-MPLS and SRv6
   data planes.

   STAMP requires protocol support on the Session-Reflector to process
   the received test packets, and hence the received test packets need
   to be punted from the fast path in data plane and return test packets
   need to be generated.  This limits the scale for number test sessions
   and the ability to provide faster measurement interval.  This
   document enhances the procedure for Performance Measurement using
   STAMP to improve the scale for number of sessions and the interval
   for measurement of SR paths, for both SR-MPLS and SRv6 data planes by
   using timestamp and forward network programming function.

2.  Conventions Used in This Document

Gandhi, et al.            Expires 5 August 2024                 [Page 4]
Internet-Draft       Using STAMP for Segment Routing       February 2024

2.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.2.  Abbreviations

   ECMP: Equal Cost Multi-Path.

   HMAC: Hashed Message Authentication Code.

   I2E: Ingress-To-Egress.

   IHS: Ingress-To-Egress, Hop-By-Hop or Select Scope.

   L2: Layer-2.

   L3: Layer-3.

   MBZ: Must be Zero.

   MNA: MPLS Network Action.

   MPLS: Multiprotocol Label Switching.

   PSID: Path Segment Identifier.

   SHA: Secure Hash Algorithm.

   SID: Segment ID.

   SR: Segment Routing.

   SRH: Segment Routing Header.

   SR-MPLS: Segment Routing with MPLS data plane.

   SRv6: Segment Routing with IPv6 data plane.

   SSID: STAMP Session Identifier.

   STAMP: Simple Two-Way Active Measurement Protocol.

   TC: Traffic Class.

Gandhi, et al.            Expires 5 August 2024                 [Page 5]
Internet-Draft       Using STAMP for Segment Routing       February 2024

   TSF: Timestamp and Forward.

   TTL: Time To Live.

   VPN: Virtual Private Network.

2.3.  Reference Topology

   As shown in Figure 1, Reference Topology, the STAMP Session-Sender S1
   initiates a STAMP Session-Sender test packet and the STAMP Session-
   Reflector R1 transmits a reply STAMP test packet.  The reply STAMP
   test packet may be transmitted to the STAMP Session-Sender S1 on the
   same path (same set of links and nodes) or a different path in the
   reverse direction from the path taken towards the Session-Reflector
   R1.

   The T1 is a transmit timestamp, and T4 is a receive timestamp added
   by node S1.  The T2 is a receive timestamp, and T3 is a transmit
   timestamp added by node R1.

   The nodes S1 and R1 may be connected via a link or an SR path
   [RFC8402].  The link may be a physical interface, virtual link, or
   Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member.  The SR
   path may be an SR Policy [RFC9256] on node S1 (called "head-end")
   with destination to node R1 (called "tail-end") or SR Flex-Algo IGP
   path [RFC9350].

                          T1                T2
                         /                   \
                +-------+     Test Packet     +-------+
                |       | - - - - - - - - - ->|       |
                |   S1  |=====================|   R1  |
                |       |<- - - - - - - - - - |       |
                +-------+  Reply Test Packet  +-------+
                         \                   /
                          T4                T3

            STAMP Session-Sender        STAMP Session-Reflector

                        Figure 1: Reference Topology

Gandhi, et al.            Expires 5 August 2024                 [Page 6]
Internet-Draft       Using STAMP for Segment Routing       February 2024

3.  Overview

   For performance measurement in SR networks, the STAMP Session-Sender
   and Session-Reflector can use the base test packets defined
   [RFC8762].  However, the STAMP test packets defined in [RFC8972] are
   preferred in SR environment because of the optional extensions.  The
   STAMP test packets are encapsulated using IP/UDP header and use the
   Destination UDP port 862 [RFC8762], by default.  In this document,
   the STAMP test packets using IP/UDP header are considered for SR
   networks, where the STAMP test packets are further encapsulated with
   an SR-MPLS or SRv6 header.  The STAMP test packets MUST carry the
   same IP/SR encapsulation as used by the data packets on the SR path
   under measurement.

   The STAMP test packets are used in one-way, round-trip (also referred
   to as two-way in this document), loopback, and loopback with
   timestamp and forward function, measurement modes in SR networks.
   Note that one-way and round-trip measurement modes are referred to in
   [RFC8762] and are further described in this document for SR networks.

   The procedure defined in [RFC8762] is used to measure packet loss
   based on the transmission and reception of the STAMP test packets.
   The optional STAMP extensions defined in [RFC8972] are used for
   direct measurement of packet loss in SR networks.  The measurement
   modes defined in this document are also applicable to measure packet
   loss in SR networks.

   The STAMP test packets are transmitted on the same path as the data
   traffic flow under measurement to measure the delay and packet loss
   experienced by the data traffic flow.

   Typically, the STAMP test packets are transmitted along an IP path
   between a Session-Sender and a Session-Reflector to measure delay and
   packet loss along that IP path.  Matching forward and reverse
   direction paths for STAMP test packets, even for directly connected
   nodes are not guaranteed.

   It may be desired in SR networks that the same path (same set of
   links and nodes) between the Session-Sender and Session-Reflector be
   used for the STAMP test packets in both directions.  This is achieved
   by using the optional STAMP extensions for SR-MPLS and SRv6 networks
   specified in [RFC9503].  The STAMP Session-Reflector uses the return
   path parameters for the reply test packet from the received Session-
   Sender test packet, as described in [RFC9503].

Gandhi, et al.            Expires 5 August 2024                 [Page 7]
Internet-Draft       Using STAMP for Segment Routing       February 2024

3.1.  Example STAMP Reference Model

   An example of a STAMP Reference Model with some of the typical
   measurement parameters for STAMP test sessions is shown in Figure 2.

                               +------------+
                               | Controller |
                               +------------+
                                   /    \
     Destination UDP Port         /      \      Destination UDP Port
     Authentication Mode         /        \     Authentication Mode
         Keychain               /          \        Keychain
     Timestamp Format          /            \
     Delay Measurement Mode   /              \
     Packet Loss Type        /                \
                            v                  v
                        +-------+          +-------+
                        |       |          |       |
                        |   S1  |==========|   R1  |
                        |       |          |       |
                        +-------+          +-------+

                 STAMP Session-Sender  STAMP Session-Reflector

                  Figure 2: Example STAMP Reference Model

   A Destination UDP port number MUST be selected for STAMP function as
   described in [RFC8762].  The same Destination UDP port can be used
   for STAMP test sessions for links, end-to-end SR paths, and L3 and L2
   services in SR networks.  In this case, the Destination UDP port does
   not distinguish between the link, end-to-end SR path, or L3 and L2
   service STAMP test sessions.  The Source UDP port is dynamically
   chosen by the Session-Sender.  The same or different UDP Source port
   can be used for STAMP test sessions for links, end-to-end SR paths,
   and L3 and L2 services in SR networks.

   Examples of the Timestamp Format is Precision Time Protocol 64-bit
   truncated (PTPv2) [IEEE1588] and Network Time Protocol (NTP).  By
   default, the Session-Reflector replies in kind to the timestamp
   format received in the received Session-Sender test packet, as
   indicated by the "Z" flag in the Error Estimate field as described in
   [RFC8762].

   Examples of Delay Measurement Mode are one-way, two-way (i.e., round-
   trip), loopback, and loopback with timestamp and forward function as
   described in this document.

Gandhi, et al.            Expires 5 August 2024                 [Page 8]
Internet-Draft       Using STAMP for Segment Routing       February 2024

   Examples of Packet Loss Type can be round-trip, near-end (forward
   direction) and far-end (backward direction) packet loss as defined in
   [RFC8762].

   When using the authentication mode for the STAMP test sessions, the
   matching Authentication Type (e.g., HMAC-SHA-256) and Keychain MUST
   be configured on STAMP Session-Sender and STAMP Session-Reflector
   [RFC8762].

   The controller shown in the "Example STAMP Reference Model" is used
   for provisioning the STAMP test sessions and is not intended for the
   dynamic signaling of the SR parameters for the STAMP test sessions
   between the Session-Sender and Session-Reflector.

   Note that the YANG data model defined for STAMP in
   [I-D.ietf-ippm-stamp-yang] can be used to provision the Session-
   Sender and Session-Reflector and also for streaming telemetry of the
   operational data.

4.  Delay Measurement in SR Networks

4.1.  Session-Sender Test Packet

   The content of an example Session-Sender test packet using an IP and
   UDP header [RFC0768] is shown in Figure 3.  The payload contains the
   Session-Sender test packet defined in Section 3 of [RFC8972] as
   transmitted in an IP network.  Note that [RFC8972] updates the
   Session-Sender test packet defined in [RFC8762] with optional STAMP
   Session Identifier (SSID).  The SR encapsulation of the STAMP test
   packet is further described later in this document.

    +---------------------------------------------------------------+
    | IP Header                                                     |
    .  Source IP Address = Session-Sender IPv4 or IPv6 Address      .
    .  Destination IP Address=Session-Reflector IPv4 or IPv6 Address.
    .  IPv4 Protocol or IPv6 Next header = UDP (17)                 .
    .                                                               .
    +---------------------------------------------------------------+
    | UDP Header                                                    |
    .  Source Port = Dynamically chosen by Session-Sender           .
    .  Destination Port = User-configured Destination Port | 862    .
    .                                                               .
    +---------------------------------------------------------------+
    | Payload = Test Packet as specified in Section 3 of RFC 8972   |
    .           in Figure 1 and Figure 3                            .
    .                                                               .
    +---------------------------------------------------------------+

Gandhi, et al.            Expires 5 August 2024                 [Page 9]
Internet-Draft       Using STAMP for Segment Routing       February 2024

                Figure 3: Example Session-Sender Test Packet

4.1.1.  Session-Sender Test Packet for Links

   The Session-Sender test packet as shown in Figure 3 is transmitted
   over the link for delay measurement.  The local and remote IP
   addresses of the link MUST be used as Source and Destination
   Addresses in the IP header of the Session-Sender test packets,
   respectively.  For IPv6 links, the link local addresses [RFC7404] can
   be used in the IPv6 header.  An SR encapsulation (e.g., containing
   adjacency SID of the link) can also be added for transmitting the
   Session-Sender test packets for links.

   The Session-Sender can use the local Address Resolution Protocol
   (ARP) table or any other similar method to obtain the IP and MAC
   addresses for the links for transmitting STAMP packets.

   Note that the Session-Sender test packet is further encapsulated with
   a Layer-2 header containing Session-Reflector MAC address as the
   Destination MAC address and Session-Sender MAC address as the Source
   MAC address for Ethernet links.

   For LAG member links, the STAMP extension for the Micro-Session ID
   TLV defined in [RFC9534] is used to identify the member link.

4.1.2.  Session-Sender Test Packet for SR-MPLS Policies

   An SR-MPLS Policy Candidate-Path can contain one or more Segment
   Lists.  Each SR-MPLS Segment List contains a list of 32-bit Label
   Stack Entry (LSE) that includes a 20-bit label value, 8-bit Time-To-
   Live (TTL) value, 3-bit Traffic-Class (TC) value and 1-bit End-Of-
   Stack (S) field.  A Session-Sender test packet MUST be transmitted
   using each Segment List of the SR-MPLS Policy Candidate-Path for
   delay measurement.

   The content of an example Session-Sender test packet for an SR-MPLS
   Policy using the same SR-MPLS encapsulation as the data traffic is
   shown in Figure 4.

Gandhi, et al.            Expires 5 August 2024                [Page 10]
Internet-Draft       Using STAMP for Segment Routing       February 2024

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Segment(1)             | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Segment(n)             | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                PSID (optional)        | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Test Packet as shown in Figure 3               |
    .                                                               .
    +---------------------------------------------------------------+

       Figure 4: Example Session-Sender Test Packet for SR-MPLS Path

   The head-end node address of the SR-MPLS Policy MUST be used as the
   Source Address in the IP header of the Session-Sender test packet.
   The endpoint address of the SR-MPLS Policy MUST be used as the
   Destination Address in the IP header of the Session-Sender test
   packet.

   The Segment List can be empty in the case of a single-hop SR path
   with Implicit NULL label.  The Session-Reflector may need to receive
   Session-Sender test packets with no MPLS header, for example, when
   using Penultimate Hop Popping (PHP).  In both these cases, the
   Destination Address in IP header ensures the test packet reaches the
   Session-Reflector.

   In the case of SR-MPLS Policy with Color-Only Destination Steering,
   with endpoint as unspecified address (the null endpoint is 0.0.0.0
   for IPv4 or :: for IPv6 (all bits set to the 0 value)) as defined in
   Section 8.8.1 of [RFC9256], the loopback address from the range 127/8
   for IPv4, or the loopback address ::1/128 for IPv6 [RFC4291] can be
   used as the Destination Address in the IP header of the Session-
   Sender test packets, respectively.  In this case, the SR-MPLS
   encapsulation MUST ensure the Session-Sender test packets reach the
   endpoint of the SR Policy (for example, by adding the Prefix SID of
   the SR-MPLS Policy endpoint in the Segment List if required).

Gandhi, et al.            Expires 5 August 2024                [Page 11]
Internet-Draft       Using STAMP for Segment Routing       February 2024

   The Path Segment Identifier (PSID)
   [I-D.ietf-spring-mpls-path-segment] of an SR-MPLS Policy (either for
   Segment List or for Candidate-Path) can be added in the Segment List
   of the STAMP test packets as shown in Figure 4, and can be used for
   direct measurement as described in Section "Direct Measurement in SR
   Networks".

4.1.3.  Session-Sender Test Packet for SRv6 Policies

   An SRv6 Policy Candidate-Path can contain one or more Segment Lists.
   Each Segment List can contain a number of SRv6 SIDs as defined in
   [RFC8986].  A Session-Sender test packet MUST be transmitted using
   each Segment List of the SRv6 Policy Candidate-Path for delay
   measurement.  A packet can contain an outer IPv6 header and SRv6
   Segment Routing Header (SRH) carrying a Segment List as described in
   [RFC8754].

   The content of an example Session-Sender test packet for an SRv6
   Policy using the same IPv6/SRH encapsulation as the data traffic is
   shown in Figure 5.

    +---------------------------------------------------------------+
    | IP Header                                                     |
    .  Source IP Address = Session-Sender IPv6 Address              .
    .  Destination IP Address = Session-Reflector IPv6 Address |    .
    .                Segment List[Segments Left]                    .
    .  Next-Header = 43, Routing Type = SRH (4)                     .
    .                                                               .
    +---------------------------------------------------------------+
    | SRH as specified in RFC 8754                                  |
    .  <PSID (optional), Segment List>                              .
    .  Next-Header = UDP (17)                                       .
    .                                                               .
    +---------------------------------------------------------------+
    | UDP Header                                                    |
    .  Source Port = Dynamically chosen by Session-Sender           .
    .  Destination Port = User-configured Destination Port | 862    .
    .                                                               .
    +---------------------------------------------------------------+
    | Payload = Test Packet as specified in Section 3 of RFC 8972   |
    .           in Figure 1 and Figure 3                            .
    .                                                               .
    +---------------------------------------------------------------+

         Figure 5: Example Session-Sender Test Packet for SRv6 Path

   The head-end node address of the SRv6 Policy MUST be used as the
   Source Address in the IPv6 header of the Session-Sender test packet.

Gandhi, et al.            Expires 5 August 2024                [Page 12]
Internet-Draft       Using STAMP for Segment Routing       February 2024

   The Segment List of the SRv6 Policy Candidate-Path can be empty.  In
   this case, the endpoint address of the SRv6 Policy is used as the
   Destination Address in the IPv6 header of the Session-Sender test
   packet.

   Note that the Session-Sender test packets can be transmitted with or
   without adding the inner IP header with Source Address of the
   Session-Sender and Destination Address of the Session-Reflector after
   the IPv6/SRH.  In case of Penultimate Segment Popping (PSP), where
   IPv6/SRH encapsulation is removed on the penultimate node, Inner IP
   header MUST be added for the test packets to reach the Session-
   Reflector node.  When inner IP header is not added, the Session-
   Sender MUST ensure that the Session-Sender test packets using the
   Segment List reach the Session-Reflector (for example, by adding the
   Prefix SID or IPv6 address of the SR Policy endpoint in the Segment
   List if required).

   The SRv6 network programming is described in [RFC8986].  The
   procedure defined for Upper-Layer (UL) Header processing for SRv6 End
   SIDs in Section 4.1.1 of [RFC8986] MUST be used to process the IPv6/
   UDP header in the received Session-Sender test packets on the
   Session-Reflector.

   The Path Segment Identifier (PSID)
   [I-D.ietf-spring-srv6-path-segment] of the SRV6 Policy (either for
   Segment List or for Candidate-Path) can be added in the Segment List
   of the STAMP test packets as shown in Figure 5 and can be used for
   direct measurement as described in Section "Direct Measurement for
   Links and SR Paths".

4.1.4.  Session-Sender Test Packet for SR Flexible Algorithm IGP Path

   The delay measurement procedure for end-to-end SR paths is also
   applicable to SR-MPLS and SRv6 Flex-Algo IGP paths.

   Flex-Algo in IGP in SR networks [RFC9350] has Prefix SIDs advertised
   by the nodes for each Flex-Algo.  The STAMP test packets for delay
   measurement MUST be transmitted on the Flex-Algo path using the same
   SR encapsulation as the data traffic under measurement.

   For delay measurement of an SR-MPLS Flex-Algo IGP path, the Session-
   Sender test packets MUST carry the Flex-Algo Prefix SID of the
   Session-Reflector for that Flex-Algo IGP path in the MPLS header.

Gandhi, et al.            Expires 5 August 2024                [Page 13]
Internet-Draft       Using STAMP for Segment Routing       February 2024

   For delay measurement of an SRv6 Flex-Algo IGP path, the Session-
   Sender test packets MUST carry the Flex-Algo Prefix SIDs of the
   Session-Sender and Session-Reflector for that Flex-Algo IGP path as
   the Source Address and Destination Address in the IPv6 header,
   respectively.

4.1.5.  Session-Sender Test Packet for P2MP SR Policies

   The delay measurement procedure for end-to-end SR-MPLS and SRv6
   Policies is equally applicable to the P2MP SR-MPLS and SRv6 Policies.

   The Point-to-Multipoint (P2MP) SR path that originates from a root
   node terminates on multiple destinations called leaf nodes (e.g.,
   P2MP SR Policy [I-D.ietf-pim-sr-p2mp-policy] Candidate-Path).  The
   Session-Sender root node MUST transmit the Session-Sender test
   packets using the Segment Lists and that may contain replication SIDs
   [I-D.ietf-spring-sr-replication-segment] for delay measurement.

   The Source Address in the Session-Sender test packets MUST be set to
   the address of the root-node of the P2MP SR-MPLS and SRv6 Policy.

   For P2MP SR-MPLS path, the Destination Address in the Session-Sender
   test packets MUST be set to a loopback address from the range 127/8
   for IPv4, or the loopback address ::1/128 for IPv6.  The SR
   encapsulation MUST ensure the Session-Sender test packets reach the
   leaf nodes of the P2MP SR Policy.

   The Session-Reflector on the leaf node MUST add its address as Source
   Address in the Session-Reflector test packet.  The P2MP root node
   measures the delay and packet loss for each leaf node independently
   using the Source Address of the leaf node from the received Session-
   Reflector reply test packets.

   The [I-D.mirsky-ippm-asymmetrical-pkts] defines extensions for using
   STAMP for performance measurement in multicast environment.  Those
   extensions also apply to the performance measurement for P2MP SR
   Policies.

4.1.6.  Session-Sender Test Packet for Layer-3 Service over SR Path

   The delay measurement procedure defined in this document for end-to-
   end SR path is also applicable to L3 services in an SR network for
   both SR-MPLS and SRv6 data planes.

Gandhi, et al.            Expires 5 August 2024                [Page 14]
Internet-Draft       Using STAMP for Segment Routing       February 2024

4.1.6.1.  Session-Sender Test Packet for Layer-3 Service over SR-MPLS
          Path

   For delay measurement of end-to-end L3 service over SR-MPLS path, the
   same SR-MPLS label stack as the data packets of the L3 service
   including the L3VPN SR-MPLS label (advertised by the Session-
   Reflector) is used to transmit Session-Sender test packets.

   An IP header (as shown in Figure 3) MUST be added in the Session-
   Sender test packets after the SR-MPLS encapsulation.  The Destination
   Address on the Session-Reflector added in the IP header MUST be
   reachable via the IP table lookup associated with the L3VPN SR-MPLS
   label.

4.1.6.2.  Session-Sender Test Packet for Layer-3 Service over SRv6 Path

   For delay measurement of end-to-end L3 service over SRv6 path, the
   same IPv6/SRH encapsulation as the data packets of the L3 service
   including the L3VPN SRv6 SID instantiated on the Session-Reflector
   (for example, End.DT6 SID instance, End.DT4 SID instance, etc.
   defined in [RFC8986]) is used to transmit Session-Sender test
   packets.

   An inner IP header (as shown in Figure 3) MAY be added in the
   Session-Sender test packets after the IPv6/SRH encapsulation.  The
   Destination Address on the Session-Reflector added in the inner IP
   header MUST be reachable via the IPv4 or IPv6 table lookup associated
   with the L3VPN SRv6 SID.

4.1.7.  Session-Sender Test Packet for Layer-2 Service over SR Path

   The delay measurement procedure defined in this document for end-to-
   end SR path is also applicable to L2 services in an SR network for
   both SR-MPLS and SRv6 data planes.

4.1.7.1.  Session-Sender Test Packet for Layer-2 Service over SR-MPLS
          Path

   For delay measurement of end-to-end L2 service over SR-MPLS path, the
   same SR-MPLS label stack as the data packets of the L2 service
   including the L2VPN SR-MPLS label (advertised by the Session-
   Reflector) is used to transmit Session-Sender test packets.

   The L2VPN SR-MPLS label is added with a TTL value of 1 in order to
   punt the Session-Sender test packet from data plane to CPU or slow
   path on Session-Reflector for STAMP processing.

Gandhi, et al.            Expires 5 August 2024                [Page 15]
Internet-Draft       Using STAMP for Segment Routing       February 2024

   An IP header (as shown in Figure 3) MUST be added in the Session-
   Sender test packets after the MPLS header.  It contains the Source
   Address of the Session-Sender and Destination Address of the Session-
   Reflector.

4.1.7.2.  Session-Sender Test Packet for Layer-2 Service over SRv6 Path

   For delay measurement of end-to-end L2 service over SRv6 path, the
   same IPv6/SRH encapsulation as the data packets of the L2 service
   including the L2VPN SRv6 SID instantiated on the Session-Reflector
   (for example, End.DT2U SID instance defined in [RFC8986]) is used to
   transmit Session-Sender test packets.

   An L2 header MAY also be added (after the IPv6/SRH encapsulation) in
   the Session-Sender test packets that contains the Session-Sender MAC
   address as Source MAC address and Session-Reflector MAC address as
   Destination MAC address.  The Destination MAC address added in the L2
   header MUST be reachable via the L2 MAC table lookup associated with
   the L2VPN SRv6 SID.

   An inner IP header (as shown in Figure 3) MAY also be added in the
   Session-Sender test packets after the IPv6/SRH and L2 header (if
   present).  It contains the Source Address of the Session-Sender and
   Destination Address of the Session-Reflector.

4.2.  Session-Reflector Test Packet

   The Session-Reflector decapsulates the outer IP header (if present)
   and the SR header (SR-MPLS header or IPv6/SRH if present) from the
   received Session-Sender test packets.  The Session-Reflector reply
   test packet is generated using the information from the IP/UDP header
   of the received Session-Sender test packet as shown in Figure 6.

Gandhi, et al.            Expires 5 August 2024                [Page 16]
Internet-Draft       Using STAMP for Segment Routing       February 2024

    +---------------------------------------------------------------+
    | IP Header                                                     |
    .  Source IP Address                                            .
    .     = Destination IP Address from Session-Sender Test Packet  .
    .  Destination IP Address                                       .
    .     = Source IP Address from Session-Sender Test Packet       .
    .  IPv4 Protocol or IPv6 Next header = UDP (17)                 .
    .                                                               .
    +---------------------------------------------------------------+
    | UDP Header                                                    |
    .  Source Port                                                  .
    .     = Destination Port from Session-Sender Test Packet        .
    .  Destination Port                                             .
    .     = Source Port from Session-Sender Test Packet             .
    .                                                               .
    +---------------------------------------------------------------+
    | Payload = Test Packet as specified in Section 3 of RFC 8972   |
    .           in Figure 2 and Figure 4                            .
    .                                                               .
    +---------------------------------------------------------------+

              Figure 6: Example Session-Reflector Test Packet

   The payload contains the Session-Reflector test packet defined in
   Section 3 of [RFC8972].

4.2.1.  One-Way Measurement Mode

   In one-way delay measurement mode, a reply test packet with the
   contents as shown in Figure 6 is transmitted by the Session-
   Reflector, for links, end-to-end SR paths and L3 and L2 services in
   SR networks.  The Session-Reflector reply test packet can be
   transmitted in the reverse direction on the same path as the forward
   direction or a different path than the forward direction to the
   Session-Sender.

   In this mode, as per Reference Topology, all timestamps T1, T2, T3,
   and T4 are collected by the STAMP test packets.  However, only
   timestamps T1 and T2 are used to measure one-way delay as (T2 - T1).
   Note that the delay value (T2 - T1) is referred to as near-end
   (forward direction) one-way delay and the delay value (T4 - T3) is
   referred to as far-end (backward direction) one-way delay.  The one-
   way delay measurement mode requires the clocks on the Session-Sender
   and Session-Reflector to be synchronized.

   In one-way delay measurement mode, optionally, the Session-Sender may
   request in the test packet to the Session-Reflector to not transmit
   the reply test packet.  The Session-Sender can use the "No Reply

Gandhi, et al.            Expires 5 August 2024                [Page 17]
Internet-Draft       Using STAMP for Segment Routing       February 2024

   Requested" flag in the Control Code Sub-TLV in the Return Path TLV
   defined in [RFC9503] for this request.  In this case, only timestamps
   T1 and T2 are collected by the STAMP packets.

4.2.2.  Two-Way Measurement Mode

   In two-way (i.e., round-trip) delay measurement mode, a reply test
   packet as shown in Figure 6 SHOULD be transmitted by the Session-
   Reflector on the same path in the reverse direction as the forward
   direction, e.g., on the same link in the reverse direction or on the
   reverse SR path associated with the forward SR path
   [I-D.ietf-pce-sr-bidir-path].

   In two-way delay measurement mode for links, the Session-Sender may
   request in the test packet to the Session-Reflector to transmit the
   reply test packet back on the same link in the reverse direction, for
   example, in an ECMP environment.  It can use the "Reply Requested on
   the Same Link" flag in the Control Code Sub-TLV in the Return Path
   TLV defined in [RFC9503] for this request.

   In two-way delay measurement mode for end-to-end SR paths and L3 and
   L2 services, the Session-Sender may request in the test packet to the
   Session-Reflector to transmit the reply test packet back on a
   specific reverse SR path, for example, in an ECMP environment or in
   SR Flex-Algo IGP environment.  It can use a Segment List sub-TLV in
   the Return Path TLV defined in [RFC9503] for this request.

   In this mode, as per Reference Topology, all timestamps T1, T2, T3,
   and T4 are collected by the STAMP test packets.  All four timestamps
   are used to measure two-way delay as ((T4 - T1) - (T3 - T2)).

4.2.2.1.  Session-Reflector Test Packet for SR-MPLS Policies

   The content of an example Session-Reflector reply test packet
   transmitted for two-way delay measurement of an end-to-end SR-MPLS
   Policy using the same SR-MPLS encapsulation as the data traffic in
   the reverse direction is shown in Figure 7.

Gandhi, et al.            Expires 5 August 2024                [Page 18]
Internet-Draft       Using STAMP for Segment Routing       February 2024

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Segment(1)             | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Segment(n)             | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                PSID (optional)        | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Test Packet as shown in Figure 6               |
    .                                                               .
    +---------------------------------------------------------------+

      Figure 7: Example Session-Reflector Test Packet for SR-MPLS Path

4.2.2.2.  Session-Reflector Test Packet for SRv6 Policies

   The content of an example Session-Reflector reply test packet
   transmitted for two-way delay measurement of an end-to-end SRv6
   Policy using the same IPv6/SRH encapsulation as the data traffic in
   the reverse direction is shown in Figure 8.

Gandhi, et al.            Expires 5 August 2024                [Page 19]
Internet-Draft       Using STAMP for Segment Routing       February 2024

    +---------------------------------------------------------------+
    | IP Header                                                     |
    .  Source IP Address                                            .
    .       = Destination IPv6 Address from Received Test Packet    .
    .  Destination IP Address                                       .
    .       = Source IPv6 Address from Received Test Packet OR      .
    .         Segment List[Segments Left]                           .
    .  Next-Header = 43, Routing Type = SRH (4)                     .
    .                                                               .
    +---------------------------------------------------------------+
    | SRH as specified in RFC 8754                                  |
    .  <PSID (optional), Segment List>                              .
    .  Next-Header = UDP (17)                                       .
    .                                                               .
    +---------------------------------------------------------------+
    | UDP Header                                                    |
    .  Source Port = Destination Port from Received Test Packet     .
    .  Destination Port = Source Port from Received Test Packet     .
    .                                                               .
    +---------------------------------------------------------------+
    | Payload = Test Packet as specified in Section 3 of RFC 8972   |
    .           in Figure 2 and Figure 4                            .
    .                                                               .
    +---------------------------------------------------------------+

       Figure 8: Example Session-Reflector Test Packet for SRv6 Path

   The procedure defined for Upper-Layer Header processing for SRv6 End
   SIDs in Section 4.1.1 in [RFC8986] MUST be used to process the IPv6/
   UDP header in the received Session-Reflector reply test packets on
   the Session-Sender.

5.  Loopback Measurement Mode in SR Networks

   The Session-Sender test packets are transmitted in loopback
   measurement mode to measure loopback delay of a bidirectional
   circular path.  In this mode, the received Session-Sender test
   packets MUST NOT be punted out of the fast path in data plane (i.e.,
   to slow path or control-plane) at the Session-Reflector.  In other
   words, the Session-Reflector does not process them and generate
   Session-Reflector test packets.  This is a new measurement mode, not
   defined by the STAMP process in [RFC8762].

Gandhi, et al.            Expires 5 August 2024                [Page 20]
Internet-Draft       Using STAMP for Segment Routing       February 2024

                          T1
                         /
                +-------+     Test Packet     +-------+
                |       | - - - - - - - - - - |       |
                |   S1  |====================||   R1  |
                |       |<- - - - - - - - - - |       |
                +-------+  Return Test Packet +-------+
                         \                    Loopback
                          T4

            STAMP Session-Sender

               Figure 9: Reference Topology for Loopback Mode

   In this mode, as shown in Figure 9, Reference Topology for Loopback
   Mode, the Session-Sender test packet received back at the Session-
   Sender retrieves the timestamp T1 from the test packet and collects
   the receive timestamp T4 locally.  Both these timestamps are used to
   measure the loopback delay as (T4 - T1).  The loopback delay includes
   the STAMP test packet processing delay on the Session-Reflector
   component.  The Session-Reflector processing delay component includes
   only the time required to loop the STAMP test packet from the
   incoming interface to the outgoing interface in the data plane.  The
   Session-Reflector does not timestamp the Session-Sender test packets
   and hence does not need timestamping capability.

5.1.  Loopback Measurement Mode STAMP Packet Processing

   The Session-Sender MUST set the Destination UDP port to the UDP port
   it uses to receive the return Session-Reflector test packets (other
   than the UDP Destination port 862 which is used by the STAMP Session-
   Reflector).  The same UDP port can be used as the Source UDP port in
   the Session-Sender test packet.

   The Session-Reflector does not support the STAMP process, hence the
   loopback function simply processes the encapsulation including IP and
   SR headers (but does not process the UDP header) to forward the
   received Session-Sender test packet to the Session-Sender without
   STAMP modifications defined in [RFC8762].

   The Session-Sender can use the STAMP Session ID (SSID) field in the
   received reply STAMP test packet or local configuration to identify
   its STAMP test session that uses the loopback mode.  In this mode, at
   the Session-Sender, the 'Session-Sender Sequence Number', 'Session-
   Sender Timestamp', 'Session-Sender Error Estimate', and 'Session-
   Sender TTL' fields MUST be set to zero in the transmitted STAMP test
   packets and MUST be ignored in the received STAMP test packets.

Gandhi, et al.            Expires 5 August 2024                [Page 21]
Internet-Draft       Using STAMP for Segment Routing       February 2024

5.2.  Loopback Measurement Mode for Links

   In loopback mode for links, an inner IP header for the return path is
   added in the Session-Sender test packets as shown in Figure 10 and it
   MUST set the Destination Address equal to the Session-Sender address.

    +---------------------------------------------------------------+
    | IP Header (Return Path)                                       |
    .  Source IP Address = Session-Sender IP Address                .
    .  Destination IP Address = Session-Sender IP Address           .
    .  IPv4 Protocol or IPv6 Next header = UDP (17)                 .
    .                                                               .
    +---------------------------------------------------------------+
    | UDP Header                                                    |
    .  Source Port = Dynamically chosen by Session-Sender           .
    .  Destination Port = Source Port                               .
    .                                                               .
    +---------------------------------------------------------------+
    | Payload = Test Packet as specified in Section 3 of RFC 8972   |
    .           in Figure 1 and Figure 3                            .
    .                                                               .
    +---------------------------------------------------------------+

   Figure 10: Example Session-Sender Return Test Packet in Loopback Mode

   The Session-Sender test packets in loopback mode may be transmitted
   with a Layer-2 header for the forward path as shown in Figure 11,
   containing Session-Reflector MAC address as the Destination Address
   and Session-Sender MAC address as the Source MAC address of Ethernet
   links.  An SR encapsulation (e.g., containing adjacency SID of the
   link) can also be added for the forward path after the Layer-2
   header.

    +---------------------------------------------------------------+
    | L2 MAC Header (Forward Path)                                  |
    .  Source Address = Session-Sender MAC Address                  .
    .  Destination Address = Session-Reflector MAC Address          .
    .  Ether-Type = 0x0800 (IPv4) Or 0x86DD (IPv6)                  .
    .                                                               .
    +---------------------------------------------------------------+
    |                Test Packet as shown in Figure 10              |
    .                                                               .
    +---------------------------------------------------------------+

       Figure 11: Example Session-Sender Test Packet in Loopback for
                               Ethernet Link

Gandhi, et al.            Expires 5 August 2024                [Page 22]
Internet-Draft       Using STAMP for Segment Routing       February 2024

5.3.  Loopback Measurement Mode for SR-MPLS Paths

   An SR-MPLS path uses an MPLS header for carrying a Segment List in
   MPLS label stack.  In the case of loopback mode for SR-MPLS paths,
   the Session-Sender test packet can either carry the Segment List of
   the forward SR-MPLS path only or both the forward and the reverse SR-
   MPLS paths in MPLS header as shown in Figure 12.

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Segment(1)             | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Segment(n)             | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                PSID (optional)        | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Test Packet as shown in Figure 10              |
    .                                                               .
    +---------------------------------------------------------------+

       Figure 12: Example Session-Sender Test Packet in Loopback Mode
                              for SR-MPLS Path

   In the case of SR-MPLS Policy using Penultimate Hop Popping (PHP),
   the Session-Sender MUST ensure that the STAMP test packets reach the
   SR-MPLS Policy endpoint (for example, by adding the Prefix SID of the
   SR-MPLS Policy endpoint in the Segment List of the forward path if
   required).

5.3.1.  Reverse SR-MPLS Path

   To receive the return Session-Sender test packet on a specific SR-
   MPLS path in an ECMP environment, the SR-MPLS label stack needs to
   carry the specific reverse direction SR-MPLS path, in addition to the
   forward direction SR-MPLS path.  For example, it can carry the
   corresponding SR-MPLS label stack of the Segment List of the reverse
   SR-MPLS Policy Candidate-Path [I-D.ietf-pce-sr-bidir-path] or the
   Binding SID of the reverse SR-MPLS Policy or the SR-MPLS Prefix
   Segment Identifier of the Session-Sender.  For SR-MPLS Flex-Algo IGP
   paths, it MUST carry the matching SR-MPLS Flex-Algo Prefix SID label
   of the Session-Sender.

Gandhi, et al.            Expires 5 August 2024                [Page 23]
Internet-Draft       Using STAMP for Segment Routing       February 2024

   The IP header of the Session-Sender test packets MUST set the
   Destination Address equal to the Session-Sender address as shown in
   Figure 10.

5.3.2.  Reverse IP/UDP Path

   In the case of loopback mode for SR-MPLS paths, the MPLS header can
   carry the SR-MPLS label stack of the forward SR path only.

   The IP header for the return path of the Session-Sender test packets
   MUST set the Destination Address equal to the Session-Sender address
   as shown in Figure 10 to forward the packet to the Session-Sender.

   The Session-Reflector decapsulates the MPLS header and forwards the
   packet using the IP header for the return path.

5.4.  Loopback Measurement Mode for SRv6 Paths

   An SRv6 path uses an IPv6 header and SRv6 Segment Routing Header
   (SRH) for carrying a Segment List as described in [RFC8754].  In the
   case of loopback mode for SRv6 paths, the Session-Sender test packet
   can either carry the Segment List of the forward SRv6 path only or
   both the forward and the reverse SRv6 paths in IPv6/SRH as shown in
   Figure 13.

    +---------------------------------------------------------------+
    | IP Header                                                     |
    .  Source IP Address = Session-Sender IPv6 Address              .
    .  Destination IP Address = Session-Reflector IPv6 Address |    .
    .                Segment List[Segments Left]                    .
    .  Next-Header = 43, Routing Type = SRH (4)                     .
    .                                                               .
    +---------------------------------------------------------------+
    | SRH as specified in RFC 8754                                  |
    .  <PSID (optional), Segment List>                              .
    .                                                               .
    +---------------------------------------------------------------+
    |                Test Packet as shown in Figure 10              |
    .                                                               .
    +---------------------------------------------------------------+

       Figure 13: Example Session-Sender Test Packet in Loopback Mode
                               for SRv6 Path

   The Session-Sender MUST ensure that the Session-Sender test packets
   using the Segment List reach the SRv6 Policy endpoint (for example,
   by adding the Prefix SID or IPv6 address of the SRv6 Policy endpoint
   in the Segment List if required).

Gandhi, et al.            Expires 5 August 2024                [Page 24]
Internet-Draft       Using STAMP for Segment Routing       February 2024

5.4.1.  Reverse SRv6 Path

   To receive the return Session-Sender test packet on a specific SRv6
   path in an ECMP environment, the SRv6 Segment List needs to carry the
   specific reverse direction SRv6 path, in addition to the forward
   direction SRv6 path.  For example, it can carry the corresponding
   Segment List of the reverse SRv6 Policy Candidate-Path
   [I-D.ietf-pce-sr-bidir-path] or the Binding SID of the reverse SRv6
   Policy or the SRv6 Prefix Segment Identifier of the Session-Sender.
   For SRv6 Flex-Algo IGP paths, it MUST carry the matching SRv6 Flex-
   Algo Prefix SID of the Session-Sender.

   An inner IP header MAY be added in the Session-Sender test packet and
   that has the Destination Address equal to the Session-Sender address
   as shown in Figure 10.

5.4.2.  Reverse IP/UDP Path

   In the case of loopback mode for SRv6 paths, the Session-Sender test
   packet can contain the Segment List of the forward SRv6 path only.

   An inner IP header for return path MUST be added in the Session-
   Sender test packets that has the Destination Address equal to the
   Session-Sender address as shown in Figure 10 to forward the packet to
   the Session-Sender.

   The Session-Reflector decapsulates the outer IPv6/SRH headers and
   forwards the packet using the inner IP header for the return path.

5.5.  Loopback Measurement Mode for Layer-3 Service over SR Path

   The loopback measurement mode is also applicable to L3 services in an
   SR network for both SR-MPLS and SRv6 data planes.

5.5.1.  Loopback Measurement Mode for Layer-3 Service over SR-MPLS Path

   In loopback mode for L3 service over SR-MPLS path, the same SR-MPLS
   label stack as the data packets of the L3 service including the L3VPN
   SR-MPLS label (advertised by the Session-Reflector) is used to
   transmit Session-Sender test packets.

   An IP header for return path MUST be added in the Session-Sender test
   packets that has the Destination Address equal to the Session-Sender
   address as shown in Figure 10 to forward the packet to the Session-
   Sender.  In this case, the Destination Address added in the IP header
   for the return path MUST be reachable via the IP table lookup
   associated with the L3VPN SR-MPLS label in the reverse direction.

Gandhi, et al.            Expires 5 August 2024                [Page 25]
Internet-Draft       Using STAMP for Segment Routing       February 2024

   The Session-Reflector decapsulates the MPLS header and forwards the
   packet using the IP header for the return path.

5.5.2.  Loopback Measurement Mode for Layer-3 Service over SRv6 Path

   In loopback mode for L3 service over SRv6 path, the same IPv6/SRH
   encapsulation as the data packets of the L3 service including the
   L3VPN SRv6 SID instantiated on the Session-Reflector (for example,
   End.DT6 SID instance, End.DT4 SID instance, etc.  defined in
   [RFC8986]) is used to transmit Session-Sender test packets.

   An inner IP header for return path MUST be added in the Session-
   Sender test packets that has the Destination Address equal to the
   Session-Sender address as shown in Figure 10 to forward the packet to
   the Session-Sender.  In this case, the Destination Address added in
   the inner IP header for the return path MUST be reachable via the
   IPv4 or IPv6 table lookup associated with the L3VPN SRv6 SID in the
   reverse direction.

   The Session-Reflector decapsulates the outer IPv6/SRH and forwards
   the packet using the inner IP header for the return path.

5.6.  Loopback Measurement Mode for Layer-2 Service over SR Path

   The loopback measurement mode is also applicable to L2 services in an
   SR network for both SR-MPLS and SRv6 data planes.

5.6.1.  Loopback Measurement Mode for Layer-2 Service over SR-MPLS Path

   Editor's Note: This mode is currently under investigation.

   In loopback mode for L2 service over SR-MPLS path, the same SR-MPLS
   label stack as the data packets of the L2 service including the L2VPN
   SR-MPLS label (advertised by the Session-Reflector) is used to
   transmit Session-Sender test packets.

   An IP header for return path MUST be added in the Session-Sender test
   packets that has the Destination Address equal to the Session-Sender
   address as shown in Figure 10 to forward the packet to the Session-
   Sender.

   The Session-Reflector decapsulates the MPLS header and forwards the
   packet using the IP header for the return path.

5.6.2.  Loopback Measurement Mode for Layer-2 Service over SRv6 Path

   Editor's Note: This mode is currently under investigation.

Gandhi, et al.            Expires 5 August 2024                [Page 26]
Internet-Draft       Using STAMP for Segment Routing       February 2024

   In loopback mode for L2 service over SRv6 path, the same IPv6/SRH
   encapsulation as the data packets of the L2 service including the
   L2VPN SRv6 SID instantiated on the Session-Reflector (for example,
   End.DT2U SID instance defined in [RFC8986]) is used to transmit
   Session-Sender test packets.

   An L2 header for return path is added (after the IPv6/SRH
   encapsulation) in the Session-Sender test packets that contains the
   Session-Sender MAC Address as Source and Destination MAC address.
   The Destination MAC address added in the L2 header MUST be reachable
   via the L2 MAC table lookup associated with the L2VPN SRv6 SID.

   An inner IP header for return path MUST be added in the Session-
   Sender test packets that has the Destination Address equal to the
   Session-Sender address as shown in Figure 10 to forward the packet to
   the Session-Sender.

   The Session-Reflector decapsulates the outer IPv6/SRH header and L2
   header and forwards the packet using the inner IP header for the
   return path.

6.  Loopback Measurement Mode with Timestamp and Forward Function in SR
    Networks

   This document defines a new STAMP measurement mode, called "loopback
   mode with timestamp and forward" that uses network programming
   function.  In this mode, the timestamps T1, T2, and T4, all in data
   plane, are collected by the Session-Sender test packet as shown in
   Figure 14.  The network programming function is used to optimize the
   "operations of punt test packet and generate return test packet" on
   the Session-Reflector, as timestamping is implemented in fast path in
   data plane.  This helps to achieve higher number of STAMP test
   session scale and faster measurement interval.

   The Session-Sender adds transmit timestamp (T1) in the payload of the
   Session-Sender test packet.  The Session-Reflector adds the receive
   timestamp (T2) in the payload of the received test packet in fast
   path in data plane without punting the test packet (e.g., to slow
   path or control-plane).  The network programming function carried by
   the test packet enables the Session-Reflector to add the receive
   timestamp (T2) at the specific offset in the payload of the test
   packet.

Gandhi, et al.            Expires 5 August 2024                [Page 27]
Internet-Draft       Using STAMP for Segment Routing       February 2024

                            T1                  T2
                           /                     \
                  +-------+      Test Packet      +-------+
                  |       | - - - - - - - - - - - |       |
                  |   S1  |======================||  R1   |
                  |       |<- - - - - - - - - - - |       |
                  +-------+   Return Test Packet  +-------+
                           \                      Loopback
                            T4

                STAMP Session-Sender     STAMP Session-Reflector
                                                (Timestamp,
                                                 and Forward)

       Figure 14: Reference Topology for Loopback Mode with Timestamp
                            and Forward Function

   For an end-to-end SR path including SR Policy, STAMP Session-Sender
   test packets are transmitted in loopback mode with timestamp and
   forward function as described in the following sub-sections.

6.1.  Loopback Measurement Mode with Timestamp and Forward Function for
      SR-MPLS Paths

   The loopback measurement mode with timestamp and forward network
   programming function for SR-MPLS paths is described below.

   MPLS Network Action (MNA) Sub-Stack defined in
   [I-D.ietf-mpls-mna-hdr] is used for SR-MPLS data plane for "timestamp
   and forward" network programming function for the STAMP test packets.
   The MNA Sub-Stack carries the MNA Label (bSPL value TBA1) as defined
   in [I-D.ietf-mpls-mna-hdr].  A new MNA Opcode (value MNA.TSF) is
   defined for the Timestamp and Forward network action.

   In the Session-Sender test packets for SR-MPLS Policies paths, the
   MNA Sub-Stack with Opcode MNA.TSF is added in the MPLS header as
   shown in Figure 15, to collect "Receive Timestamp" field in the
   payload of the test packet.  The Ingress-to-Egress (I2E), Hop-By-Hop
   (HBH), Select scope (IHS) is set to "I2E" when return path is IP/UDP.
   The Network Action Sub-Stack Length (NASL) is set to 0 when there is
   no Label Stack Entry (LSE) after the MNA.TSF Opcode in the MNA Sub-
   Stack.  The U flag is set to skip the network action and forward the
   packet (and not drop the packet).

   The Label Stack for the reverse direction SR-MPLS path can be added
   after the MNA Sub-Stack to receive the return test packet on a
   specific path.  The Ingress-to-Egress (I2E), Hop-By-Hop (HBH), Select
   scope (IHS) is set to "Select" when the return path is SR-MPLS.

Gandhi, et al.            Expires 5 August 2024                [Page 28]
Internet-Draft       Using STAMP for Segment Routing       February 2024

   When a Session-Reflector receives a packet with MNA Sub-Stack with
   Opcode MNA.TSF, after timestamping the packet in STAMP payload at the
   specific offset, the Session-Reflector pops the MNA Sub-Stack (after
   completing any other network actions) and forwards the packet using
   the next label or IP header in the packet (just like the data packets
   for the traffic flow).

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Label(1)                   | TC  |S|      TTL      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Label(n)                   | TC  |S|      TTL      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            MNA Label (value TBA1)     | TC  |S|      TTL      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |7-bit MNA.TSF|  0x0                    |R|IHS|S| RES |U|NASL=0 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Test Packet as shown in Figure 10              |
     .                                                               .
     +---------------------------------------------------------------+

     Figure 15: Example STAMP Test Packet with MNA for TSF for SR-MPLS

6.1.1.  Timestamp and Forward Network Action Assignment

   New MPLS Network Action Opcode is defined called "Timestamp and
   Forward Network Action, MNA.TSF".  The MNA.TSF Opcode is statically
   configured on the STAMP Session-Reflector node with a value from
   "Private Use from Range 111-126".  The timestamp format for 64-bit
   PTPv2 and NTP to be added in the STAMP payload is statically
   configured for MNA.TSF.  The offset in the STAMP payload (e.g., for
   unauthenticated mode (value 16)) is also statically configured for
   MNA.TSF.

6.1.2.  Node Capability for MNA Sub-Stack with Opcode MNA.TSF

   The STAMP Session-Sender needs to know if the Session-Reflector can
   process the MNA Sub-Stack with Opcode MNA.TSF to avoid dropping the
   test packets.  The signaling extension for this capability exchange
   or local configuration are outside the scope of this document.

Gandhi, et al.            Expires 5 August 2024                [Page 29]
Internet-Draft       Using STAMP for Segment Routing       February 2024

6.2.  Loopback Measurement Mode with Timestamp and Forward Function for
      SRv6 Paths

   The loopback measurement mode with timestamp and forward network
   programming function for SRv6 paths is described below.

   The [RFC8986] defines SRv6 Endpoint Behaviours for SRv6 nodes.  A new
   SRv6 Endpoint Behaviour is defined for "Timestamp and Forward (TSF)"
   network programming function for the STAMP test packets.

   In the Session-Sender test packets for SRv6 Policies, Timestamp and
   Forward Endpoint Function (End.TSF) is carried with the target
   Segment Identifier (SID) in SRH [RFC8754] as shown in Figure 16, to
   collect "Receive Timestamp" field in the payload of the test packet.
   The Segment List for the reverse direction path can be added after
   the target SID to receive the return test packet on a specific path.
   When a Session-Reflector receives a packet with Timestamp and Forward
   Endpoint (End.TSF) for the target SID, which is local, after
   timestamping the packet at the specific offset, the Session-Reflector
   forwards the packet using the next SID in the SRH or inner IPv6
   header in the packet (just like the data packets for the traffic
   flow).

     +---------------------------------------------------------------+
     | IP Header                                                     |
     .  Source IP Address = Session-Sender IPv6 Address              .
     .  Destination IP Address = Session-Reflector IPv6 Address |    .
     .                Segment List[Segments Left]                    .
     .  Next-Header = 43, Routing Type = SRH (4)                     .
     .                                                               .
     +---------------------------------------------------------------+
     | SRH as specified in RFC 8754                                  |
     .     <Segment List>                                            .
     .     <SRv6 Endpoint End.TSF>                                   .
     .                                                               .
     +---------------------------------------------------------------+
     |                Test Packet as shown in Figure 10              |
     .                                                               .
     +---------------------------------------------------------------+

      Figure 16: Example STAMP Test Packet with Endpoint Function for
                                TSF for SRv6

Gandhi, et al.            Expires 5 August 2024                [Page 30]
Internet-Draft       Using STAMP for Segment Routing       February 2024

6.2.1.  Timestamp and Forward Endpoint Function Assignment

   New SRv6 Endpoint Behavior is defined called "Endpoint Behavior bound
   to SID with Timestamp and Forward (End.TSF)".  The End.TSF is a node
   SID instantiated at STAMP Session-Reflector node.  The End.TSF is
   statically configured on the STAMP Session-Reflector node and not
   advertised into the routing protocols.  The timestamp format for
   64-bit PTPv2 and NTP to be added in the STAMP payload is statically
   configured for End.TSF.  The offset in the STAMP payload (e.g., for
   unauthenticated mode (value 16)) is also statically configured for
   End.TSF.

6.2.2.  Node Capability for Timestamp and Forward Endpoint Function

   The STAMP Session-Sender needs to know if the Session-Reflector can
   process the Timestamp and Forward Endpoint Function to avoid dropping
   test packets.  The signaling extension for this capability exchange
   or local configuration are outside the scope of this document.

7.  Packet Loss Measurement in SR Networks

   The procedure described in Section 4 for delay measurement in SR
   networks using STAMP test packets can also be used for packet loss
   measurement in SR networks.  The Sequence Number field in the STAMP
   test packet can be used as described in Section 4 "Theory of
   Operation" in [RFC8762], to detect round-trip, near-end (forward
   direction) and far-end (backward direction) packet loss in SR
   networks.  This method is used for inferred packet loss measurement
   that provides only an approximate view of the data packet loss.

   In case of the loopback mode, and loopback mode with timestamp and
   forward function, both introduced in this document, only the round-
   trip packet loss detection is applicable.

8.  Direct Measurement in SR Networks

   The STAMP "Direct Measurement" TLV (Type 5) defined in [RFC8972] can
   be used in SR networks for data packet loss measurement.  The STAMP
   test packets with this TLV are transmitted using the procedures
   described in Section 4 for delay measurement using STAMP test packets
   to collect the Session-Sender transmit counters and Session-Reflector
   receive and transmit counters of the data packet flows for direct
   measurement.

   The PSID carried in the received data packet for the traffic flow
   under measurement can be used to measure receive data packets (for
   receive traffic counter) for an end-to-end SR path on the Session-
   Reflector.  The PSID in the received Session-Sender test packet

Gandhi, et al.            Expires 5 August 2024                [Page 31]
Internet-Draft       Using STAMP for Segment Routing       February 2024

   header can be used to associate the receive traffic counter to the
   end-to-end SR path on the Session-Reflector.  In the case of L3 and
   L2 services in SR networks, the associated SR-MPLS service labels or
   SRv6 service SIDs, can be used for receive traffic counters.

   In case of the loopback mode, and loopback mode with timestamp and
   forward function, both introduced in this document, the direct
   measurement is not applicable.

9.  ECMP Measurement in SR Networks

   An SR Policy can have ECMPs between the source and transit nodes,
   between transit nodes and between transit and destination nodes.
   Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP
   paths via transit nodes part of that Anycast group.  The STAMP test
   packets need to be transmitted to traverse different ECMP paths to
   measure end-to-end delay of an SR Policy.

   Forwarding plane has various hashing functions available to forward
   packets on specific ECMP paths.  The mechanisms described in
   [RFC8029] and [RFC5884] for handling ECMPs are also applicable to
   delay measurement.

   For SR-MPLS Policy, sweeping of MPLS entropy label [RFC6790] values
   can be used in Session-Sender test packets and Session-Reflector
   reply test packets to take advantage of the hashing function in data
   plane to influence the ECMP path taken by them.

   In IPv4 header of the Session-Sender test packets and Session-
   Reflector reply test packets sweeping of Destination Address from the
   range 127/8 can be used to exercise ECMP paths taken by them when
   using MPLS header.

   As specified in [RFC6437], Flow Label field in the outer IPv6 header
   can also be used for sweeping to exercise different IPv6 ECMP paths.

10.  STAMP Session State

   The STAMP test session state monitoring allows to know if the
   performance measurement test is active or idle.  The threshold-based
   notification for delay and packet loss may not be generated if the
   delay and packet loss values do not change significantly.  For an
   unambiguous monitoring, the controller needs to distinguish the cases
   whether the performance measurement is active, or delay and packet
   loss values are not changing significantly to cross the threshold.

Gandhi, et al.            Expires 5 August 2024                [Page 32]
Internet-Draft       Using STAMP for Segment Routing       February 2024

   The STAMP test session state is initially notified as active as soon
   as one or more reply test packets are received at the Session-Sender.
   The STAMP test session state is notified as idle (or failed) when
   consecutive N number of reply test packets are not received at the
   Session-Sender after the session state is notified as active, where N
   (consecutive packet loss count) is a locally provisioned value.  In
   this case, the failed state of the STAMP test session on the Session-
   Sender also indicates that the connectivity verification to the
   Session-Reflector has failed.

11.  Additional STAMP Test Packet Processing Rules

   The processing rules described in this section are applicable to the
   STAMP test packets for links, end-to-end SR paths, and L3 and L2
   services in SR networks.

11.1.  TTL

   The TTL field in the IPv4 and MPLS headers of the Session-Sender and
   Session-Reflector test packets MUST be set to 255 as per Generalized
   TTL Security Mechanism (GTSM) [RFC5082].

11.2.  IPv6 Hop Limit

   The Hop Limit (HL) field in all IPv6 headers of the Session-Sender
   and Session-Reflector test packets MUST be set to 255 as per
   Generalized TTL Security Mechanism (GTSM) [RFC5082].

11.3.  Router Alert Option

   The Router Alert IP option (RAO) [RFC2113] MUST NOT be set in the
   STAMP test packets to be able to punt the test packets using the UDP
   ports for STAMP.

11.4.  IPv6 Flow Label

   The Flow Label field in the IPv6 header of the STAMP test packet is
   set to the value that is used by the data packets for the traffic
   flow on the SR path being measured by the Session-Sender.

   The Session-Reflector SHOULD return the same Flow Label value it
   received in the STAMP test packet IPv6 header in the STAMP reply test
   packet, and it can be based on the local policy on the Session-
   Reflector.

Gandhi, et al.            Expires 5 August 2024                [Page 33]
Internet-Draft       Using STAMP for Segment Routing       February 2024

11.5.  UDP Checksum

   For IPv4 test packets, where the hardware is not capable of re-
   computing the UDP checksum or adding checksum complement [RFC7820],
   the Session-Sender and Session-Reflector can set the UDP checksum
   value to 0 [RFC8085].

   For IPv6 test packets, where the hardware is not capable of re-
   computing the UDP checksum or adding checksum complement [RFC7820],
   the Session-Sender and Session-Reflector can use the procedure
   defined in [RFC6936] for the UDP checksum (with value set to 0) for
   the UDP ports used for STAMP sessions.

12.  Implementation Status

   Editorial note: Please remove this section prior to publication.

   The following routing platforms running IOS-XR operating system have
   participated in an interop testing for one-way, two-way and loopback
   measurement modes:

   * Cisco 8802 (based Cisco Silicon One Q200)

   * Cisco ASR9904 with Lightspeed linecard and Tomahawk linecard

   * Cisco NCS5500 (based on Broadcom Jericho1 platform)

   * Cisco NCS5700 (based on Broadcom Jericho2 platform)

13.  Security Considerations

   The security considerations specified in [RFC8762], [RFC8972], and
   [RFC9503] also apply to the procedures described in this document.

   Use of HMAC-SHA-256 in the authenticated mode protects the data
   integrity of the STAMP test packets.  The message integrity
   protection using HMAC defined in Section 4.4 of [RFC8762] can be used
   with the procedure described in this document.

   STAMP uses the well-known UDP port number that could become a target
   of denial of service (DoS) or could be used to aid on-path attacks.
   Thus, the security considerations and measures to mitigate the risk
   of the attack documented in Section 6 of [RFC8545] equally apply to
   the procedures described in this document.

   The procedures defined in this document is intended for deployment in
   a single network administrative domain.  As such, the Session-Sender
   address, Session-Reflector address, and forward and return paths are

Gandhi, et al.            Expires 5 August 2024                [Page 34]
Internet-Draft       Using STAMP for Segment Routing       February 2024

   provisioned by the operator for the STAMP session.  It is assumed
   that the operator has verified the integrity of the forward and
   return paths of the STAMP test packets.

   When using the procedures defined in [RFC6936], the security
   considerations specified in [RFC6936] also apply.

   The security considerations specified in [I-D.ietf-mpls-mna-hdr] are
   also applicable to the procedures for the SR-MPLS data plane defined
   in this document.

   SRv6 STAMP test packets can use the HMAC protection authentication
   defined for SRH in [RFC8754].

   The security considerations specified in [RFC8986] are also
   applicable to the procedures for the SRv6 data plane defined in this
   document.

14.  IANA Considerations

   This document does not require any IANA action.

15.  References

15.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,
              <https://www.rfc-editor.org/info/rfc768>.

   [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/info/rfc2119>.

   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
              RFC 6790, DOI 10.17487/RFC6790, November 2012,
              <https://www.rfc-editor.org/info/rfc6790>.

   [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/info/rfc8174>.

   [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/info/rfc8762>.

Gandhi, et al.            Expires 5 August 2024                [Page 35]
Internet-Draft       Using STAMP for Segment Routing       February 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/info/rfc8972>.

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

   [RFC9503]  Gandhi, R., Filsfils, C., Chen, M., Janssens, B., and R.
              Foote, "Simple Two-Way Active Measurement Protocol (STAMP)
              Extensions for Segment Routing Networks", RFC 9503,
              October 2023, <https://www.rfc-editor.org/info/rfc9503>.

   [RFC9534]  Li, Z., Zhou, T., Guo, J., Mirsky, G., and R. Gandhi,
              "Simple Two-Way Active Measurement Protocol Extensions for
              Performance Measurement on a Link Aggregation Group",
              RFC 9534, January 2024,
              <https://www.rfc-editor.org/info/rfc9534>.

   [I-D.ietf-mpls-mna-hdr]
              Rajamanickam, J., Ed., Gandhi, R., Ed., Zigler, R., Song,
              H., and K. Kompella, "MPLS Network Action Sub-Stack
              Solution", Work in Progress, Internet-Draft, draft-ietf-
              mpls-mna-hdr-04, October 2023,
              <https://www.ietf.org/archive/id/draft-ietf-mpls-mna-hdr-
              04.txt>.

15.2.  Informative References

   [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock
              Synchronization Protocol for Networked Measurement and
              Control Systems", March 2008.

   [RFC2113]  Katz, D., "IP Router Alert Option", RFC 2113,
              DOI 10.17487/RFC2113, February 1997,
              <https://www.rfc-editor.org/info/rfc2113>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

Gandhi, et al.            Expires 5 August 2024                [Page 36]
Internet-Draft       Using STAMP for Segment Routing       February 2024

   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
              Pignataro, "The Generalized TTL Security Mechanism
              (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
              <https://www.rfc-editor.org/info/rfc5082>.

   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
              "Bidirectional Forwarding Detection (BFD) for MPLS Label
              Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
              June 2010, <https://www.rfc-editor.org/info/rfc5884>.

   [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
              "IPv6 Flow Label Specification", RFC 6437,
              DOI 10.17487/RFC6437, November 2011,
              <https://www.rfc-editor.org/info/rfc6437>.

   [RFC6936]  Fairhurst, G. and M. Westerlund, "Applicability Statement
              for the Use of IPv6 UDP Datagrams with Zero Checksums",
              RFC 6936, DOI 10.17487/RFC6936, April 2013,
              <https://www.rfc-editor.org/info/rfc6936>.

   [RFC7404]  Behringer, M. and E. Vyncke, "Using Only Link-Local
              Addressing inside an IPv6 Network", RFC 7404,
              DOI 10.17487/RFC7404, November 2014,
              <https://www.rfc-editor.org/info/rfc7404>.

   [RFC7820]  Mizrahi, T., "UDP Checksum Complement in the One-Way
              Active Measurement Protocol (OWAMP) and Two-Way Active
              Measurement Protocol (TWAMP)", RFC 7820,
              DOI 10.17487/RFC7820, March 2016,
              <https://www.rfc-editor.org/info/rfc7820>.

   [RFC8029]  Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
              Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
              Switched (MPLS) Data-Plane Failures", RFC 8029,
              DOI 10.17487/RFC8029, March 2017,
              <https://www.rfc-editor.org/info/rfc8029>.

   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
              March 2017, <https://www.rfc-editor.org/info/rfc8085>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

Gandhi, et al.            Expires 5 August 2024                [Page 37]
Internet-Draft       Using STAMP for Segment Routing       February 2024

   [RFC8545]  Morton, A., Ed. and G. Mirsky, Ed., "Well-Known Port
              Assignments for the One-Way Active Measurement Protocol
              (OWAMP) and the Two-Way Active Measurement Protocol
              (TWAMP)", RFC 8545, DOI 10.17487/RFC8545, March 2019,
              <https://www.rfc-editor.org/info/rfc8545>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

   [RFC9256]  Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
              P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, July 2022,
              <https://www.rfc-editor.org/info/rfc9256>.

   [RFC9350]  Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
              and A. Gulko, "IGP Flexible Algorithm", RFC 9350, February
              2023, <https://www.rfc-editor.org/info/rfc9350>.

   [I-D.ietf-spring-sr-replication-segment]
              (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H.,
              and Z. Zhang, "SR Replication Segment for Multi-point
              Service Delivery", Work in Progress, Internet-Draft,
              draft-ietf-spring-sr-replication-segment-19, 28 August
              2023, <https://www.ietf.org/archive/id/draft-ietf-spring-
              sr-replication-segment-19.txt>.

   [I-D.ietf-pim-sr-p2mp-policy]
              (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H.,
              and Z. Zhang, "Segment Routing Point-to-Multipoint
              Policy", Work in Progress, Internet-Draft, draft-ietf-pim-
              sr-p2mp-policy-07, 11 October 2023,
              <https://www.ietf.org/archive/id/draft-ietf-pim-sr-p2mp-
              policy-07.txt>.

   [I-D.ietf-spring-mpls-path-segment]
              Cheng, W., Li, H., Li, C., Gandhi, R., and R. Zigler,
              "Path Segment in MPLS Based Segment Routing Network", Work
              in Progress, Internet-Draft, draft-ietf-spring-mpls-path-
              segment-22, 30 November 2023,
              <https://www.ietf.org/archive/id/draft-ietf-spring-mpls-
              path-segment-22.txt>.

   [I-D.ietf-spring-srv6-path-segment]
              Li, C., Cheng, W., Chen, M., Dhody, D., and Y. Zhu, "Path
              Segment for SRv6 (Segment Routing in IPv6)", Work in
              Progress, Internet-Draft, draft-ietf-spring-srv6-path-

Gandhi, et al.            Expires 5 August 2024                [Page 38]
Internet-Draft       Using STAMP for Segment Routing       February 2024

              segment-07, 19 October 2023,
              <https://www.ietf.org/archive/id/draft-ietf-spring-srv6-
              path-segment-07.txt>.

   [I-D.ietf-pce-sr-bidir-path]
              Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong,
              "Path Computation Element Communication Protocol (PCEP)
              Extensions for Associated Bidirectional Segment Routing
              (SR) Paths", Work in Progress, Internet-Draft, draft-ietf-
              pce-sr-bidir-path-12, 9 September 2023,
              <https://www.ietf.org/archive/id/draft-ietf-pce-sr-bidir-
              path-12.txt>.

   [I-D.ietf-ippm-stamp-yang]
              Mirsky, G., Min, X., Luo, W. S., and R. Gandhi, "Simple
              Two-way Active Measurement Protocol (STAMP) Data Model",
              Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-
              yang-12, 5 November 2023,
              <https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-
              yang-12.txt>.

   [I-D.mirsky-ippm-asymmetrical-pkts]
              Mirsky, G., Ruffini, E., and H. Nydell, "Performance
              Measurement with Asymmetrical Packets in STAMP", Work in
              Progress, Internet-Draft, draft-mirsky-ippm-asymmetrical-
              pkts-02, 20 October 2023,
              <https://www.ietf.org/archive/id/draft-mirsky-ippm-
              asymmetrical-pkts-02.txt>.

   [IEEE802.1AX]
              IEEE Std. 802.1AX, "IEEE Standard for Local and
              metropolitan area networks - Link Aggregation", November
              2008.

Acknowledgments

   The authors would like to thank Thierry Couture and Ianik Semco for
   the discussions on the use-cases for Performance Measurement in
   Segment Routing.  The authors would also like to thank Greg Mirsky,
   Gyan Mishra, Xie Jingrong, and Mike Koldychev for reviewing this
   document and providing useful comments and suggestions.  Patrick
   Khordoc, Haowei Shi, Amila Tharaperiya Gamage, Pengyan Zhang, Ruby
   Lin and Radu Valceanu have helped improve the mechanisms described in
   this document.

Gandhi, et al.            Expires 5 August 2024                [Page 39]
Internet-Draft       Using STAMP for Segment Routing       February 2024

Contributors

   The following people have substantially contributed to this document:

   Bart Janssens
   Colt
   Email: Bart.Janssens@colt.net

   Navin Vaghamshi
   Reliance
   Email: Navin.Vaghamshi@ril.com

   Moses Nagarajah
   Telstra
   Email: Moses.Nagarajah@team.telstra.com

   Amit Dhamija
   Arrcus
   India
   Email: amitd@arrcus.com

Authors' Addresses

   Rakesh Gandhi (editor)
   Cisco Systems, Inc.
   Canada
   Email: rgandhi@cisco.com

   Clarence Filsfils
   Cisco Systems, Inc.
   Email: cfilsfil@cisco.com

   Daniel Voyer
   Bell Canada
   Email: daniel.voyer@bell.ca

   Mach(Guoyi) Chen
   Huawei
   Email: mach.chen@huawei.com

   Richard Foote
   Nokia
   Email: footer.foote@nokia.com

Gandhi, et al.            Expires 5 August 2024                [Page 40]