Skip to main content

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

Document Type Active Internet-Draft (spring WG)
Authors Rakesh Gandhi , Clarence Filsfils , Daniel Voyer , Mach Chen , Richard "Footer" Foote
Last updated 2024-08-02 (Latest revision 2024-04-24)
Replaces draft-gandhi-spring-stamp-srpm, draft-gandhi-spring-enhanced-srpm
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
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-15
SPRING Working Group                                      R. Gandhi, Ed.
Internet-Draft                                               C. Filsfils
Intended status: Informational                       Cisco Systems, Inc.
Expires: 26 October 2024                                        D. Voyer
                                                             Bell Canada
                                                                 M. Chen
                                                                  Huawei
                                                                R. Foote
                                                                   Nokia
                                                           24 April 2024

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

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, SR paths (including SR
   Policies and SR IGP Flexible Algorithm 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 26 October 2024.

Gandhi, et al.           Expires 26 October 2024                [Page 1]
Internet-Draft       Using STAMP for Segment Routing          April 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Two-Way Measurement Mode in SR Networks . . . . . . . . . . .   7
     4.1.  Example STAMP Reference Model . . . . . . . . . . . . . .   8
     4.2.  Session-Sender Test Packet  . . . . . . . . . . . . . . .   9
     4.3.  Session-Sender Test Packet for Links  . . . . . . . . . .  10
     4.4.  Session-Sender Test Packet for SR-MPLS Data Plane . . . .  10
       4.4.1.  Session-Sender Test Packet for SR-MPLS Paths  . . . .  10
       4.4.2.  Session-Sender Test Packet for Layer-3 Services over
               SR-MPLS Path  . . . . . . . . . . . . . . . . . . . .  12
       4.4.3.  Session-Sender Test Packet for Layer-2 Services over
               SR-MPLS Path  . . . . . . . . . . . . . . . . . . . .  13
     4.5.  Session-Sender Test Packet for SRv6 Data Plane  . . . . .  13
       4.5.1.  Session-Sender Test Packet for SRv6 Paths . . . . . .  13
       4.5.2.  Session-Sender Test Packet for Layer-3 Services over
               SRv6 Path . . . . . . . . . . . . . . . . . . . . . .  16
       4.5.3.  Session-Sender Test Packet for Layer-2 Services over
               SRv6 Path . . . . . . . . . . . . . . . . . . . . . .  19
     4.6.  Session-Reflector Test Packet . . . . . . . . . . . . . .  21
   5.  One-Way Measurement Mode in SR Networks . . . . . . . . . . .  23
     5.1.  Example STAMP Reference Model . . . . . . . . . . . . . .  23
   6.  Loopback Measurement Mode in SR Networks  . . . . . . . . . .  24
     6.1.  Loopback Measurement Mode STAMP Process . . . . . . . . .  25
     6.2.  Loopback Measurement Mode for Links . . . . . . . . . . .  26
     6.3.  Loopback Measurement Mode for SR-MPLS Data Plane  . . . .  26
       6.3.1.  Loopback Measurement Mode for SR-MPLS Paths . . . . .  27
       6.3.2.  Loopback Measurement Mode for Layer-3 Services over
               SR-MPLS Path  . . . . . . . . . . . . . . . . . . . .  28

Gandhi, et al.           Expires 26 October 2024                [Page 2]
Internet-Draft       Using STAMP for Segment Routing          April 2024

       6.3.3.  Loopback Measurement Mode for Layer-2 Services over
               SR-MPLS Path  . . . . . . . . . . . . . . . . . . . .  30
     6.4.  Loopback Measurement Mode for SRv6 Data Plane . . . . . .  31
       6.4.1.  Loopback Measurement Mode for SRv6 Paths  . . . . . .  31
       6.4.2.  Loopback Measurement Mode for Layer-3 Services over
               SRv6 Path . . . . . . . . . . . . . . . . . . . . . .  33
       6.4.3.  Loopback Measurement Mode for Layer-2 Services over
               SRv6 Path . . . . . . . . . . . . . . . . . . . . . .  36
   7.  Loopback Measurement Mode with Timestamp and Forward Function
           in SR Networks  . . . . . . . . . . . . . . . . . . . . .  37
     7.1.  Loopback Measurement Mode with Timestamp and Forward
           Function for SR-MPLS Data Plane . . . . . . . . . . . . .  38
       7.1.1.  Timestamp and Forward Network Action Assignment . . .  39
       7.1.2.  Node Capability for MNA Sub-Stack with Opcode
               MNA.TSF . . . . . . . . . . . . . . . . . . . . . . .  39
     7.2.  Loopback Measurement Mode with Timestamp and Forward
           Function for SRv6 Data Plane  . . . . . . . . . . . . . .  40
       7.2.1.  Timestamp and Forward Endpoint Function Assignment  .  42
       7.2.2.  Node Capability for Timestamp and Forward Endpoint
               Function  . . . . . . . . . . . . . . . . . . . . . .  42
   8.  Packet Loss Measurement in SR Networks  . . . . . . . . . . .  42
   9.  Direct Measurement in SR Networks . . . . . . . . . . . . . .  43
   10. ECMP Measurement in SR Networks . . . . . . . . . . . . . . .  43
   11. STAMP Session State . . . . . . . . . . . . . . . . . . . . .  44
   12. Additional STAMP Test Packet Processing Rules . . . . . . . .  44
     12.1.  TTL  . . . . . . . . . . . . . . . . . . . . . . . . . .  44
     12.2.  IPv6 Hop Limit . . . . . . . . . . . . . . . . . . . . .  44
     12.3.  Router Alert Option  . . . . . . . . . . . . . . . . . .  45
     12.4.  IPv6 Flow Label  . . . . . . . . . . . . . . . . . . . .  45
     12.5.  UDP Checksum . . . . . . . . . . . . . . . . . . . . . .  45
   13. Implementation Status . . . . . . . . . . . . . . . . . . . .  45
   14. Security Considerations . . . . . . . . . . . . . . . . . . .  46
   15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  46
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  46
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  46
     16.2.  Informative References . . . . . . . . . . . . . . . . .  48
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  50
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  51
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  51

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

Gandhi, et al.           Expires 26 October 2024                [Page 3]
Internet-Draft       Using STAMP for Segment Routing          April 2024

   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, SR paths [RFC8402] (including
   SR Policies [RFC9256] and SR IGP Flexible Algorithm (Flex-Algo) 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 STAMP
   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 STAMP sessions and the
   interval for measurement of SR paths, for both SR-MPLS and SRv6 data
   planes by defining new measurement modes, one-way, loopback, and
   loopback with "timestamp and forward network programming function".

2.  Conventions Used in This Document

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.

Gandhi, et al.           Expires 26 October 2024                [Page 4]
Internet-Draft       Using STAMP for Segment Routing          April 2024

   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.

   TSF: Timestamp and Forward.

   TTL: Time-To-Live.

   VPN: Virtual Private Network.

3.  Overview

   For performance measurement in SR networks, the STAMP Session-Sender
   and Session-Reflector can use the base STAMP 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 [RFC8762].
   In this document, the STAMP test packets using IP/UDP header are used

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

   for SR networks, where the STAMP test packets are further
   encapsulated with an SR-MPLS header or IPv6 Segment Routing Header
   (IPv6/SRH).

   The STAMP test packets are transmitted in performance measurement
   mode of two-way, one-way, loopback, or loopback with "timestamp and
   forward network programming function" in SR networks.  Note that two-
   way measurement mode is referred to in STAMP process in [RFC8762] and
   is further described for SR networks in this document.  The other
   measurement modes are new, described for SR networks in this
   document, are not defined by the STAMP process in [RFC8762].

   The STAMP test packets are transmitted on the same path as the data
   traffic flow under measurement to measure delay and packet loss
   experienced by the data traffic flow by using the same SR
   encapsulation as the data traffic flow.  The STAMP test packets carry
   the same SR-MPLS and IPv6/SRH headers as the data packets transmitted
   on the SR path and on the L3 and L2 service for the traffic flow
   under measurement.

   Typically, STAMP reply test packets are transmitted along an IP path
   between Session-Reflector and Session-Sender.  Matching forward
   direction path and return path 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, for example, in an ECMP environment.
   This is achieved by using the optional STAMP extensions for SR-MPLS
   and SRv6 networks specified in [RFC9503] in two-way measurement mode.
   The STAMP Session-Reflector uses the return path parameters for the
   reply test packet from the STAMP extensions in the received Session-
   Sender test packet, as described in [RFC9503].  In case of loopback
   measurement mode, this is achieved by adding both forward direction
   path and return path in the SR-MPLS and IPv6/SRH encapsulation of the
   STAMP Session-Sender test packets.

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

Gandhi, et al.           Expires 26 October 2024                [Page 6]
Internet-Draft       Using STAMP for Segment Routing          April 2024

4.  Two-Way Measurement Mode in SR Networks

   As shown in Figure 1, Reference Topology for two-way measurement
   mode, the STAMP Session-Sender S1 initiates a STAMP Session-Sender
   test packet and the STAMP Session-Reflector R1 generates and
   transmits a reply test packet.  The reply 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.  All four timestamps are used by Session-
   Sender to measure round-trip delay as ((T4 - T1) - (T3 - T2)).
   Timestamps T1 and T2 are used by the Session-Sender to measure one-
   way delay as (T2 - T1), also referred to as near-end (forward
   direction) delay.  Note that the delay value (T4 - T3) measured by
   Session-Sender is referred to as far-end (backward direction) one-way
   delay.

   The one-way delay requires the clocks on the Session-Sender and
   Session-Reflector to be synchronized.

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

          STAMP Session-Sender          STAMP Session-Reflector

         Figure 1: Reference Topology for Two-Way Measurement Mode

   The nodes S1 and R1 may be connected via a link or an SR path with
   SR-MPLS or SRv6 data plane [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 IGP Flex-Algo path [RFC9350].  A Layer-3
   (L3) and Layer-2 (L2) VPN service may be carried over the SR path.

Gandhi, et al.           Expires 26 October 2024                [Page 7]
Internet-Draft       Using STAMP for Segment Routing          April 2024

4.1.  Example STAMP Reference Model

   An example STAMP Reference Model defined in [RFC8972] with some of
   the typical measurement parameters for a STAMP session is shown in
   Figure 2.

                               +------------+
                               |    SDN     |
                               | Controller |
                               +------------+
                                    /  \
     Performance Measurement Mode  /    \         Stateful or Stateless
     Destination UDP Port         /      \        Destination UDP Port
     Authentication Mode         /        \       Authentication Mode
         Keychain               /          \          Keychain
     Timestamp Format          /            \     Timestamp Format
     Metric Type              /              \
     SSID                    /                \
                            v                  v
                        +-------+          +-------+
                        |       |  STAMP   |       |
                        |   S1  |==========|   R1  |
                        |       |  Session |       |
                        +-------+          +-------+

                  STAMP Session-Sender  STAMP Session-Reflector

                  Figure 2: Example STAMP Reference Model

   The Performance Measurement mode is two-way in this example.

   The Destination UDP port number is selected for STAMP function as
   described in [RFC8762].  By default, Destination UDP port 862 is
   selected for STAMP sessions [RFC8762] for links, SR paths, and L3 and
   L2 services.

   The Source UDP port is chosen by the Session-Sender.  The same or
   different Source UDP port can be chosen for different STAMP sessions.

   Session-Reflector mode can be Stateful or Stateless as described in
   Section 4 of [RFC8762].  Stateless mode may be desired in two-way
   measurement mode.

   The SSID field in the STAMP test packets [RFC8972], and local
   configuration are used to identify the STAMP sessions that use two-
   way measurement mode.

Gandhi, et al.           Expires 26 October 2024                [Page 8]
Internet-Draft       Using STAMP for Segment Routing          April 2024

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

   Examples of the Timestamp Format is 64-bit truncated Precision Time
   Protocol (PTPv2) [IEEE.1588] and 64-bit Network Time Protocol (NTP)
   [RFC5905].  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] and it can be based on the Session-Reflector capability.

   Examples of Delay Metric Type are one-way delay, round-trip delay,
   near-end (forward direction) and far-end (backward direction) delay
   as defined in [RFC8762].

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

   A Software-Defined Networking (SDN) controller can be used for
   configuration and management of STAMP sessions as described in
   [RFC8762].  The controller can also receive streaming telemetry of
   operational data.  The YANG data model for STAMP defined in
   [I-D.ietf-ippm-stamp-yang] can be used to configure Session-Senders
   and Session-Reflectors and to stream telemetry of operational data.

4.2.  Session-Sender Test Packet

   The content of an example Session-Sender test packet transmitted is
   shown in Figure 3.  The payload containing the Session-Sender test
   packet, as defined in Section 3 of [RFC8972], is transmitted with IP
   and UDP header [RFC0768].

Gandhi, et al.           Expires 26 October 2024                [Page 9]
Internet-Draft       Using STAMP for Segment Routing          April 2024

    +---------------------------------------------------------------+
    | 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 = Chosen by Session-Sender                       .
    .  Destination Port = User-configured Destination Port | 862    .
    .                                                               .
    +---------------------------------------------------------------+
    | Payload = Test Packet as specified in Section 3 of RFC 8972   |
    .           in Figures 1 and 3                                  .
    .                                                               .
    +---------------------------------------------------------------+

                Figure 3: Example Session-Sender Test Packet

4.3.  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
   local 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] can be used to identify the member link.

4.4.  Session-Sender Test Packet for SR-MPLS Data Plane

4.4.1.  Session-Sender Test Packet for SR-MPLS Paths

   An SR-MPLS path may be an SR-MPLS Policy [RFC9256] or SR-MPLS IGP
   Flex-Algo path [RFC9350].

Gandhi, et al.           Expires 26 October 2024               [Page 10]
Internet-Draft       Using STAMP for Segment Routing          April 2024

   A Candidate-Path of an SR-MPLS Policy can contain one or more Segment
   Lists.  The Session-Sender test packets MUST be transmitted using
   each Segment List of the Candidate-Path of the SR-MPLS Policy for
   delay measurement.

   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.

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

    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] (top of stack)  | 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.

   In case of Penultimate Hop Popping (PHP), the MPLS header is removed
   by the penultimate node.  In this case, the Destination Address in
   the IP header ensures that the test packets reach the Session-
   Reflector on the SR-MPLS Policy endpoint.

   In 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

Gandhi, et al.           Expires 26 October 2024               [Page 11]
Internet-Draft       Using STAMP for Segment Routing          April 2024

   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
   SR Policy endpoint (for example, by adding the Prefix SID label of
   the SR-MPLS Policy endpoint in the Segment List).

   The Path Segment Identifier (PSID) [RFC9545] 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, and can be used for direct
   measurement as described in Section 9, "Direct Measurement in SR
   Networks".

   Each IGP Flex-Algo in SR-MPLS networks [RFC9350] has Prefix SID
   labels advertised by the nodes.  For delay measurement of SR-MPLS IGP
   Flex-Algo paths, the Session-Sender test packets carry the Flex-Algo
   Prefix SID label(s) of the Session-Sender and Session-Reflector in
   the MPLS header for that IGP Flex-Algo path under measurement.

4.4.2.  Session-Sender Test Packet for Layer-3 Services over SR-MPLS
        Path

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

    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] (top of stack)  | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            L3VPN Segment              | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Test Packet as shown in Figure 3                   |
    .            Destination IP Address in L3VPN table              .
    .            Source IP Address in L3VPN table(reverse direction).
    .                                                               .
    +---------------------------------------------------------------+

      Figure 5: Example Session-Sender Test Packet for L3 Service over
                                SR-MPLS Path

   An IP header as shown in Figure 3 is added in the Session-Sender test
   packets after the SR-MPLS encapsulation.  The Destination Address
   added in the IP header MUST be reachable via the IP table lookup

Gandhi, et al.           Expires 26 October 2024               [Page 12]
Internet-Draft       Using STAMP for Segment Routing          April 2024

   associated with the L3VPN label added for the L3 service on the
   Session-Reflector.  The Source Address added in the IP header of the
   Session-Sender test packets MUST be reachable via the IP table lookup
   associated with the L3 service in the reverse direction.

4.4.3.  Session-Sender Test Packet for Layer-2 Services over SR-MPLS
        Path

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

    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] (top of stack)  | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            L2VPN Segment              | TC  |1|      TTL=1    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Test Packet as shown in Figure 3                   |
    .                                                               .
    +---------------------------------------------------------------+

      Figure 6: Example Session-Sender Test Packet for L2 Service over
                                SR-MPLS Path

   The L2VPN 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.

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

4.5.  Session-Sender Test Packet for SRv6 Data Plane

4.5.1.  Session-Sender Test Packet for SRv6 Paths

   An SRv6 path may be an SRv6 Policy [RFC9256] or SRv6 IGP Flex-Algo
   path [RFC9350].

Gandhi, et al.           Expires 26 October 2024               [Page 13]
Internet-Draft       Using STAMP for Segment Routing          April 2024

   A Candidate-Path of an SRv6 Policy can contain one or more Segment
   Lists.  The Session-Sender test packets MUST be transmitted using
   each Segment List of the Candidate-Path of the SRv6 Policy for delay
   measurement.

   The Segment Lists contain a number of SRv6 SIDs as defined in
   [RFC8986].  The Session-Sender test packets contain an IPv6 header
   and SRv6 Segment Routing Header (SRH) carrying Segment List as
   described in [RFC8754].

   The content of an example Session-Sender test packet for an SRv6 path
   using the same IPv6/SRH encapsulation as the data traffic transmitted
   over the path is shown in Figure 7.  The IPv6/SRH encapsulation can
   be encoded in Insert-Mode or Encaps-Mode.  In Insert-Mode, an SRH is
   inserted after the IPv6 header of the test packets as shown in
   Example 1 of Figure 7.  In Encaps-Mode, the test packets are
   encapsulated in an outer IPv6 header with an SRH as shown in Example
   2 of Figure 7.

    +---------------------------------------------------------------+
    | IPv6 Header                                                   |
    .  Source IP Address = Session-Sender IPv6 Address              .
    .  Destination IP Address = Segment List[Segments Left]         .
    .  Next-Header = 43, Routing Type = SRH (4)                     .
    .                                                               .
    +---------------------------------------------------------------+
    | SRH                                                           |
    .  Segment List[0] = Session-Reflector IPv6 Address or          .
    .                    Last Segment of Segment List or            .
    .                    Optional PSID                              .
    .  <Remained Segment List of Forward Path>                      .
    .  Next-Header = UDP (17)                                       .
    .                                                               .
    +---------------------------------------------------------------+
    | UDP Header as shown in Figure 3                               |
    .                                                               .
    +---------------------------------------------------------------+
    | Payload as shown in Figure 3                                  |
    .                                                               .
    +---------------------------------------------------------------+

              Example 1: Using Insert-Mode Encoding

    +---------------------------------------------------------------+
    | IPv6 Header                                                   |
    .  Source IP Address = Session-Sender IPv6 Address              .
    .  Destination IP Address = Segment List[Segments Left]         .
    .  Next-Header = 43, Routing Type = SRH (4)                     .

Gandhi, et al.           Expires 26 October 2024               [Page 14]
Internet-Draft       Using STAMP for Segment Routing          April 2024

    .                                                               .
    +---------------------------------------------------------------+
    | SRH                                                           |
    .  Segment List[0] = Session-Reflector IPv6 Address or          .
    .                    Last Segment of Segment List or            .
    .                    Optional PSID                              .
    .  <Remained Segment List of Forward Path>                      .
    .  Next-Header = 43 (IPv6) or 4 (IPv4)                          .
    .                                                               .
    +---------------------------------------------------------------+
    | IP Header as shown in Figure 3                                |
    .                                                               .
    +---------------------------------------------------------------+
    | UDP Header as shown in Figure 3                               |
    .                                                               .
    +---------------------------------------------------------------+
    | Payload as shown in Figure 3                                  |
    .                                                               .
    +---------------------------------------------------------------+

              Example 2: Using Encaps-Mode Encoding

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

   In outer IPv6/SRH header, the head-end node address of the SRv6
   Policy MUST be used as the Source Address and the next Segment in the
   Segment List is used as the Destination Address.  When Segment List
   of the Candidate-Path of the SRv6 Policy is empty, the endpoint
   address of the SRv6 Policy is added as the Destination Address.

   In Encaps-Mode for IPv6, an inner IPv6 header added MUST contain the
   endpoint address of the SRv6 Policy as the Destination Address and
   the head-end node address of the SRv6 Policy as the Source Address.
   In case of SRv6 Policy with Color-Only Destination Steering, with
   endpoint as unspecified address (the null endpoint :: for IPv6 (all
   bits set to the 0 value)) as defined in Section 8.8.1 of [RFC9256],
   the loopback address ::1/128 for IPv6 [RFC4291] can be used as the
   Destination Address in the inner IPv6 header of the Session-Sender
   test packets.  In this case, the Session-Sender MUST ensure that the
   Session-Sender test packets using the Segment List reach the Session-
   Reflector on the SRv6 Policy endpoint (for example, by adding the
   Prefix SID or the IPv6 address of the SRv6 Policy endpoint in the
   Segment List).

Gandhi, et al.           Expires 26 October 2024               [Page 15]
Internet-Draft       Using STAMP for Segment Routing          April 2024

   In case of Penultimate Segment Popping (PSP), the IPv6/SRH
   encapsulation is removed by the penultimate node.  In Insert-Mode,
   the Session-Sender MUST ensure that the Session-Sender test packets
   using the Segment List reach the Session-Reflector on the SRv6 Policy
   endpoint (for example, by adding the Prefix SID or the IPv6 address
   of the SRv6 Policy endpoint in the Segment List).

   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] is used to process the 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 and can be used for direct measurement as
   described in Section 9, "Direct Measurement in SR Networks".

   Each IGP Flex-Algo in SRv6 networks [RFC9350] has Prefix SIDs
   advertised by the nodes.  For delay measurement of SRv6 IGP Flex-Algo
   paths, the Session-Sender test packets carry the SRv6 Flex-Algo
   Prefix SIDs of the Session-Sender and Session-Reflector as the Source
   Address and Destination Address in the IPv6 header, respectively, for
   that SRv6 IGP Flex-Algo path under measurement.

4.5.2.  Session-Sender Test Packet for Layer-3 Services over SRv6 Path

   For delay measurement of L3 service over SRv6 path, the same IPv6/SRH
   encapsulation as the data packets transmitted over the L3 service
   including the L3VPN SRv6 SID instantiated on the Session-Reflector
   (for example, End.DT6 SID instance, End.DT4 SID instance, End.DT46
   instance, defined in [RFC8986]) is used to transmit Session-Sender
   test packets as shown in Figure 8 for both encoding modes, Insert-
   Mode and Encaps-Mode.

    +---------------------------------------------------------------+
    | IPv6 Header                                                   |
    .  Source IP Address = Session-Sender IPv6 Address              .
    .                      in L3VPN table (reverse direction)       .
    .  Destination IP Address = Segment List[Segments Left]         .
    .  Next-Header = 43, Routing Type = SRH (4)                     .
    .                                                               .
    +---------------------------------------------------------------+
    | SRH                                                           |
    .  Segment List[0] = End.DT6/End.DT46 SID                       .
    .  <Remained Segment List of Forward Path>                      .
    .  Next-Header = UDP (17)                                       .
    .                                                               .

Gandhi, et al.           Expires 26 October 2024               [Page 16]
Internet-Draft       Using STAMP for Segment Routing          April 2024

    +---------------------------------------------------------------+
    | UDP Header as shown in Figure 3                               |
    .                                                               .
    +---------------------------------------------------------------+
    | Payload as shown in Figure 3                                  |
    .                                                               .
    +---------------------------------------------------------------+

              Example 1: Using Insert-Mode Encoding

    +---------------------------------------------------------------+
    | IPv6 Header                                                   |
    .  Source IP Address = Session-Sender IPv6 Address              .
    .  Destination IP Address = Segment List[Segments Left]         .
    .  Next-Header = 43, Routing Type = SRH (4)                     .
    .                                                               .
    +---------------------------------------------------------------+
    | SRH                                                           |
    .  Segment List[0] = End.DT4/End.DT46 SID                       .
    .  <Remained Segment List of Forward Path>                      .
    .  Next-Header = 4 (IPv4)                                       .
    .                                                               .
    +---------------------------------------------------------------+
    | IPv4 Header as shown in Figure 3                              |
    .      Destination IPv4 Address in L3VPN table                  .
    .      Source IPv4 Address in L3VPN table (reverse direction)   .
    .                                                               .
    +---------------------------------------------------------------+
    | UDP Header as shown in Figure 3                               |
    .                                                               .
    +---------------------------------------------------------------+
    | Payload as shown in Figure 3                                  |
    .                                                               .
    +---------------------------------------------------------------+

              Example 2: Using Encaps-Mode Encoding for IPv4

    +---------------------------------------------------------------+
    | IPv6 Header                                                   |
    .  Source IP Address = Session-Sender IPv6 Address              .
    .  Destination IP Address = Segment List[Segments Left]         .
    .  Next-Header = 43, Routing Type = SRH (4)                     .
    .                                                               .
    +---------------------------------------------------------------+
    | SRH                                                           |
    .  Segment List[0] = End.DT6/End.DT46 SID                       .
    .  <Remained Segment List of Forward Path>                      .
    .  Next-Header = 43 (IPv6)                                      .

Gandhi, et al.           Expires 26 October 2024               [Page 17]
Internet-Draft       Using STAMP for Segment Routing          April 2024

    .                                                               .
    +---------------------------------------------------------------+
    | IPv6 Header as shown in Figure 3                              |
    .      Destination IPv6 Address in L3VPN table                  .
    .      Source IPv6 Address in L3VPN table (reverse direction)   .
    .                                                               .
    +---------------------------------------------------------------+
    | UDP Header as shown in Figure 3                               |
    .                                                               .
    +---------------------------------------------------------------+
    | Payload as shown in Figure 3                                  |
    .                                                               .
    +---------------------------------------------------------------+

              Example 3: Using Encaps-Mode Encoding for IPv6

      Figure 8: Example Session-Sender Test Packet for L3 Service over
                                 SRv6 Path

   In Insert-Mode, an SRH is inserted after the IPv6 header of the STAMP
   test packets as shown in Example 1 of Figure 8.  The IPv6 Source
   Address added in the IPv6 header MUST be reachable via the IPv6 table
   lookup for the L3 service in the reverse direction in case of End.DT6
   and End.DT46 SIDs to return the reply test packets over that L3
   service.

   In Encaps-Mode, the STAMP test packets are encapsulated in outer IPv6
   header with an SRH as shown in Examples 2 and 3 of Figure 8.  An
   inner IP header is added in the Session-Sender test packets after the
   IPv6/SRH encapsulation.

   The IPv6 Destination Address added in the inner IPv6 header MUST be
   reachable via the IPv6 table lookup associated with the L3VPN SRv6
   SID added.  Similarly, the IPv4 Destination Address added in the
   inner IPv4 header MUST be reachable via the IPv4 table lookup
   associated with the L3VPN SRv6 SID added.

   The IPv6 Source Address added in the inner IPv6 header MUST be
   reachable via the IPv6 table lookup for the L3 service in the reverse
   direction to return the reply test packets over that L3 service.
   Similarly, the IPv4 Source Address added in the inner IPv4 header
   MUST be reachable via the IPv4 table lookup for the L3 service in the
   reverse direction.

Gandhi, et al.           Expires 26 October 2024               [Page 18]
Internet-Draft       Using STAMP for Segment Routing          April 2024

4.5.3.  Session-Sender Test Packet for Layer-2 Services over SRv6 Path

   For delay measurement of L2 service over SRv6 path, the same IPv6/SRH
   encapsulation as the data packets transmitted over 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 as shown in Figure 9 for both
   encoding modes, Insert-Mode and Encaps-Mode.

Gandhi, et al.           Expires 26 October 2024               [Page 19]
Internet-Draft       Using STAMP for Segment Routing          April 2024

    +---------------------------------------------------------------+
    | IPv6 Header                                                   |
    .  Source IP Address = Session-Sender IPv6 Address              .
    .  Destination IP Address = Segment List[Segments Left]         .
    .  Next-Header = 43, Routing Type = SRH (4)                     .
    .                                                               .
    +---------------------------------------------------------------+
    | SRH                                                           |
    .  Segment List[0] = End.DT2U SID                               .
    .  <Remained Segment List of Forward Path>                      .
    .  Next-Header = UDP (17)                                       .
    .                                                               .
    +---------------------------------------------------------------+
    | UDP Header as shown in Figure 3                               |
    .                                                               .
    +---------------------------------------------------------------+
    | Payload as shown in Figure 3                                  |
    .                                                               .
    +---------------------------------------------------------------+

              Example 1: Using Insert-Mode Encoding

    +---------------------------------------------------------------+
    | IPv6 Header                                                   |
    .  Source IP Address = Session-Sender IPv6 Address              .
    .  Destination IP Address = Segment List[Segments Left]         .
    .  Next-Header = 43, Routing Type = SRH (4)                     .
    .                                                               .
    +---------------------------------------------------------------+
    | SRH                                                           |
    .  Segment List[0] = End.DT2U SID                               .
    .  <Remained Segment List of Forward Path>                      .
    .  Next-Header = 43 (IPv6)                                      .
    .                                                               .
    +---------------------------------------------------------------+
    | IPv6 Header as shown in Figure 3                              |
    .  Hop Limit = 1                                                .
    .                                                               .
    +---------------------------------------------------------------+
    | UDP Header as shown in Figure 3                               |
    .                                                               .
    +---------------------------------------------------------------+
    | Payload as shown in Figure 3                                  |
    .                                                               .
    +---------------------------------------------------------------+

              Example 2: Using Encaps-Mode Encoding

Gandhi, et al.           Expires 26 October 2024               [Page 20]
Internet-Draft       Using STAMP for Segment Routing          April 2024

      Figure 9: Example Session-Sender Test Packet for L2 Service over
                                 SRv6 Path

   In both encoding modes, the Session-Sender address is added as the
   Source Address and Session-Reflector address is added as the
   Destination Address in the outer IPv6 header.

   In Insert-Mode, an SRH is inserted after the IPv6 header of the STAMP
   test packets as shown in Example 1 of Figure 9.

   In Encaps-Mode, in addition to the outer IPv6/SRH encapsulation, an
   inner IPv6 header is added as shown in Example 2 of Figure 9, with
   Hop Limit value of 1 in order to punt the Session-Sender test packets
   from data plane to CPU or slow path on Session-Reflector for STAMP
   processing.  The inner IPv6 header contains the Session-Sender
   Address as the Source Address and the Session-Reflector Address as
   the Destination Address.

4.6.  Session-Reflector Test Packet

   In two-way measurement mode, reply test packets are transmitted by
   the Session-Reflector on the same or different path in the reverse
   direction for the STAMP sessions for links, SR paths and L3 and L2
   services.  It may be desired that the Session-Reflector test packets
   are transmitted on the return path that is same as the forward
   direction path in SR networks.

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

Gandhi, et al.           Expires 26 October 2024               [Page 21]
Internet-Draft       Using STAMP for Segment Routing          April 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 Figures 2 and 4                                  .
    .                                                               .
    +---------------------------------------------------------------+

              Figure 10: Example Session-Reflector Test Packet

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

   For links, the Session-Sender may request in the test packet to the
   Session-Reflector to transmit the reply test packet on the same link
   in the reverse direction.  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.

   For SR paths, the Session-Sender may request in the test packet to
   the Session-Reflector to transmit the reply test packet on a specific
   SR return path.  For example, reverse SR path associated with the
   forward direction SR path [I-D.ietf-pce-sr-bidir-path] or the Binding
   SID of the reverse SR Policy or the Prefix SID of the Session-Sender.
   It can use Segment List sub-TLV in the Return Path TLV defined in
   [RFC9503] for this request.

   For SR IGP Flex-Algo paths, the Session-Sender may request in the
   test packet to the Session-Reflector to transmit the reply test
   packet on the same SR IGP Flex-Algo path in the reverse direction
   using Segment List sub-TLV in the Return Path TLV defined in
   [RFC9503].

Gandhi, et al.           Expires 26 October 2024               [Page 22]
Internet-Draft       Using STAMP for Segment Routing          April 2024

   For L3 services, the Session-Reflector can derive the L3 service in
   the reverse direction using the L3VPN SID received in the Session-
   Sender test packets to transmit the Session-Reflector test packets.

   For L2 services, the Session-Reflector can derive the L2 service in
   the reverse direction using the L2VPN SID received in the Session-
   Sender test packets to transmit the Session-Reflector test packets.

5.  One-Way Measurement Mode in SR Networks

   As shown in Figure 11, Reference Topology for one-way measurement
   mode, the STAMP Session-Sender S1 initiates a Session-Sender test
   packet.  The STAMP Session-Reflector does not generate and transmit
   reply test packets upon receiving Session-Sender test packets.

   The T1 is a transmit timestamp added by node S1, T2 is a receive
   timestamp added by node R1.  Timestamps T1 and T2 are used by the
   Session-Reflector to measure one-way delay as (T2 - T1).

   The one-way delay requires the clocks on the Session-Sender and
   Session-Reflector to be synchronized.

                          T1                T2
                         /                   \
                +-------+     Test Packet     +-------+
                |       | - - - - - - - - - ->|       |
                |   S1  |=====================|   R1  |
                |       |                     |       |
                +-------+                     +-------+

          STAMP Session-Sender          STAMP Session-Reflector

         Figure 11: Reference Topology for One-Way Measurement Mode

5.1.  Example STAMP Reference Model

   In one-way measurement mode, Session-Sender test packets defined in
   Section 4 for STAMP sessions for links, SR paths, and L3 and L2
   services are transmitted.  The Session-Sender can request in the test
   packets to the Session-Reflector to not transmit reply test packets
   using the "No Reply Requested" flag in the Control Code Sub-TLV in
   the Return Path TLV defined in [RFC9503].

   A Destination UDP port can be selected for one-way measurement mode,
   different than the Destination UDP port selected for two-way
   measurement mode, to not generate and transmit reply test packets.
   By default, the Destination UDP port 861 [RFC4656] is used in one-way
   measurement mode.

Gandhi, et al.           Expires 26 October 2024               [Page 23]
Internet-Draft       Using STAMP for Segment Routing          April 2024

   Stateful mode of Session-Reflector [RFC8762] may be desired in one-
   way measurement mode.

   The SSID field in the received Session-Sender test packets, and local
   configuration are used to identify the STAMP sessions that use one-
   way measurement mode on Session-Sender and Session-Reflector.

6.  Loopback Measurement Mode in SR Networks

   As shown in Figure 12, Reference Topology for loopback measurement
   mode, STAMP Session-Sender S1 initiates a Session-Sender test packet
   to measure loopback delay of a bidirectional circular path.  At STAMP
   Session-Reflector, 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) but simply forwarded.  In other words, the Session-
   Reflector does not perform STAMP functions and generate Session-
   Reflector test packets.

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

          STAMP Session-Sender          STAMP Session-Reflector
                                              (Loopback,
                                               Forward)

        Figure 12: Reference Topology for Loopback Measurement Mode

   The Session-Sender retrieves the timestamp T1 from the received
   Session-Sender test packet and collects the receive timestamp T4
   locally.  Both timestamps T1 and T4 are used to measure 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 test packets and hence does not need timestamping
   capability.

Gandhi, et al.           Expires 26 October 2024               [Page 24]
Internet-Draft       Using STAMP for Segment Routing          April 2024

6.1.  Loopback Measurement Mode STAMP Process

   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 Destination UDP ports 862 and 861 which are used by the
   Session-Reflector).  The same UDP port can be used as Destination and
   Source UDP port in Session-Sender test packets as shown in Figure 13.

   The IP header for the return path in the Session-Sender test packets
   MUST set the Destination Address equal to the Session-Sender address
   as shown in Figure 13 to return the test packets to the Session-
   Sender.  The Session-Sender test packets are encapsulated with
   forward direction SR path and transmitted to Session-Reflector.

    +---------------------------------------------------------------+
    | 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 = Chosen by Session-Sender                       .
    .  Destination Port = Source Port                               .
    .                                                               .
    +---------------------------------------------------------------+
    | Payload = Test Packet as specified in Section 3 of RFC 8972   |
    .           in Figures 1 and 3                                  .
    .                                                               .
    +---------------------------------------------------------------+

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

   The Session-Reflector does not perform the STAMP process, as 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 SSID field in the received Session-
   Sender test packets, and local configuration to identify its STAMP
   sessions that use loopback measurement mode.

Gandhi, et al.           Expires 26 October 2024               [Page 25]
Internet-Draft       Using STAMP for Segment Routing          April 2024

   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
   Session-Sender test packets and MUST be ignored in the received test
   packets.

6.2.  Loopback Measurement Mode for Links

   The Session-Sender test packets in loopback measurement mode may be
   transmitted with a Layer-2 header for the forward direction path as
   shown in Figure 14, containing the link MAC address on the Session-
   Reflector as the Destination Address and the link MAC address on the
   Session-Sender as the Source MAC address for Ethernet links.

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

         Figure 14: Example Session-Sender Test Packet in Loopback
                     Measurement Mode for Ethernet Link

   An SR encapsulation (e.g., containing adjacency SID of the link) for
   the forward direction path can also be added after the Layer-2
   header.

   The IP header for the return path of the Session-Sender test packets
   is added and it MUST set the Source and Destination Address equal to
   the link address on the Session-Sender to return the test packet to
   the Session-Sender.

   The Session-Reflector decapsulates the L2 header and forwards the
   test packet using the IP header for the return path to the Session-
   Sender.

6.3.  Loopback Measurement Mode for SR-MPLS Data Plane

Gandhi, et al.           Expires 26 October 2024               [Page 26]
Internet-Draft       Using STAMP for Segment Routing          April 2024

6.3.1.  Loopback Measurement Mode for SR-MPLS Paths

   In loopback measurement mode for SR-MPLS paths, the Session-Sender
   test packet can carry either the Segment List of the forward
   direction path only or both the forward direction and the return
   paths in MPLS header as shown in Figure 15.

    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] (top of stack)  | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Segment[n]                 | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            PSID (optional)            | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Test Packet as shown in Figure 13 (Return Path)    |
    .                                                               .
    +---------------------------------------------------------------+

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

   An SR-MPLS path may be an SR-MPLS Policy [RFC9256] or SR-MPLS IGP
   Flex-Algo path [RFC9350].

   In 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 label of
   the SR-MPLS Policy endpoint in the Segment List of the forward
   direction path).

   The IP header for the return path of the Session-Sender test packets
   is added and it MUST set the Destination Address equal to the
   Session-Sender address.

6.3.1.1.  SR-MPLS Return Path

   The Session-Sender test packets, in SR-MPLS label stack, carry return
   path, in addition to forward direction path.  For example, they can
   carry the SR-MPLS label stack of the Segment List of the associated
   reverse Candidate-Path [I-D.ietf-pce-sr-bidir-path] or the Binding
   SID label of the reverse SR-MPLS Policy or the SR-MPLS Prefix SID
   label of the Session-Sender.

Gandhi, et al.           Expires 26 October 2024               [Page 27]
Internet-Draft       Using STAMP for Segment Routing          April 2024

   For SR-MPLS IGP Flex-Algo paths, Session-Sender test packets can
   carry the SR-MPLS Prefix SID label of the Session-Sender for the same
   SR-MPLS IGP Flex-Algo in the reverse direction.

   In this case, the optional PSID is not added in the Session-Sender
   test packet.

6.3.1.2.  IP Return Path

   The Session-Sender test packets in MPLS header carry the SR-MPLS
   label stack of the forward direction path only.

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

   In this case, the optional PSID added in the Session-Sender test
   packet is for the SR-MPLS forward direction path and is allocated by
   the Session-Reflector.

6.3.2.  Loopback Measurement Mode for Layer-3 Services over SR-MPLS Path

   In loopback measurement mode for L3 service over SR-MPLS path, the
   SR-MPLS label stack of the data packets transmitted over the L3
   service is used to transmit Session-Sender test packets as shown in
   Figure 16.

Gandhi, et al.           Expires 26 October 2024               [Page 28]
Internet-Draft       Using STAMP for Segment Routing          April 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] (top of stack)  | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            L3VPN Segment (Return Path)| TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Test Packet as shown in Figure 13 (Return Path)    |
    .            Destination IP Address in L3VPN table              .
    .                                                               .
    +---------------------------------------------------------------+

                 Example 1: Using SR-MPLS Return Path

    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] (top of stack)  | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            L3VPN Segment(Forward Path)| TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Test Packet as shown in Figure 13 (Return Path)    |
    .            Destination IP Address in L3VPN table              .
    .                                                               .
    +---------------------------------------------------------------+

                 Example 2: Using IP Return Path

         Figure 16: Example Session-Sender Test Packet in Loopback
             Measurement Mode for L3 Service over SR-MPLS Path

   The IP header for the return path of the Session-Sender test packets
   is added and it MUST set the Destination Address equal to the
   Session-Sender address.  The Destination Address added in the IP
   header for the return path MUST be reachable via the IP table lookup
   associated with the L3VPN label added in the test packets.

Gandhi, et al.           Expires 26 October 2024               [Page 29]
Internet-Draft       Using STAMP for Segment Routing          April 2024

6.3.2.1.  SR-MPLS Return Path

   The SR-MPLS label stack except the L3VPN label (advertised by the
   Session-Reflector) of the forward direction L3 service is added in
   the Session-Sender test packets.  In addition, the SR-MPLS label
   stack including the L3VPN label for the reverse direction L3 service
   is also added in the Session-Sender test packets.

6.3.2.2.  IP Return Path

   The SR-MPLS label stack including the L3VPN label (advertised by the
   Session-Reflector) of the forward direction L3 service is added in
   the Session-Sender test packets.

   The Session-Reflector decapsulates the MPLS header and forwards the
   Session-Sender test packet using the IP header for the return path
   (after adding SR-MPLS encapsulation for the reverse direction L3
   service).

6.3.3.  Loopback Measurement Mode for Layer-2 Services over SR-MPLS Path

   In loopback measurement mode for L2 service over SR-MPLS path, the
   SR-MPLS label stack of the data packets transmitted over the L2
   service is used to transmit Session-Sender test packets as shown in
   Figure 17.

    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] (top of stack)  | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            L2VPN Segment (Return Path)| TC  |1|      TTL=1    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Test Packet as shown in Figure 13 (Return Path)    |
    .                                                               .
    +---------------------------------------------------------------+

                 Example: Using SR-MPLS Return Path

         Figure 17: Example Session-Sender Test Packet in Loopback
             Measurement Mode for L2 Service over SR-MPLS Path

   The IP header for the return path MUST be added in the Session-Sender
   test packets that has the Destination Address equal to the Session-
   Sender address.

Gandhi, et al.           Expires 26 October 2024               [Page 30]
Internet-Draft       Using STAMP for Segment Routing          April 2024

6.3.3.1.  SR-MPLS Return Path

   The SR-MPLS label stack except the L2VPN label (advertised by the
   Session-Reflector) of the forward direction L2 service is added in
   Session-Sender the test packets.  In addition, the SR-MPLS label
   stack including the L2VPN label for the reverse direction L2 service
   is added the Session-Sender test packet with a TTL value of 1 in
   order to punt the test packet from data plane to CPU or slow path on
   Session-Sender for STAMP processing.

6.3.3.2.  IP Return Path

   The STAMP test packets without using SR-MPLS return path is outside
   the scope of this document.

6.4.  Loopback Measurement Mode for SRv6 Data Plane

6.4.1.  Loopback Measurement Mode for SRv6 Paths

   In loopback measurement mode for SRv6 paths, the Session-Sender test
   packet can carry either the Segment List of the forward direction
   path only using Encaps-Mode encoding or both the forward direction
   and the return paths in IPv6/SRH using Insert-Mode encoding as shown
   in Figure 18.

    +---------------------------------------------------------------+
    | IPv6 Header                                                   |
    .  Source IP Address = Session-Sender IPv6 Address              .
    .  Destination IP Address = Segment List[Segments Left]         .
    .  Next-Header = 43, Routing Type = SRH (4)                     .
    .                                                               .
    +---------------------------------------------------------------+
    | SRH                                                           |
    .  Segment List[0] = Session-Sender IPv6 Address or             .
    .                    Last Segment of Segment List of Return Path.
    .  <Remained Segment List for Return Path>                      .
    .  <PSID (optional), Segment List for Forward Path>             .
    .  Next-Header = UDP (17)                                       .
    .                                                               .
    +---------------------------------------------------------------+
    | UDP Header as shown in Figure 13                              |
    .                                                               .
    +---------------------------------------------------------------+
    | Payload as shown in Figure 13                                 |
    .                                                               .
    +---------------------------------------------------------------+

       Example 1: Using Insert-Mode Encoding with SRv6 Return Path

Gandhi, et al.           Expires 26 October 2024               [Page 31]
Internet-Draft       Using STAMP for Segment Routing          April 2024

    +---------------------------------------------------------------+
    | IPv6 Header                                                   |
    .  Source IP Address = Session-Sender IPv6 Address              .
    .  Destination IP Address = Segment List[Segments Left]         .
    .  Next-Header = 43, Routing Type = SRH (4)                     .
    .                                                               .
    +---------------------------------------------------------------+
    | SRH                                                           |
    .  Segment List[0] = Session-Reflector IPv6 Address or          .
    .                    Last Segment of Segment List or            .
    .                    Optional PSID                              .
    .  <Remained Segment List of Forward Path>                      .
    .  Next-Header = 43 (IPv6) or 4 (IPv4)                          .
    .                                                               .
    +---------------------------------------------------------------+
    | IP Header as shown in Figure 13 (Return Path)                 |
    .                                                               .
    +---------------------------------------------------------------+
    | UDP Header as shown in Figure 13                              |
    .                                                               .
    +---------------------------------------------------------------+
    | Payload as shown in Figure 13                                 |
    .                                                               .
    +---------------------------------------------------------------+

       Example 2: Using Encaps-Mode Encoding with IP Return Path

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

   An SRv6 path may be an SRv6 Policy [RFC9256] or SRv6 IGP Flex-Algo
   path [RFC9350].

   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) in both encoding modes.

6.4.1.1.  SRv6 Return Path

   For SRv6 return path, the Session-Sender test packets are encoded in
   Insert-Mode as shown in Example 1 in Figure 18.

   The Session-Sender test packets, in SRv6 Segment List, carry return
   path, in addition to forward direction path.  For example, they can
   carry the Segment List of the associated reverse Candidate-Path
   [I-D.ietf-pce-sr-bidir-path] or the Binding SID of the reverse SRv6
   Policy or the SRv6 Prefix SID of the Session-Sender.

Gandhi, et al.           Expires 26 October 2024               [Page 32]
Internet-Draft       Using STAMP for Segment Routing          April 2024

   For SRv6 IGP Flex-Algo paths, the Session-Sender test packets can
   carry the SRv6 Prefix SID of the Session-Sender for the same IGP
   Flex-Algo in the reverse direction.

   In this case, the optional PSID is not added in the Session-Sender
   test packet.

6.4.1.2.  IP Return Path

   For IP return path, the Session-Sender test packets are encoded in
   Encaps-Mode as shown in Example 2 in Figure 18.

   The Session-Sender test packets carry the Segment List of the SRv6
   forward direction 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 to return the test packet to the Session-
   Sender.

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

   In this case, the optional PSID added in the Session-Sender test
   packet is for the SRv6 forward direction path and is allocated by the
   Session-Reflector.

6.4.2.  Loopback Measurement Mode for Layer-3 Services over SRv6 Path

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

    +---------------------------------------------------------------+
    | IPv6 Header                                                   |
    .  Source IP Address = Session-Sender IPv6 Address              .
    .  Destination IP Address = Segment List[Segments Left]         .
    .  Next-Header = 43, Routing Type = SRH (4)                     .
    .                                                               .
    +---------------------------------------------------------------+
    | SRH                                                           |
    .  Segment List[0] = End.DT4/DT6/DT46 SID of Return Path        .
    .  <Remained Segment List of Return Path>                       .
    .  <Segment List of Forward Path>                               .
    .  Next-Header = UDP (17)                                       .
    .                                                               .

Gandhi, et al.           Expires 26 October 2024               [Page 33]
Internet-Draft       Using STAMP for Segment Routing          April 2024

    +---------------------------------------------------------------+
    | UDP Header as shown in Figure 13                              |
    .                                                               .
    +---------------------------------------------------------------+
    | Payload as shown in Figure 13                                 |
    .                                                               .
    +---------------------------------------------------------------+

       Example 1: Using Insert-Mode Encoding with SRv6 Return Path

    +---------------------------------------------------------------+
    | IPv6 Header                                                   |
    .  Source IP Address = Session-Sender IPv6 Address              .
    .  Destination IP Address = Segment List[Segments Left]         .
    .  Next-Header = 43, Routing Type = SRH (4)                     .
    .                                                               .
    +---------------------------------------------------------------+
    | SRH                                                           |
    .  Segment List[0] = End.DT4/DT46 SID of Forward Path           .
    .  <Remained Segment List of Forward Path>                      .
    .  Next-Header = 4 (IPv4)                                       .
    .                                                               .
    +---------------------------------------------------------------+
    | IPv4 Header as shown in Figure 13 (Return Path)               |
    .      Destination IPv4 Address in L3VPN table                  .
    +---------------------------------------------------------------+
    | UDP Header as shown in Figure 13                              |
    .                                                               .
    +---------------------------------------------------------------+
    | Payload as shown in Figure 13                                 |
    .                                                               .
    +---------------------------------------------------------------+

       Example 2: Using Encaps-Mode Encoding with IPv4 Return Path

    +---------------------------------------------------------------+
    | IPv6 Header                                                   |
    .  Source IP Address = Session-Sender IPv6 Address              .
    .  Destination IP Address = Segment List[Segments Left]         .
    .  Next-Header = 43, Routing Type = SRH (4)                     .
    .                                                               .
    +---------------------------------------------------------------+
    | SRH                                                           |
    .  Segment List[0] = End.DT6/DT46 SID of Forward Path           .
    .  <Remained Segment List of Forward Path>                      .
    .  Next-Header = 43 (IPv6)                                      .
    .                                                               .
    +---------------------------------------------------------------+

Gandhi, et al.           Expires 26 October 2024               [Page 34]
Internet-Draft       Using STAMP for Segment Routing          April 2024

    | IPv6 Header as shown in Figure 13 (Return Path)               |
    .      Destination IPv6 Address in L3VPN table                  .
    +---------------------------------------------------------------+
    | UDP Header as shown in Figure 13                              |
    .                                                               .
    +---------------------------------------------------------------+
    | Payload as shown in Figure 13                                 |
    .                                                               .
    +---------------------------------------------------------------+

       Example 3: Using Encaps-Mode Encoding with IPv6 Return Path

         Figure 19: Example Session-Sender Test Packet in Loopback
               Measurement Mode for L3 Service over SRv6 Path

6.4.2.1.  SRv6 Return Path

   For SRv6 return path, the Session-Sender test packets are encoded in
   Insert-Mode as shown in Example 1 in Figure 19.

   The SRv6 Segment List except the L3VPN SRv6 SID instantiated on the
   Session-Reflector of the forward direction L3 service is added in the
   IPv6/SRH encapsulation of the Session-Sender test packet.  In
   addition, SRv6 Segment List including the L3VPN SRv6 SID instantiated
   on the Session-Sender for the reverse direction L3 service is also
   added in the IPv6/SRH encapsulation to return the test packet to the
   Session-Sender from the Session-Reflector.

6.4.2.2.  IP Return Path

   For IP return path, the Session-Sender test packets are encoded in
   Encaps-Mode as shown in Examples 2 and 3 in Figure 19.

   The SRv6 Segment List including the L3VPN SRv6 SID instantiated on
   the Session-Reflector for the forward direction L3 service is added
   in the IPv6/SRH encapsulation to transmit the Session-Sender test
   packet to the Session-Reflector.

   An inner IP header for return path MUST also be added in the Session-
   Sender test packets that has the Destination Address equal to the
   Session-Sender address to forward the test packet to the Session-
   Sender from the Session-Reflector.  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 on the Session-Reflector.

Gandhi, et al.           Expires 26 October 2024               [Page 35]
Internet-Draft       Using STAMP for Segment Routing          April 2024

   The Session-Reflector decapsulates the IPv6/SRH and forwards the
   Session-Sender test packet using the inner IP header for the return
   path (after adding IPv6/SRH encapsulation for the reverse direction
   L3 service).

6.4.3.  Loopback Measurement Mode for Layer-2 Services over SRv6 Path

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

    +---------------------------------------------------------------+
    | IPv6 Header                                                   |
    .  Source IP Address = Session-Sender IPv6 Address              .
    .  Destination IP Address = Segment List[Segments Left]         .
    .  Next-Header = 43, Routing Type = SRH (4)                     .
    .                                                               .
    +---------------------------------------------------------------+
    | SRH                                                           |
    .  Segment List[0] = End.DT2U SID of Return Path                .
    .  <Remained Segment List of Return Path>                       .
    .  <Segment List of Forward Path>                               .
    .  Next-Header = UDP (17)                                       .
    .                                                               .
    +---------------------------------------------------------------+
    | UDP Header as shown in Figure 13                              |
    .                                                               .
    +---------------------------------------------------------------+
    | Payload as shown in Figure 13                                 |
    .                                                               .
    +---------------------------------------------------------------+

       Example: Using Insert-Mode Encoding with SRv6 Return Path

       Figure 20: Example Session-Sender Test Packet in Loopback Mode
                       for L2 Service over SRv6 Path

6.4.3.1.  SRv6 Return Path

   For SRv6 return path, the Session-Sender test packets are encoded in
   Insert-Mode as shown in Figure 20.

   The SRv6 Segment List except the L2VPN SRv6 SID instantiated on the
   Session-Reflector of the forward direction L2 service is added in the
   IPv6/SRH encapsulation of the Session-Sender test packet.  In
   addition, SRv6 Segment List including the L2VPN SRv6 SID instantiated

Gandhi, et al.           Expires 26 October 2024               [Page 36]
Internet-Draft       Using STAMP for Segment Routing          April 2024

   on the Session-Sender for the reverse direction L2 service is also
   added in the IPv6/SRH encapsulation to return the test packet to the
   Session-Sender from the Session-Reflector.

6.4.3.2.  IP Return Path

   For IP return path, the Session-Sender test packets are encoded in
   Encaps-Mode.  However, this mode is outside the scope of this
   document.

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

   As shown in Figure 21, Reference Topology for "loopback measurement
   mode with timestamp and forward", STAMP Session-Sender S1 initiates a
   Session-Sender test packet in loopback measurement mode with network
   programming function.  The network programming function is used to
   optimize the "operations of punt test packet and generate return test
   packet" on the STAMP Session-Reflector, as timestamping is
   implemented in fast path in data plane.  This helps to achieve higher
   number of STAMP session scale and faster measurement interval.

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

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

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

   The Session-Sender retrieves the timestamp T1 and T2 from the
   received Session-Sender test packet and collects the receive
   timestamp T4 locally.  Timestamps T1 and T2 are used by the Session-
   Sender to measure one-way delay as (T2 - T1).  Timestamps T1 and T4
   are used by the Session-Sender to measure loopback delay as (T4 -
   T1).

Gandhi, et al.           Expires 26 October 2024               [Page 37]
Internet-Draft       Using STAMP for Segment Routing          April 2024

   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) for STAMP packet processing.  The network
   programming function carried by the test packet enables the Session-
   Reflector to add the "receive timestamp" (T2) at specific offset in
   the payload of the test packet.

7.1.  Loopback Measurement Mode with Timestamp and Forward Function for
      SR-MPLS Data Plane

   The MPLS Network Action (MNA) Sub-Stack defined in
   [I-D.ietf-mpls-mna-hdr] is used for SR-MPLS paths for "timestamp and
   forward network programming function" for 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 network action for "Timestamp and Forward network programming
   function".

   In the Session-Sender test packets for SR-MPLS paths, the MNA Sub-
   Stack with Opcode MNA.TSF is added in the MPLS header as shown in
   Figure 22, to collect timestamp in the "Receive Timestamp" field in
   the payload of the test packet from Session-Reflector.  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 LSE after the MNA.TSF Opcode in
   the MNA Sub-Stack.  The U flag is set to skip the network action and
   forward the test packet (and not drop the packet).

   The SR-MPLS label stack of the return path can be added after the MNA
   Sub-Stack to receive the return test packet on a specific path as
   described in loopback measurement for SR-MPLS path this document.
   The Ingress-to-Egress (I2E), Hop-By-Hop (HBH), Select scope (IHS) is
   set to "Select" in this case.

Gandhi, et al.           Expires 26 October 2024               [Page 38]
Internet-Draft       Using STAMP for Segment Routing          April 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] (top of stack)  | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Segment[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 13 (Return Path)    |
    .                                                               .
    +---------------------------------------------------------------+

         Figure 22: Example Session-Sender Test Packet in Loopback
                Measurement Mode with TSF for SR-MPLS Paths

   When a Session-Reflector receives a test packet with MNA Sub-Stack
   with Opcode MNA.TSF, after timestamping the test packet payload at
   specific offset, the Session-Reflector pops the MNA Sub-Stack (after
   completing any other network actions) and forwards the test packet as
   defined in loopback measurement mode for SR-MPLS path in this
   document.

7.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 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 Session-Sender test packet payload is
   statically configured for MNA.TSF.  The offset in the Session-Sender
   test packet payload (e.g., for unauthenticated mode with offset 16
   bytes) is also statically configured for MNA.TSF.

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

   The 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 is outside the scope of this document.

Gandhi, et al.           Expires 26 October 2024               [Page 39]
Internet-Draft       Using STAMP for Segment Routing          April 2024

7.2.  Loopback Measurement Mode with Timestamp and Forward Function for
      SRv6 Data Plane

   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 STAMP test packets.

   In the Session-Sender test packets for SRv6 paths, Timestamp and
   Forward Endpoint Function (End.TSF) is carried with the target
   Segment Identifier (SID) in SRH [RFC8754] as shown in Figure 23, for
   both Insert-Mode and Encaps-Mode encoding, to collect timestamp in
   the "Receive Timestamp" field in the payload of the test packet from
   Session-Reflector.

Gandhi, et al.           Expires 26 October 2024               [Page 40]
Internet-Draft       Using STAMP for Segment Routing          April 2024

    +---------------------------------------------------------------+
    | IPv6 Header                                                   |
    .  Source IP Address = Session-Sender IPv6 Address              .
    .  Destination IP Address = Segment List[Segments Left]         .
    .  Next-Header = 43, Routing Type = SRH (4)                     .
    .                                                               .
    +---------------------------------------------------------------+
    | SRH                                                           |
    .  <Segment List for Return Path>                               .
    .  <Segment List for Forward Path including End.TSF SID>        .
    .  Next-Header = UDP (17)                                       .
    .                                                               .
    +---------------------------------------------------------------+
    | UDP Header as shown in Figure 13                              |
    .                                                               .
    +---------------------------------------------------------------+
    | Payload as shown in Figure 13                                 |
    .                                                               .
    +---------------------------------------------------------------+

       Example 1: Using Insert-Mode Encoding with SRv6 Return Path

    +---------------------------------------------------------------+
    | IPv6 Header                                                   |
    .  Source IP Address = Session-Sender IPv6 Address              .
    .  Destination IP Address = Segment List[Segments Left]         .
    .  Next-Header = 43, Routing Type = SRH (4)                     .
    .                                                               .
    +---------------------------------------------------------------+
    | SRH                                                           |
    .  Segment List[0] = End.TSF SID                                .
    .  <Remained Segment List of Forward Path>                      .
    .  Next-Header = 43 (IPv6) or 4 (IPv4)                          .
    .                                                               .
    +---------------------------------------------------------------+
    | IP Header as shown in Figure 13 (Return Path)                 |
    .                                                               .
    +---------------------------------------------------------------+
    | UDP Header as shown in Figure 13                              |
    .                                                               .
    +---------------------------------------------------------------+
    | Payload as shown in Figure 13                                 |
    .                                                               .
    +---------------------------------------------------------------+

       Example 2: Using Encaps-Mode Encoding with IP Return Path

Gandhi, et al.           Expires 26 October 2024               [Page 41]
Internet-Draft       Using STAMP for Segment Routing          April 2024

         Figure 23: Example Session-Sender Test Packet in Loopback
                  Measurement Mode with TSF for SRv6 Paths

   The Session-Sender test packets are encoded in Insert-Mode for SRv6
   return path and in Encaps-Mode for IP return path as defined in
   loopback measurement mode for SRv6 path in this document.

   When a Session-Reflector receives a test packet with Timestamp and
   Forward Endpoint (End.TSF) for the target SID, which is local, after
   timestamping the test packet at specific offset, the Session-
   Reflector forwards the test packet as defined in loopback measurement
   mode for SRv6 paths.

7.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 Session-Reflector node.  The End.TSF is
   statically configured on the Session-Reflector node and not
   advertised into the routing protocols.  The timestamp format for
   64-bit PTPv2 and NTP to be added in the Session-Sender test packet
   payload is statically configured for End.TSF.  The offset in the
   Session-Sender test packet payload (e.g., for unauthenticated mode
   with offset 16 bytes) is also statically configured for End.TSF.

7.2.2.  Node Capability for Timestamp and Forward Endpoint Function

   The 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 is outside the scope of this document.

8.  Packet Loss Measurement in SR Networks

   The procedure described in Section 4 for delay measurement in SR
   networks using STAMP test packets also allows for round-trip, near-
   end (forward direction) and far-end (backward direction) inferred
   packet loss measurement in SR networks.  This, however, provides only
   an approximate view of the data packet loss.

   The loopback measurement mode and loopback measurement mode with
   timestamp and forward network programming function allow only the
   round-trip packet loss measurement.

Gandhi, et al.           Expires 26 October 2024               [Page 42]
Internet-Draft       Using STAMP for Segment Routing          April 2024

9.  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 procedure
   described in Section 4 for delay measurement in SR networks 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 SR path on the Session-Reflector.

   In case of L3 and L2 services in SR networks, the associated SR-MPLS
   service labels and SRv6 service SIDs can be used to measure receive
   data packets (for receive traffic counters) on the Session-Reflector.

   In loopback measurement mode and loopback measurement mode with
   timestamp and forward network programming function, the direct
   measurement is not applicable.

10.  ECMP Measurement in SR Networks

   An SR path 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 path 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 delay of an SR path.

   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 paths, sweeping of MPLS entropy label [RFC6790] values
   can be used in Session-Sender test packets and Session-Reflector 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 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.

Gandhi, et al.           Expires 26 October 2024               [Page 43]
Internet-Draft       Using STAMP for Segment Routing          April 2024

11.  STAMP Session State

   The threshold-based notification for delay and packet loss metrics
   may not be generated if the delay and packet loss metrics are not
   changing significantly.  For an unambiguous monitoring, the
   controller may need to distinguish the cases whether the STAMP
   session is active, but delay and packet loss metrics are not changing
   significantly crossing the thresholds or the STAMP session has failed
   and not transmitting or receiving test packets.

   The STAMP session state monitoring allows to know if the performance
   measurement test is active, idle or failed.  The STAMP session state
   is notified as idle when Session-Sender is not transmitting test
   packets.  The STAMP session state is initially notified as active
   when Session-Sender is transmitting test packets and as soon as one
   or more reply test packets are received at the Session-Sender.

   The STAMP session state is notified as failed when consecutive N
   number of reply test packets are not received at the Session-Sender
   after the STAMP 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 session on the Session-
   Sender also indicates the connectivity (i.e., liveness) failure of
   the link, SR path or the L3/L2 service where the STAMP session was
   active.

12.  Additional STAMP Test Packet Processing Rules

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

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

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

Gandhi, et al.           Expires 26 October 2024               [Page 44]
Internet-Draft       Using STAMP for Segment Routing          April 2024

12.3.  Router Alert Option

   The Router Alert IP option (RAO) [RFC2113] MUST NOT be set in the
   Session-Sender and Session-Reflector test packets to be able to punt
   the test packets using the Destination UDP port for STAMP.

12.4.  IPv6 Flow Label

   The Flow Label field in the IPv6 header of the Session-Sender test
   packets 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 use the Flow Label value it received in
   the IPv6 header of the Session-Sender test packet in the reply test
   packet, and it can be based on the local configuration on the
   Session-Reflector.

12.5.  UDP Checksum

   For IPv4 STAMP test packets, where the local processor after adding
   the timestamp, 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 STAMP test packets, where the local processor after adding
   the timestamp, 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 the STAMP
   sessions, and it can be based on the local policy.

13.  Implementation Status

   Editorial note: Please remove this section prior to publication.

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

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

Gandhi, et al.           Expires 26 October 2024               [Page 45]
Internet-Draft       Using STAMP for Segment Routing          April 2024

14.  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 direction and return
   paths are provisioned by the operator for the STAMP session.  It is
   assumed that the operator has verified the integrity of the forward
   direction 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.

15.  IANA Considerations

   This document does not require any IANA action.

16.  References

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

Gandhi, et al.           Expires 26 October 2024               [Page 46]
Internet-Draft       Using STAMP for Segment Routing          April 2024

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

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

Gandhi, et al.           Expires 26 October 2024               [Page 47]
Internet-Draft       Using STAMP for Segment Routing          April 2024

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

16.2.  Informative References

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

   [IEEE802.1AX]
              IEEE Std. 802.1AX, "IEEE Standard for Local and
              metropolitan area networks - Link Aggregation", November
              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>.

   [RFC4656]  Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
              Zekauskas, "A One-way Active Measurement Protocol
              (OWAMP)", RFC 4656, September 2006,
              <https://www.rfc-editor.org/info/rfc4656>.

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

   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
              Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

Gandhi, et al.           Expires 26 October 2024               [Page 48]
Internet-Draft       Using STAMP for Segment Routing          April 2024

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

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

Gandhi, et al.           Expires 26 October 2024               [Page 49]
Internet-Draft       Using STAMP for Segment Routing          April 2024

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

   [RFC9545]  Cheng, W., Li, H., Li, C., Gandhi, R., and R. Zigler,
              "Path Segment in MPLS-Based Segment Routing Network",
              RFC 9545, February 2024,
              <https://www.rfc-editor.org/info/rfc9545>.

   [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-
              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-13, 13 February 2024,
              <https://www.ietf.org/archive/id/draft-ietf-pce-sr-bidir-
              path-13.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>.

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

Gandhi, et al.           Expires 26 October 2024               [Page 50]
Internet-Draft       Using STAMP for Segment Routing          April 2024

   this document.

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

Gandhi, et al.           Expires 26 October 2024               [Page 51]
Internet-Draft       Using STAMP for Segment Routing          April 2024

   Email: footer.foote@nokia.com

Gandhi, et al.           Expires 26 October 2024               [Page 52]