<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902" docName="draft-mirsky-mpls-stamp-07" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.6.0 -->
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<front>
    <title abbrev="STAMP for MPLS LSPs">Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label Switched Paths (LSPs)</title>
    <seriesInfo name="Internet-Draft" value="draft-mirsky-mpls-stamp-07"/>
    
    <author initials="G." surname="Mirsky" fullname="Greg Mirsky">
      <organization>Ericsson</organization>
      <address>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    
    <date year="2024"/>
    
    <area>Routing</area>
    <workgroup>MPLS Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>LSP Ping</keyword>
    <keyword>STAMP </keyword>
    <abstract>
      <t>
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.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
 <xref target="RFC8762" format="default"/> and <xref target="RFC8972" format="default"/> defined
 the base specification and extensions of the Simple Two-Way Active Measurement Protocol (STAMP). 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 message over a Multiprotocol Label Switching (MPLS )
 Label Switched Path (LSP). Also, the use of LSP Ping <xref target="RFC8029"/> to bootstrap and control the path for the reflected STAMP test packet
 is discussed in the document. <xref target="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.
      </t>
      <t>
 This document defines the Reflected Packet Path TLV as an extension to LSP Ping  
 <xref target="RFC8029" format="default"/>. 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 <xref target="RFC8029" format="default"/>.
 As a special case, forward and reverse
 directions of the STAMP test session can form a bi-directional co-routed associated channel.
      </t>
      <section numbered="true" toc="default">
        <name>Conventions Used in this Document</name>
    
         <section title="Acronyms">

          <t>STAMP:          Simple Tw-way Active Measurement Protocol</t>
           <t>MPLS:          Multiprotocol Label Switching</t>
            <t>LSP:          Label Switching Path</t>
            <t>SSID:        STAMP Session Identifier</t>
         </section>    
         
        <section numbered="true" toc="default">
          <name>Requirements Language</name>
          <t>
   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 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> 
   when, and only when, they appear in all capitals, as shown here.
          </t>
        </section>
      </section>
    </section>
    <section anchor="stamp-encap-sec" numbered="true" toc="default">
      <name>Encapsulation of a STAMP Test Packet</name>
      <t>
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.
<xref target="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:
</t>
      <ul spacing="normal">
        <li>
The STAMP test packet sent by the ingress LSR SHOULD be a UDP packet
   with a well-known destination port 862 <xref target="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.
</li>
<li>
The destination IP address MUST be randomly chosen from the 127/8 range for IPv4. For IPv6, the ::1/128 address
MUST be used. 
</li>
<li>
For the STAMP test packet, the sender MUST set the IP TTL or hop limit to 255 <xref target="RFC5082"/>.
</li>
<li>
The source IP address is a routable address of the sender.
</li>
<li>
The reflected STAMP test packets are UDP packets.
</li>
<li>
The source IP address of a reflected STAMP test packet is a routable address of the STAMP Session-Reflector.
</li>
      </ul>
    </section>
    
    <section anchor="stamp-bootstrap-sec" numbered="true" toc="default">
      <name>Bootstrap STAMP Using LSP Ping</name>
      <t>
 A STAMP test session over an MPLS LSP can be bootstrapped using LSP Ping, defined in <xref target="RFC8029" format="default"/>.
 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)
 <xref target="I-D.kompella-mpls-lspping-norao"/>.
 This document defines a new SSID TLV. The STAMP Session Identifier TLV MUST
 contain the STAMP Session Identifier (SSID) <xref target="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.
      </t>
      <section anchor="ssid-tlv" numbered="true" toc="default">
        <name>STAMP Session Identifier TLV</name>
        <t>
The STAMP Session Identifier TLV is an optional TLV within the LSP Ping <xref target="RFC8029" format="default"/>. 
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 <xref target="mpls-stamp-tlv" format="default"/>.
</t>
        <figure anchor="mpls-stamp-tlv">
          <name>STAMP Session Identifier TLV</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[    
  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  |           Reserved            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~               Reflected Packet Path  (optional)               ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>
            STAMP Session Identifier Type is a two-octet field and has a value of TBD1 (to be assigned by IANA
            as requested in <xref target="iana-consider" format="default"/>).
        </t>
        <t>
            Length field is a two-octet field equal to the length in octets of the SSID, UDP Destination Port Number,
            Reserved, and Reflected Packet Path fields. The minimum value MUST be eight.
        </t>
        <t>SSID field is a four-octet field that identifies the STAMP test session at the STAMP Session-Sender.</t>
        <t>
        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 to862
        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 te Return Code field to
        "UDP Destination Port Unavailable" (<xref target="iana-return-code"/>).
        </t>
        <t>Reserved is a two-octet field. It MUST be zeroed on transmission and ignored on reciept.</t>
        <t>
            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 group's TLVs and sub-TLVs registry MAY be 
            used in this field. The Non-FEC Path TLV, defined in <xref target="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.
        </t>
        <t>
             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" (<xref target="iana-return-code"/>).
        </t>
        <t>
           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 as sub-TLVs in the Reflected Packet Path 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 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. In that case, the egress LSR MUST
   transition to transmitting reflected STAMP packets over an IP network.
   </t>
      </section>
      
      <section anchor="return-codes" numbered="true" toc="default">
        <name>Return Codes</name>
        <t>
This document defines the following Return Codes for MPLS LSP Echo Reply:
</t>
        <ul spacing="normal">
          <li>
"The specified Reflected Packet Path was not found",  (TBD2).
When a specified reverse path is not available at the STAMPSession-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 <xref target="ssid-tlv" format="default"/>.
</li>
<li>"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".
</li>
        </ul>
      </section>
      
    </section>
    <section anchor="operational-sec" numbered="true" toc="default">
      <name>STAMP Session Establishment</name>
      <t>
      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.
   </t>
   <t>
   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. The Session-Reflector MAY
   use a combination of other values in IP/UDP headers instead of using SSID to demultiplex STAMP test sessions.
</t>
<t>
If the MPLS network includes an equal-cost multipath environment, a STAMP Session-Sender MUST
use the same value of an Entropy Label (<xref target="RFC6790"/> and <xref target="RFC8662"/>)
in the LSP Ping Echo request that bootstraps the STAMP test session and consecutive STAMP test packets.
</t>
      </section>
<!--
    <section anchor="operational-sec" numbered="true" toc="default">
      <name>Operational Considerations</name>
      <t>
  When an explicit path is set either as Static or RSVP-TE LSP,
  corresponding sub-TLVs, defined in <xref target="RFC7110" format="default"/>, MAY be used
  to identify the explicit reverse path for the BFD session. If any of defined in <xref target="RFC7110" format="default"/>
  sub-TLVs used in BFD Reverse Path TLV, then the periodic verification of the control plane
  against the data plane, as recommended in Section 4 <xref target="RFC5884" format="default"/>, MUST use
  the Return Path TLV, as per <xref target="RFC7110" format="default"/>, with that sub-TLV.
  By using the LSP Ping with Return Path TLV, an operator monitors whether
  at the egress BFD node the reverse LSP is mapped to the same FEC as the BFD session.
  Selection and control of the rate of LSP Ping with Return Path TLV
  follows the recommendation of <xref target="RFC5884" format="default"/>:
"The rate of generation of these LSP Ping Echo request
   messages SHOULD be significantly less than the rate of generation of
   the BFD Control packets.  An implementation MAY provide configuration
   options to control the rate of generation of the periodic LSP Ping
   Echo request messages."
      </t>
      <t>
    Suppose an operator planned network maintenance activity that possibly affects FEC used in
    the BFD Reverse Path TLV. In that case, the operator MUST avoid the unnecessary disruption using
    the LSP Ping with a new FEC in the BFD Reverse Path TLV.  But in some scenarios, proactive measures cannot be taken.
    Because the frequency of LSP Ping messages will be lower than the defect detection time provided by the BFD session.
    As a result, a change in the reverse-path FEC will first be detected as the BFD session's failure.
    In such a case, the ingress BFD node SHOULD immediately transmit the LSP Ping Echo request with Return Path TLV
    to verify whether the FEC is still valid. If the failure was caused by the change in the FEC used for the
    reverse direction of the BFD session, the ingress BFD node SHOULD bootstrap a new BFD session
 using another FEC in BFD Reverse Path TLV.
      </t>
-->
        <section anchor="iana-consider" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="iana-TLV" numbered="true" toc="default">
        <name>STAMP Session Identifier TLV</name>
        <t>
     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 group, "TLVs and
   sub-TLVs" registry.
        </t>
        <table anchor="bfdtlv-table" align="center">
          <name>New BFD Reverse Type TLV</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">&nbsp;(TBD1)</td>
              <td align="left">STAMP Session Identifier TLV</td>
              <td align="left">This&nbsp;document</td>
            </tr>
          </tbody>
        </table>
      </section>
      
      <section anchor="iana-return-code" numbered="true" toc="default">
        <name>Return Code</name>
        <t>
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 group's "Return Codes" registry, as follows using a
Standards Action value.
</t>
        <table anchor="return-code" align="center">
          <name>New Return Code</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">&nbsp;(TBD2)</td>
              <td align="left">The specified Reflected Packet Path was not found.</td>
              <td align="left">This&nbsp;document</td>
            </tr>
            <tr>
              <td align="left">&nbsp;(TBD3)</td>
              <td align="left">UDP Destination Port Unavailable.</td>
              <td align="left">This&nbsp;document</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
 Security considerations discussed in <xref target="RFC8029" format="default"/>, <xref target="RFC8762" format="default"/>,
 and <xref target="RFC8972" format="default"/> apply to this document. 
      </t>
    </section>
    
        <section numbered="true" toc="default">
      <name>Acknowledgments</name>
      <t>
The author sincerely appreciates Richard "Footer" Foote's thoughtful comments.
      </t>
    </section>
    
  </middle>
  <back>
  <references>
  <name>References</name>
  <references>
        <name>Normative References</name>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8762.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8972.xml"/>

      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8662.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-spring-bfd.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-kompella-mpls-lspping-norao.xml"/>
    </references>
    
    <references>
    <name>Informational References</name>
         <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5082.xml"/>
          </references>
    
    </references>

  </back>
</rfc>
