Internet-Draft STAMP for MPLS LSPs July 2022
Mirsky Expires 29 January 2023 [Page]
MPLS Working Group
Intended Status:
Standards Track
G. Mirsky

Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label Switched Paths (LSPs)


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

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 29 January 2023.

Table of Contents

1. Introduction

[RFC8762] and [RFC8972] defined the base specification and extensions of the Simple Two-Way Active Measurement Protocol (STAMP). STAMP can be used to measure packet loss, packet delay, detect packet re-ordering, and unwanted multiple copies of a STAMP packet. This document defines the encapsulation of the STAMP test message over an 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.

This document defines the Reflected Packet Path 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. Acronyms

STAMP: Simple Tw-way Active Measurement Protocol

MPLS: Multiprotocol Label Switching

LSP: Label Switching Path

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

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. This document defines a new SSID TLV. The STAMP Session Identifier 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.

  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                              |
 |                                                               |
 ~                    Reflected Packet Path                      ~
 |                                                               |
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 field is a two-octet field equal to the length in octets of the SSID and Reflected Packet Path fields. The minimum value MUST be four.

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

Reflected Packet Path field contains none, one or more sub-TLVs. Any Target FEC Stack sub-TLV (already defined, or to be defined in the future) for TLV Types 1, 16, and 21 of MPLS LSP Ping Parameters registry MAY be used in this field. The Non-FEC Path TLV, defined in [I-D.ietf-spring-bfd], MAY be used to specify the path for a STAMP reflected test packet in the SR-MPLS environment. None, one or more sub-TLVs MAY be included in the Reflected Packet Path TLV. If no 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 Reflected Packet Path 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 system that supports this specification MUST support using the STAMP Session Identifier TLV after the STAMP test session has been established. If a system that supports this specification receives an LSP Ping with the STAMP Session Identifier TLV that has no sub-TLVs in the Reflected Packet Path 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, the egress LSR MUST transition to transmitting reflected STAMP packets over an IP network.

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

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 "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry.

Table 1: New BFD Reverse Type TLV
Value Description Reference
 (TBD1) STAMP Session Identifier TLV This document

5.2. Return Code

The IANA is requested to assign a new Return Code value from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "Return Codes" sub-registry, as follows using a Standards Action value.

Table 2: New Return Code
Value Description Reference
 (TBD2) The specified Reflected Packet Path was not found. This document

6. Security Considerations

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

7. References>

7.1. Normative References

Mirsky, G., Tantsura, J., Varlashkin, I., Chen, M., and J. Wenying, "Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane", Work in Progress, Internet-Draft, draft-ietf-spring-bfd-04, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", DOI 10.17487/RFC2119, BCP 14, RFC 2119, , <>.
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, , <>.
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, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", DOI 10.17487/RFC8174, RFC 8174, BCP 14, , <>.
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, , <>.
Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", DOI 10.17487/RFC8762, RFC 8762, , <>.
Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, "Simple Two-Way Active Measurement Protocol Optional Extensions", DOI 10.17487/RFC8972, RFC 8972, , <>.

7.2. Informational References

Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, , <>.

Appendix A. Acknowledgments

The authors greatly appreciate a thorough review and the most helpful comments from Eric Gray and Carlos Pignataro. The authors much appreciate the help of Qian Xin, who provided information about the implementation of this specification.

Author's Address

Greg Mirsky