Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label Switched Paths (LSPs)
draft-ietf-mpls-stamp-01

MPLS Working Group                                             G. Mirsky
Internet-Draft                                               Independent
Intended status: Standards Track                                L. Zhang
Expires: 18 December 2026                                   L. Andersson
                                                     Huawei Technologies
                                                            16 June 2026

   Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label
                         Switched Paths (LSPs)
                        draft-ietf-mpls-stamp-01

Abstract

   Simple Two-way Active Measurement Protocol (STAMP), defined in RFC
   8762 and RFC 8972, is expected to be able to monitor the performance
   of paths between systems that use a wide variety of encapsulations.
   This document defines encapsulation and bootstrapping of a STAMP test
   session over an MPLS Label Switched Path.

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 18 December 2026.

Copyright Notice

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

Mirsky, et al.          Expires 18 December 2026                [Page 1]
Internet-Draft             STAMP for MPLS LSPs                 June 2026

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions Used in this Document . . . . . . . . . . . .   3
       1.1.1.  Abbreviations . . . . . . . . . . . . . . . . . . . .   3
       1.1.2.  Requirements Language . . . . . . . . . . . . . . . .   3
   2.  Encapsulation of a STAMP Test Packet  . . . . . . . . . . . .   3
   3.  Bootstrap STAMP Using LSP Ping  . . . . . . . . . . . . . . .   4
     3.1.  STAMP Session Identifier TLV  . . . . . . . . . . . . . .   4
     3.2.  Return Codes  . . . . . . . . . . . . . . . . . . . . . .   6
   4.  STAMP Session Establishment . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  STAMP Session Identifier TLV  . . . . . . . . . . . . . .   7
     5.2.  Return Codes  . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Operational Considerations  . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informational References  . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   [RFC8762] and [RFC8972] defined the base specification and optional
   extensions of the Simple Two-Way Active Measurement Protocol (STAMP).
   The reader is expected to be familiar with the terminology of
   [RFC8762] and [RFC8972].  STAMP can be used to measure packet loss,
   and packet delay, detect packet re-ordering, and unwanted multiple
   copies of a STAMP packet.  This document defines the encapsulation of
   the STAMP test packet over a Multiprotocol Label Switching (MPLS)
   Label Switched Path (LSP).  Also, the use of LSP Ping [RFC8029] to
   bootstrap and control the path for the reflected STAMP test packet is
   discussed in the document.  [RFC8762] defined two modes of a STAMP
   Session-Reflector - Stateful and Stateless.  While using the LSP Ping
   extension to bootstrap a STAMP test session applies for both Session-
   Reflector modes, controlling the path for the reflected STAMP test
   packet is appropriate for the Stateful mode of the Session-Reflector
   only.

Mirsky, et al.          Expires 18 December 2026                [Page 2]
Internet-Draft             STAMP for MPLS LSPs                 June 2026

   This document defines the STAMP Session Identifier TLV as an
   extension to LSP Ping [RFC8029].  It is to be used to instruct the
   STAMP Session-Reflector how to demultiplex incoming STAMP test
   sessions and a path to use for the reflected STAMP test packets.  The
   TLV will be allocated from the TLV and sub-TLV registry defined in
   [RFC8029].  As a special case, forward and reverse directions of the
   STAMP test session can form a bi-directional co-routed associated
   channel.

1.1.  Conventions Used in this Document

1.1.1.  Abbreviations

   STAMP: Simple Two-way Active Measurement Protocol

   MPLS: Multiprotocol Label Switching

   LSP: Label Switched Path

   LSR: Label Switching Router

   SSID: STAMP Session Identifier

1.1.2.  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.  Encapsulation of a STAMP Test Packet

   STAMP can be used to measure one-way and roud-trip packet loss and
   packet delay, and detect packet re-ordering, and unwarranted
   replication of a STAMP test packet.  [RFC8762] defined formats of a
   STAMP test packet and reflected STAMP test packet in unauthenticated
   and authenticated modes, respectively.  These STAMP test packets can
   be encapsulated in IP/UDP to be transmitted over an MPLS LSP as
   follows:

   *  The STAMP test packet sent by the ingress Label Switching Router
      (LSR) SHOULD be a UDP packet with a well-known destination port
      862 [RFC8762] and a source port assigned by the sender.  The
      destination UDP port MAY be selected from the Dynamic UDP ports
      range.  The mechanism used to select the port number from the
      Dynamic range is outside the scope of this document.

Mirsky, et al.          Expires 18 December 2026                [Page 3]
Internet-Draft             STAMP for MPLS LSPs                 June 2026

   *  The destination IP address MUST be chosen from the 127/8 range for
      IPv4.  For IPv6, the destination address MUST be chosen from the
      IPv6 Dummy Prefix range
      [IANA-IPv6-Special-Purpose-Address-Registry].  Method of selecting
      an IP address from the range is outside the scope of this
      document.

   *  For the STAMP test packet, the sender MUST set the IP TTL or hop
      limit to 255 [RFC5082].

   *  The source IP address is a routable address of the sender.

   *  The reflected STAMP test packets are UDP packets.

   *  The source IP address of a reflected STAMP test packet is a
      routable address of the STAMP Session-Reflector.

3.  Bootstrap STAMP Using LSP Ping

   A STAMP test session over an MPLS LSP can be bootstrapped using LSP
   Ping, defined in [RFC8029].  To bootstrap a STAMP test session, STAMP
   Session Identifier TLV MUST be used.  When LSP Ping is used to
   bootstrap a STAMP test session, the Reply Mode field SHOULD be set to
   "Reply via an IPv4/IPv6 UDP packet" (2) value.  In some environments,
   e.g., point-to-multipoint LSP, the Reply Mode field MAY be set to "Do
   not reply" (1).  The value of the Reply Mode field MUST NOT be set to
   "Reply via an IPv4/IPv6 UDP packet with Router Alert" (3) [RFC9570].
   This document defines a new TLV - the STAMP Session Identifier (SSID)
   TLV.  The SSID TLV MUST contain the STAMP Session Identifier (SSID)
   [RFC8972] value and MAY contain none, one or more sub-TLVs that can
   be used to carry information about the path for reflected STAMP test
   packet.

3.1.  STAMP Session Identifier TLV

   The STAMP Session Identifier TLV is an optional TLV within the LSP
   Ping [RFC8029].  The STAMP Session Identifier TLV carries SSID value
   and, optionally, information about the path onto which the STAMP
   Session-Reflector MUST transmit reflected STAMP test packets for the
   given STAMP test session.  The format of the STAMP Session Identifier
   TLV is as presented in Figure 1.

Mirsky, et al.          Expires 18 December 2026                [Page 4]
Internet-Draft             STAMP for MPLS LSPs                 June 2026

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   STAMP Session Id TLV Type   |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              SSID             |  UDP Destination Port Number  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       Sub-TLVs (optional)                     ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1: STAMP Session Identifier TLV

   STAMP Session Identifier Type is a two-octet field and has a value of
   TBD1 (to be assigned by IANA as requested in Section 5).

   Length is a two-octet field equal to the length in octets of the
   SSID, UDP Destination Port Number, Reserved, and Sub-TLVs fields.
   The minimum value MUST be eight.

   SSID field is a two-octet field that identifies the STAMP test
   session at the STAMP Session-Sender.

   UDP Destination Port Number is a two-octet field.  The field
   indicates the value of the UDP destination port in test packet
   transmitted by the Session-Sender for the test session with SSID.
   The Session-Sender MAY set the value of the field to 862 that is
   assigned by IANA as TWAMP-Test Receiver Port.  If the value of the
   field is not equal to 862 then it MUST be one from the range of
   Dynamic ports, i.e., from 49152 to 65535.  Any other value of the UDP
   Destination Port Number field is invalid and the Session-Reflector
   MUST send an Echo Reply message with the received STAMP Session
   Identifier TLV and set the Return Code field to "UDP Destination Port
   Unavailable" (Section 5.2).

Mirsky, et al.          Expires 18 December 2026                [Page 5]
Internet-Draft             STAMP for MPLS LSPs                 June 2026

   Sub-TLVs field contains zero or more sub-TLVs, i.e., nested TLVs that
   have independent types and MUST be four-octet aligned.  This field
   MAY be used to define the path of the reflected STAMP test packet.
   In that case, Only non-multicast Target FEC Stack sub-TLVs (already
   defined or to be defined in the future) for TLV Types 1, 16, and 21
   in the "Multiprotocol Label Switching (MPLS) Label Switched Paths
   (LSPs) Ping Parameters" registry are permitted to be used in this
   field.  Other sub-TLVs MUST NOT be used.  (This implies that
   multicast Target FEC Stack sub-TLVs, e.g., the Multicast P2MP LDP FEC
   Stack sub-TLV and the Multicast MP2MP LDP FEC Stack sub-TLV, are not
   permitted in the Sub-TLVs field.)  If no Target FEC Stack sub-TLVs
   are found in the STAMP Session Identifier TLV, the STAMP Session-
   Reflector MUST revert to transmitting the STAMP reflected packets
   over the IP network.

   If the STAMP Session-Reflector cannot find the path specified in the
   STAMP Session Identifier TLV, it MUST send Echo Reply with the
   received STAMP Session Identifier TLV and set the Return Code to "The
   specified Reflected Packet Path was not found" (Section 5.2).

   The STAMP Session Identifier TLV MAY be used in the bootstrapping of
   a STAMP test session.  A STAMP Session-Reflector that supports this
   specification MUST support subsequent STAMP Session Identifier TLVs
   after the STAMP test session with the given SSID has been
   established.  The system that receives a new path in the Sub-TLVs
   field for the established STAMP test session MUST use the new path
   for the reflected STAMP test packets.  Suppose a system that supports
   this specification receives an LSP Ping with the STAMP Session
   Identifier TLV with no Target FEC Stack sub-TLVs in the Sub-TLVs
   field, even though the reflected test packets for the specified STAMP
   test session has been transmitted according to the previously
   received STAMP Session Identifier TLV.  In that case, the egress LSR
   MUST transition to transmitting reflected STAMP packets over an IP
   network.

3.2.  Return Codes

   This document defines the following Return Codes for MPLS LSP Echo
   Reply:

   *  "The specified Reflected Packet Path was not found", (TBD2).  When
      a specified reverse path is not available at the STAMP Session-
      Reflector an Echo Reply with the Return Code set to "The specified
      Reflected Packet Path was not found" MUST be sent back to the
      STAMP Session-Sender Section 3.1.

Mirsky, et al.          Expires 18 December 2026                [Page 6]
Internet-Draft             STAMP for MPLS LSPs                 June 2026

   *  "UDP Destination Port Unavailable" (TBD3).  If the value of the
      Destination UDP Port Number field is not 862, nor is from the
      Dynamic ports range, the Session-Reflector MUST send an Echo Reply
      to the Session-Sender with the Return Code set to "UDP Destination
      Port Unavailable".

4.  STAMP Session Establishment

   A STAMP test session can be bootstrapped using LSP Ping.  To monitor
   performance for a particular MPLS LSP and FEC combination LSP Ping
   Echo request and Echo reply packets, in the ping mode, exchanged
   between the STAMP Session-Sender and Session-Reflector for that MPLS
   LSP and FEC combination.  If LSP Ping is used to establishing a STAMP
   test session, an LSP Ping Echo request message MUST carry the SSID
   value assigned by the Session-Sender for the STAMP test session.
   This MUST subsequently be used as the SSID field in the STAMP test
   session packets sent by the STAMP Session-Sender.

   On receipt of the LSP Ping Echo request message, the STAMP Session-
   Reflector MUST send an LSP Ping Echo reply if the validation of the
   FEC in the LSP Ping Echo request message succeeds.  The Session-
   Reflector SHOULD use the value in the SSID field and source IP
   address in the received LSP Ping Echo request message to demultiplex
   STAMP test sessions.  The Session-Reflector MAY use a combination of
   other values in IP/UDP headers instead of using SSID to demultiplex
   STAMP test sessions.

   If the MPLS network includes an equal-cost multipath environment, a
   STAMP Session-Sender MUST use the same value of an Entropy Label
   ([RFC6790] and [RFC8662]) in the LSP Ping Echo request that
   bootstraps the STAMP test session and consecutive STAMP test packets.

5.  IANA Considerations

5.1.  STAMP Session Identifier TLV

   The IANA is requested to assign a new value for the STAMP Session
   Identifier TLV from the Standard Action range (0-16383), that
   requires a response if not recognized, from the TLVs registry in the
   Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
   Parameters registry group.

Mirsky, et al.          Expires 18 December 2026                [Page 7]
Internet-Draft             STAMP for MPLS LSPs                 June 2026

        +=========+==============================+===============+
        | Value   | Description                  | Reference     |
        +=========+==============================+===============+
        |  (TBD1) | STAMP Session Identifier TLV | This document |
        +---------+------------------------------+---------------+

                    Table 1: New BFD Reverse Type TLV

5.2.  Return Codes

   IANA is requested to assign two new Return Codes from the Standards
   Action range of the Return Codes registry in the Multiprotocol Label
   Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry
   group.

         +=========+============================+===============+
         | Value   | Description                | Reference     |
         +=========+============================+===============+
         |  (TBD2) | The specified Reflected    | This document |
         |         | Packet Path was not found. |               |
         +---------+----------------------------+---------------+
         |  (TBD3) | UDP Destination Port       | This document |
         |         | Unavailable.               |               |
         +---------+----------------------------+---------------+

                         Table 2: New Return Code

6.  Operational Considerations

   The operational considerations discussed in [RFC8762] also apply to
   this document.  Using LSP Ping [RFC8029] in combination with the
   STAMP Session Identifier TLV defined in this document to bootstrap
   the STAMP test session simplifies the collection of essential
   performance metrics in the MPLS domain.

7.  Security Considerations

   Security considerations discussed in [RFC8029], [RFC8762], and
   [RFC8972] apply to this document.

8.  Acknowledgments

   The authors sincerely appreciate Richard "Footer" Foote's thoughtful
   comments.  The authors express their sincere appreciation of the
   thorough review and text contributed by Loa Andersson.

9.  References

Mirsky, et al.          Expires 18 December 2026                [Page 8]
Internet-Draft             STAMP for MPLS LSPs                 June 2026

9.1.  Normative References

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

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

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

   [RFC8662]  Kini, S., Kompella, K., Sivabalan, S., Litkowski, S.,
              Shakir, R., and J. Tantsura, "Entropy Label for Source
              Packet Routing in Networking (SPRING) Tunnels", RFC 8662,
              DOI 10.17487/RFC8662, December 2019,
              <https://www.rfc-editor.org/info/rfc8662>.

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

   [RFC9570]  Kompella, K., Bonica, R., and G. Mirsky, Ed., "Deprecating
              the Use of Router Alert in LSP Ping", RFC 9570,
              DOI 10.17487/RFC9570, May 2024,
              <https://www.rfc-editor.org/info/rfc9570>.

9.2.  Informational References

Mirsky, et al.          Expires 18 December 2026                [Page 9]
Internet-Draft             STAMP for MPLS LSPs                 June 2026

   [IANA-IPv6-Special-Purpose-Address-Registry]
              IANA, "IANA IPv6 Special-Purpose Address Registry",
              <https://www.iana.org/assignments/iana-ipv6-special-
              registry/iana-ipv6-special-registry.xhtml>.

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

Authors' Addresses

   Greg Mirsky
   Independent
   Email: gregimirsky@gmail.com

   Li Zhang
   Huawei Technologies
   China
   Email: zhangli344@huawei.com

   Loa Andersson
   Huawei Technologies
   Email: loa@pi.nu

Mirsky, et al.          Expires 18 December 2026               [Page 10]