<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!ENTITY nbsp   "&#160;">
<!ENTITY zwsp   "&#8203;">
<!ENTITY nbhy   "&#8209;">
<!ENTITY wj     "&#8288;">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3032 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml">
<!ENTITY RFC3931 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3931.xml">
<!ENTITY RFC4026 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4026.xml">
<!ENTITY RFC4448 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4448.xml">
<!ENTITY RFC5462 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5462.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8762 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8762.xml">
<!ENTITY RFC8972 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8972.xml">
<!ENTITY RFC2104 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml">
<!ENTITY RFC4385 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4385.xml">
<!ENTITY RFC5586 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5586.xml">
<!ENTITY RFC5082 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5082.xml">
<!ENTITY RFC5085 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5085.xml">
<!ENTITY RFC5087 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5087.xml">
<!ENTITY RFC5921 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5921.xml">
<!ENTITY RFC5960 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5960.xml">
<!ENTITY RFC6374 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6374.xml">
<!ENTITY RFC6658 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6658.xml">
<!ENTITY RFC6790 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml">
<!ENTITY RFC6936 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6936.xml">
<!ENTITY RFC7708 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7708.xml">
<!ENTITY RFC7820 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7820.xml">
<!ENTITY RFC8085 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml">
<!ENTITY RFC9780 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9780.xml">
<!ENTITY RFC9801 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9801.xml">
<!ENTITY I-D.ietf-spring-stamp-srpm-mpls SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-stamp-srpm-mpls.xml">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-ietf-mpls-stamp-pw-08" category="std" consensus="true" ipr="trust200902">
<!-- xml2rfc v2v3 conversion 3.12.0 -->
<!-- Generated by id2xml 1.5.0 on 2020-02-06T01:41:26Z -->
    <?rfc compact="yes"?>
    <?rfc text-list-symbols="oo*+-"?>
    <?rfc subcompact="no"?>
    <?rfc sortrefs="false"?>
    <?rfc symrefs="true"?>
    <?rfc strict="yes"?>
    <?rfc toc="yes"?>

    <front>
    <title abbrev="STAMP in MPLS Networks">Encapsulation of Simple Two-Way Active Measurement Protocol for LSPs and Pseudowires in MPLS Networks</title>

    <author fullname="Rakesh Gandhi" initials="R." role="editor" surname="Gandhi">
    <organization>Cisco Systems, Inc.</organization>
    <address>
    <postal><country>Canada</country>
    </postal>
        <email>rgandhi@cisco.com</email>
    </address>
    </author>

    <author fullname="Patrice Brissette" initials="P." surname="Brissette">
    <organization>Cisco Systems, Inc.</organization>
        <address>
    <postal><country>Canada</country>
    </postal>
        <email>pbrisset@cisco.com</email>
    </address>
    </author>

    <author fullname="Edward Leyton" initials="E." surname="Leyton">
     <organization>Verizon Wireless</organization>
     <address>
     <email>edward.leyton@verizonwireless.com</email>
     </address>
    </author>

    <author fullname="Xiao Min" initials="X." surname="Min">
      <organization>ZTE Corp.</organization>
     <address>
       <postal>
         <street/>
         <city>Nanjing</city>
         <region/>
         <code/>
         <country>China</country>
       </postal>
       <email>xiao.min2@zte.com.cn</email>
     </address>
    </author>

    <date year="2026"/>
    <workgroup>MPLS Working Group</workgroup>

    <abstract><t>
    This document describes the procedure for encapsulating
    the Simple Two-Way Active Measurement Protocol (STAMP), defined in RFC 8762, and its optional
    extensions defined in RFC 8972, in MPLS networks.
    Label Switched Paths (LSPs) and Pseudowires (PWs) are used in MPLS networks for various services,
    including Layer 2 and Layer 3 data packets, and may use the Control Word (CW).
    The procedure for encapsulating STAMP test packets with or without the CW and/or an IP/UDP header
    for LSPs and PWs is also described.
   </t>
    </abstract>
    </front>

    <middle>
    <section title="Introduction" anchor="sect-1">
  
   <t>The Simple Two-Way Active Measurement Protocol (STAMP) provides
   capabilities for measuring various metrics in IP networks
   <xref target="RFC8762"/> without the use of a control channel to 
   pre-signal session parameters.  <xref target="RFC8972"/> defines optional extensions for STAMP.
   </t>

   <t>Label Switched Paths (LSPs) are used in MPLS networks for various services, 
   including Layer 2 and Layer 3 data packets.
   LSPs can be point-to-point or point-to-multipoint. 
   STAMP encapsulations for point-to-multipoint LSPs are outside the scope of this document.
   This document specifies STAMP encapsulations for point-to-point LSPs.
   </t>

   <t>Pseudowires (PWs) are used in MPLS networks for various services,
   including Layer 2 and Layer 3 data packets <xref target="RFC6658"/>.
   PWs are bidirectional in nature.
   PWs may use the Control Word (CW) as defined in Section 3 of <xref target="RFC4385"/>.
   This document covers STAMP encapsulations for point-to-point PWs,
   whereas point-to-multipoint PWs are outside the scope of this document.
   PWs can be single-segment PWs or multi-segment PWs.
   This document specifies STAMP encapsulations for single-segment PWs; multi-segment PWs are outside the scope of this document.
   </t>

   <t>
   MPLS Transport Profile (MPLS-TP) <xref target="RFC5960"/> is designed to use the MPLS data plane without any changes.
   Therefore, when STAMP is specified over an MPLS data plane, it is equally
   applicable to MPLS-TP networks. 
   As specified in Section 2 of <xref target="RFC5921"/>, 
   "OAM and protection mechanisms, and forwarding of data packets, must
   be able to operate without IP forwarding support".
   </t>

   <t>
   A Generic Associated Channel (G-ACh) <xref target="RFC5586"/> provides a mechanism
   for transporting Operations, Administration, and Maintenance (OAM) and
   other control messages over the MPLS data plane. The G-ACh types identify the
   various OAM messages that are being transported over the channel.
   Virtual Circuit Connectivity Verification (VCCV) is used as a Control Channel for PWs as described in <xref target="RFC5085"/>.
   A G-ACh can be used as a VCCV Control Channel as described in <xref target="RFC7708"/>.
   </t>

   <t>
   When using STAMP for MPLS and MPLS-TP for both LSPs and PWs,
   there are unique aspects that need to be considered concerning the use of CW,
   and these aspects are addressed in this document.
   </t>

   <t>This document describes the procedure for the encapsulation of STAMP, 
   defined in <xref target="RFC8762"/>, and its optional extensions, defined 
   in <xref target="RFC8972"/>, for LSPs and PWs in MPLS networks.  
   The procedure is also described for encapsulating 
   STAMP test packets with or without the CW and/or an IP/UDP header for LSPs and PWs.
   </t>

   <t>
   This document defines two new G-ACh types when using STAMP without an IP/UDP header.
   These types are independent of the PW demultiplexer type and are therefore applicable to both
   the PW label and the Layer 2 Tunneling Protocol version 3 (L2TPv3) PW demultiplexer.
   This document uses the existing G-ACh types for IPv4 and IPv6 when STAMP test packets are transmitted with an IP/UDP header for the LSPs and PWs that carry CW.
   </t>

   <t>
   Additional considerations for encapsulating STAMP for performance measurement of Segment Routing 
   LSPs over the MPLS data plane are described in <xref target="I-D.ietf-spring-stamp-srpm-mpls"/>, and
   are outside the scope of this document.
   </t>

   <section title="Requirements" anchor="sect-1.1">

   <t>
   STAMP test packets need to be transmitted with the same
   label stack used by the LSPs and PWs to ensure proper validation
   of the underlay path taken by the actual data traffic. In addition, STAMP test packets need
   to follow the same Equal-Cost Multi-Path (ECMP) underlay path taken by the LSP and PW data traffic in the network.
   PW data traffic may be encapsulated using CW, as defined in Section 3 of <xref target="RFC4385"/>, and an IP header.
   As such, STAMP test packets need to be transmitted over these PWs using a G-ACh and an IP/UDP header.
   </t>

   <t>
   When a STAMP test packet is transmitted to the target IP address of a STAMP Session-Reflector, it is
   encapsulated for an MPLS LSP by the data plane based on the reachability of that IP address over the LSP.
   Hence, the STAMP test packets are treated the same way as the data traffic forwarded over the LSP by the transit nodes along the path.
   </t>

   <t>
   Data traffic over the L2-Specific Sublayer (L2SS), as used in L2TPv3 PWs, carries CW but does not carry an IP/UDP header.
   As such, STAMP test packets need to be transmitted over these L2TPv3 PWs
   using a G-ACh carrying only the STAMP payload without any IP/UDP header.
   </t>

   <t>
   Private Line Emulation (PLE) <xref target="RFC9801"/>
   traffic is sent over a Packet Switched Network (PSN) as Virtual Private Wire Services (VPWS) using PWs.
   The data packets are encapsulated with PLE CW, but they do not carry any IP header.
   As such, STAMP test packets need to be transmitted using the same label stack,
   including the VPWS PW label as the PLE traffic <xref target="RFC9801"/>,
   and encapsulated using a G-ACh but without an IP/UDP header.
   This allows STAMP test packets to experience the same forwarding
   behavior, follow the same underlay path as the PLE traffic, and avoid different ECMP behavior on intermediate nodes.</t>

   <t>
   The G-ACh types allow for demultiplexing of the VCCV Control Channel for PWs <xref target="RFC7708"/>.
   The G-ACh types for STAMP test packets with or without IP/UDP headers are also used to demultiplex the VCCV Control Channel for PWs.
   Signaling extensions for the VCCV Control Channel for PWs for STAMP are outside the scope of this document.
   </t>

   <t>
   The G-ACh provides support for the OAM Control Channel associated
   with MPLS-TP <xref target="RFC5960"/> LSPs and PWs.
   The OAM Control Channel for MPLS-TP needs to be extended to encapsulate STAMP test packets 
   (just like the delay and loss measurement packets defined in <xref target="RFC6374"/>).
   The G-ACh types for STAMP also allow for the demultiplexing of the OAM Control Channel for MPLS-TP.
   </t>
   
   <t>
   The requirements for the encapsulation of 
   the STAMP test packets for the LSPs and PWs in MPLS networks can be summarized as follows:
   </t>

  <ul>
  <li>
  <t>The G-ACh needs to support STAMP test packets with an IP/UDP header.</t>
  </li>
  <li>
  <t>The G-ACh needs to support STAMP test packets without an IP/UDP header.</t>
  </li>
  <li>
  <t>The G-ACh types need to support demultiplexing of the Control Channel for STAMP test packets.</t>
  </li>
  <li>
  <t>Session-Sender test packets need to follow the underlay path taken by the data traffic that uses CW.</t>
  </li>
  <li>
  <t>Session-Sender test packets need to follow the same ECMP underlay path taken by the data traffic that uses CW and an Entropy Label defined in <xref target="RFC6790"/>.</t>
  </li>
  <li>
  <t>Session-Sender test packets need to follow the same ECMP underlay path taken by the data traffic that uses CW but does not use an Entropy Label defined in <xref target="RFC6790"/>.</t>
  </li>
  <li>
  <t>Session-Reflector test packets can follow the reverse underlay path taken by Session-Sender test packets.</t>
  </li>
  <li>
  <t>Session-Reflector test packets can follow the same reverse ECMP underlay path taken by Session-Sender test packets.</t>
  </li>
  </ul>


   </section>

   <section title="Examples of MPLS Data Traffic Use Cases" anchor="sect-1.2">

    <t>Examples of MPLS data traffic use cases for STAMP test packets with IP/UDP headers are:</t>
    <ol>
     <li>
      <t>MPLS PW Data Traffic (with CW and IP header)</t>
     </li>
     <li>
      <t>MPLS-TP PW Data Traffic (with CW and IP header)</t>
     </li>
     <li>
      <t>MPLS LSP Data Traffic (with IP header)</t>
     </li>
    </ol>
    
    <t>Examples of MPLS data traffic use cases for STAMP test packets without IP/UDP headers are:</t>
    <ol>
     <li>
      <t>MPLS Ethernet PW Data Traffic <xref target="RFC4448"/></t>
     </li>
     <li>
      <t>L2SS used in L2TPv3 PW Data Traffic <xref target="RFC3931"/></t>
     </li>
     <li>
      <t>Private Line Emulation <xref target="RFC9801"/> PW Data Traffic</t>
     </li>
     <li>
      <t>TDM over IP <xref target="RFC5087"/> PW Data Traffic (with no IP header)</t>
     </li>
     <li>
      <t>MPLS-TP LSP Data Traffic</t>
     </li>
    </ol>

    </section>

   </section>

   <section title="Conventions Used in This Document" anchor="sect-2">
       
   <section title="Requirements Language" anchor="sect-2.1">
  <t>
 The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
 "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
 described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shown here.
        </t>
    </section>

   <section title="Abbreviations" anchor="sect-2.2">

   <table anchor="abbreviations">
   <name>Abbreviations</name>
   <thead>
   <tr>
   <th align="left">Abbreviation</th>
   <th align="left">Meaning</th>
   <th align="left">Reference</th>
   </tr>
   </thead>
   <tbody>
   <tr>
   <td>CE</td>
   <td>Customer Edge</td>
   <td><xref target="RFC4026"/></td>
   </tr>
   <tr>
  <td>CW</td>
  <td>Control Word</td>
  <td><xref target="RFC4385"/></td>
  </tr>
  <tr>
   <td>ECMP</td>
   <td>Equal-Cost Multi-Path</td>
   <td><xref target="RFC6790"/></td>
   </tr>
   <tr>
   <td>G-ACh</td>
   <td>Generic Associated Channel</td>
   <td><xref target="RFC5586"/></td>
   </tr>
   <tr>
   <td>GAL</td>
  <td>Generic Associated Channel Label</td>
   <td><xref target="RFC5586"/></td>
   </tr>
  <tr>
  <td>GTSM</td>
  <td>Generalized TTL Security Mechanism</td>
  <td><xref target="RFC5082"/></td>
  </tr>
   <tr>
   <td>HMAC</td>
   <td>Hash-based Message Authentication Code</td>
   <td><xref target="RFC2104"/></td>
   </tr>
   <tr>
   <td>L2SS</td>
   <td>L2-Specific Sublayer</td>
   <td><xref target="RFC3931"/></td>
   </tr>
   <tr>
  <td>L2TPv3</td>
  <td>Layer 2 Tunneling Protocol version 3</td>
   <td><xref target="RFC3931"/></td>
   </tr>
  <tr>
  <td>L2VPN</td>
  <td>Layer 2 Virtual Private Network</td>
  <td><xref target="RFC4026"/></td>
  </tr>
  <tr>
  <td>L3VPN</td>
  <td>Layer 3 Virtual Private Network</td>
  <td><xref target="RFC4026"/></td>
  </tr>
   <tr>
   <td>LSP</td>
   <td>Label Switched Path</td>
   <td><xref target="RFC3032"/></td>
   </tr>
   <tr>
   <td>MPLS</td>
   <td>Multiprotocol Label Switching</td>
   <td><xref target="RFC3032"/></td>
   </tr>
   <tr>
   <td>MPLS-TP</td>
   <td>MPLS Transport Profile</td>
   <td><xref target="RFC5960"/></td>
   </tr>
   <tr>
   <td>OAM</td>
   <td>Operations, Administration, and Maintenance</td>
   <td><xref target="RFC5586"/></td>
   </tr>
   <tr>
   <td>PE</td>
   <td>Provider Edge</td>
   <td><xref target="RFC4026"/></td>
   </tr>
   <tr>
   <td>PLE</td>
   <td>Private Line Emulation</td>
   <td><xref target="RFC9801"/></td>
   </tr>
  <tr>
  <td>PSN</td>
  <td>Packet Switched Network</td>
  <td><xref target="RFC9801"/></td>
  </tr>
   <tr>
   <td>PW</td>
   <td>Pseudowire</td>
   <td><xref target="RFC6658"/></td>
   </tr>
   <tr>
   <td>S bit</td>
   <td>Bottom of Stack bit</td>
   <td><xref target="RFC3032"/></td>
   </tr>
   <tr>
   <td>SSID</td>
   <td>STAMP Session Identifier</td>
   <td><xref target="RFC8972"/></td>
   </tr>
   <tr>
   <td>STAMP</td>
   <td>Simple Two-Way Active Measurement Protocol</td>
   <td><xref target="RFC8762"/></td>
   </tr>
   <tr>
   <td>TC</td>
   <td>Traffic Class</td>
   <td><xref target="RFC5462"/></td>
   </tr>
   <tr>
  <td>TDM</td>
  <td>Time-Division Multiplexing</td>
  <td><xref target="RFC5087"/></td>
  </tr>
   <tr>
   <td>TTL</td>
  <td>Time to Live</td>
   <td><xref target="RFC3032"/></td>
   </tr>
  <tr>
  <td>VCCV</td>
  <td>Virtual Circuit Connectivity Verification</td>
  <td><xref target="RFC5085"/></td>
  </tr>
  <tr>
  <td>VPWS</td>
  <td>Virtual Private Wire Service</td>
  <td><xref target="RFC9801"/></td>
  </tr>
   </tbody>
   </table>

   </section>

   <section title="STAMP Reference Topology" anchor="sect-2.3">
   <t>
   In the STAMP reference topology shown in <xref target="ure-stamp-reference-top"/>,
   there is an LSP or a PW to transport data between Provider Edge (PE) endpoints S1 and R1.
   The STAMP Session-Sender on PE node S1 initiates a
   Session-Sender test packet, and the STAMP Session-Reflector on PE node R1
   transmits a reply Session-Reflector test packet. The Session-Reflector test packet may be transmitted
   to the STAMP Session-Sender node S1 on the same path (that is, the same set
   of links and nodes) in the reverse direction of the path taken toward the Session-Reflector node R1.
   </t>

   <figure title="STAMP Reference Topology using LSP and PW" anchor="ure-stamp-reference-top"><artwork><![CDATA[

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

         STAMP Session-Sender        STAMP Session-Reflector
         Provider Edge Endpoint      Provider Edge Endpoint
]]></artwork>
    </figure>

   <t>
   T1 is a transmit timestamp, and T4 is a receive timestamp added by node S1.
   T2 is a receive timestamp, and T3 is a transmit timestamp added by node R1.
   </t> 

   <t>
   The STAMP test packets are used for both one-way and round-trip performance metrics, such as delay, delay
   variation, and packet loss <xref target="RFC8972"/>.
   </t> 

    </section>

   </section>
   
    <section title="Overview" anchor="sect-3">
    <t>
    The STAMP Session-Sender and Session-Reflector test packet payloads defined 
    in <xref target="RFC8972"/> are encapsulated and transmitted over the LSPs and PWs in MPLS networks.  
    </t>

    <t>
    The base STAMP test packet payloads can be encapsulated using an IP/UDP
    header and destination UDP port 862 as the default destination port,
    as specified in Section 4.1 of <xref target="RFC8762"/>.
    When choosing a destination port from the User Ports range, the possible impact on the network 
    needs to be carefully studied and agreed on by all users of the network domain where the test has 
    been planned, as described in Section 4.1 of <xref target="RFC8762"/>.
    </t>

    <t>
    The source UDP port is chosen by the Session-Sender from the User Ports range, which
    MUST be different from 862 and MUST be able to distinguish between the received Session-Reflector test packets and
    the Session-Sender test packets from the reverse direction.
    </t> 

    <t>
    The STAMP Session Identifier (SSID) defined in <xref target="RFC8972"/> is used to identify the STAMP session and MUST be set to non-zero.
    The SSID MUST be carried in the STAMP test packets in both directions to be able to identify the STAMP sessions for MPLS LSPs and PWs.
    </t>

    <t>
    The STAMP Session-Sender and Session-Reflector addresses for a STAMP session are provisioned on both endpoints of the MPLS LSP and PW.
    </t>

      <section title="Formats and G-ACh Types for STAMP" anchor="sect-3.1">

    <t>
    STAMP test packet payloads are encapsulated over G-ACh in two formats:
    Format-1 (with an IP/UDP header) and Format-2 (without an IP/UDP header).
    </t>

    <ul>

    <li>
    Format-1: For encapsulating the STAMP test packet payloads over a G-ACh with IP/UDP headers, IPv4 and IPv6 
    channel types <xref target="RFC4385"/> are used for both Session-Sender 
    and Session-Reflector test packets.  The destination UDP port number in the 
    Session-Sender and Session-Reflector test packets distinguishes the test packets.
    </li>

    <li>
    Format-2: For encapsulating the STAMP test packet payloads over a G-ACh without adding IP/UDP headers,
    two new channel types are defined in this document: one for the 
    Session-Sender test packets and one for the Session-Reflector 
    test packets.  The different channel types are required for the 
    Session-Sender and Session-Reflector test packets as the STAMP test packets 
    do not have a way to discriminate between them.
    </li>

    </ul>

    <section title="STAMP Session Identification" anchor="sect-3.1.1">

    <ul>
    <li>
    Format-1:
    <ul>
    <li>
    The Session-Reflector address that is the source address, destination UDP port, and the SSID in the
    received Session-Reflector test packets, along with the locally provisioned STAMP session parameters are used
    by the Session-Sender to identify a STAMP session.
    </li>
    <li>
    The Session-Sender address that is the source address, destination UDP port, and the SSID
    in the received Session-Sender test packets, along with the locally provisioned STAMP session parameters are used
    by the Stateful Session-Reflector to identify a STAMP session.
    </li>
    </ul>
    </li>

    <li>
    Format-2:
    <ul>
    <li>
    The SSID along with the reverse direction LSP and PW context in the received Session-Reflector
    test packets, along with the locally provisioned STAMP session parameters are used
    by the Session-Sender to identify a STAMP session.
    </li>
    <li>
    The SSID along with the LSP and PW context in the received Session-Sender test packets, along with the
    locally provisioned STAMP session parameters are used by the Stateful Session-Reflector
    to identify a STAMP session.
    </li>
    </ul>
    </li>
    </ul>

    </section>

    </section>

    <section title="Using STAMP for LSPs and PWs" anchor="sect-3.2">

   <t>
   Following encapsulation use-cases provide the STAMP test packets with the same ECMP behaviour on the intermediate nodes as data traffic being measured:
   </t>

    <ul>
    <li>
    The STAMP test packet payloads are encapsulated with an IP/UDP header without a G-ACh header, and with an MPLS 
    header using the same label stack as the MPLS LSP and MPLS-TP LSP data traffic that contains an IP header but not the CW.
    The label stack may include the L2 or L3 VPN label for the service carried over the LSP.
    </li>

    <li>
    The STAMP test packet payloads are encapsulated with an IP/UDP header with a G-ACh header (instead of the CW used by the data traffic), and with an MPLS 
    header using the same label stack as the MPLS LSP and MPLS-TP LSP data traffic that contains an IP header and the CW.
    The label stack may include the L2 or L3 VPN label for the service carried over the LSP.
    </li>

    <li>
    The STAMP test packet payloads are encapsulated with an MPLS 
    header using the same label stack as the PW data traffic (including the PW label) and a G-ACh header 
    (instead of the CW used by the data traffic). 
    The encapsulation allows STAMP test packets to follow the same path as the PW data traffic.
    </li>

    </ul>

    <t>
    When using an IP header, the IP version (IPv4 or IPv6) in the STAMP test packets MUST match the IP version used 
    for the LSPs and PWs being measured.  When an LSP carries both IPv4 and IPv6
    data traffic, the IP version used in the STAMP test packet MUST match the IP
    version of the specific data traffic flow being measured.
    </t>

    <section title="VCCV Channel" anchor="sect-3.2.1">

    <t>
    The OAM Control Channel traffic between two PE endpoints is not forwarded beyond the PE
    endpoints toward Customer Edge (CE) devices; instead, the OAM 
    messages are intercepted at the PE endpoints for exception processing in the control plane.
    <xref target="RFC5085"/> defines mechanisms for the VCCV Control Channel to carry OAM messages for PWs.
    </t>

    <ul>
    <li>
    <t>The "In-band VCCV for Control Word with 0001b as first nibble (Type 1)" defined in Section 5.1.1 of <xref target="RFC5085"/>
    MUST be added when measuring PWs with CW to avoid different ECMP hashing behaviour.</t>
    </li>
    <li>
    <t>The method for "TTL Expiry VCCV (Type 3)" defined in Section 5.1.3 of <xref target="RFC5085"/>
    allows the termination of OAM messages on the remote PE endpoint nodes.
    This method is applied to the STAMP test packets to force the test packets
    to be processed on Session-Sender and Session-Reflector control planes by adding the PW label with a TTL value of 1.</t>
    </li>
    <li>
    <t>VCCV Type 2 is also referred to as the "MPLS Router Alert Label" <xref target="RFC5085"/>
    This method could result in a different ECMP hashing behaviour,
    and thus result in the STAMP test packets taking a path that differs from that of the actual data traffic under test <xref target="RFC5085"/>
    Hence, the use of VCCV Type 2 for STAMP when measuring PW traffic is not supported by the procedures defined in this document.</t>
    </li>
    </ul>

    <t>
    The procedure described to encapsulate STAMP test packets for PWs is equally
    applicable to MPLS LSPs and MPLS-TP LSPs using CW in the following scenarios:
    </t>

    <ul>
    <li>
    <t>For data traffic over MPLS LSPs using an IP header, STAMP test packets
    in Format-1 are transmitted.</t>
    </li>
    <li>
    <t>For data traffic without an IP header over MPLS-TP LSPs, STAMP test
    packets in Format-2 are transmitted with a TTL value of 1 in the ultimate
    LSP label in the MPLS header.</t>
    </li>
    </ul>

    </section>

    <section title="TTL Processing" anchor="sect-3.2.2">

    <t>
    The IPv4 Time to Live (TTL), IPv6 Hop Limit, and Generalized TTL Security Mechanism (GTSM)
    procedures from <xref target="RFC5082"/> also apply to the
    encapsulation of STAMP test packets; hence, the IPv4 TTL, non-ultimate MPLS label TTL,
    and IPv6 Hop Limit MUST be set to 255.  Note that the TTL in the ultimate PW label or LSP label
    is set separately to 1 when using the TTL Expiry method (VCCV Type 3) described above.
    </t>

    </section>

    <section title="UDP Checksum Handling" anchor="sect-3.2.3">

    <t>
    When the local processor cannot recompute the UDP checksum after adding the
    timestamp or add a checksum complement <xref target="RFC7820"
    format="default"/>, the following procedures apply:
    </t>

    <ul>
    <li>
    <t>For IPv4 STAMP test packets, the Session-Sender and Session-Reflector set
    the UDP checksum value to 0 <xref target="RFC8085" format="default"/>.</t>
    </li>
    <li>
    <t>For IPv6 STAMP test packets, the Session-Sender and Session-Reflector use
    the procedure defined in <xref target="RFC6936" format="default"/> for UDP
    ports used in STAMP sessions to set the UDP checksum value to 0 and this can be 
    based on a local policy.</t>
    </li>
    </ul>

    </section>

    <section title="G-ACh Label (GAL)" anchor="sect-3.2.4">

    <t>
    The G-ACh label (GAL) defined in <xref target="RFC5586"/> also applies to the G-ACh types defined in this document
    for STAMP test packets without an IP/UDP header (Format-2).
    This use case is similar to the use case for MPLS-TP LSP performance measurement defined in <xref target="RFC6374"/>.
    As specified in Section 4.2 of <xref target="RFC5586"/>, the GAL MUST NOT be used with PWs in MPLS-TP networks.
    Therefore, Format-2 encapsulation using GAL does not apply to MPLS-TP PWs.
    </t>

    <t>
    The GAL applies to Format-1 using the G-ACh channel type for IPv4 (0x0021) or IPv6 (0x0057) as described in <xref target="RFC5586"/>.
    </t>

    </section>

    </section>

    <section title="Applicability of Control Channel Types to STAMP for LSPs and PWs" anchor="sect-3.3">

    <t>Control Channel Types defined in <xref target="RFC5085"/> are applicable to STAMP test packets for LSPs and PWs as shown in <xref target="iana-cc-type-tbl"/>: </t>

    <texttable anchor="iana-cc-type-tbl" title="Control Channel Types for LSPs and PWs">

    <ttcol align="left">Control Channel Type</ttcol>
    <ttcol align="left">Control Channel Name</ttcol>
    <ttcol align="left">STAMP Header Format</ttcol>
    <ttcol align="left">G-ACh Type</ttcol>

    <c>Type 1</c>
    <c>In-band: Control Word with 0001b as first nibble</c>
    <c>Format-1 (IP/UDP Headers)</c>
    <c>IPv4 G-ACh (0x0021) and IPv6 G-ACh (0x0057)</c>

    <c>Type 1</c>
    <c>In-band: Control Word with 0001b as first nibble</c>
    <c>Format-2 (No IP/UDP Headers)</c>
    <c>STAMP G-ACh (TBA1 and TBA2)</c>

    <c>Type 2</c>
    <c>Out-of-band: MPLS Router Alert Label</c>
    <c>Not supported</c>
    <c>Not supported</c>

    <c>Type 3</c>
    <c>TTL Expiry: Label with TTL as 1</c>
    <c>Format-1 (IP/UDP Headers)</c>
    <c>IPv4 G-ACh (0x0021) and IPv6 G-ACh (0x0057)</c>

    <c>Type 3</c>
    <c>TTL Expiry: Label with TTL as 1</c>
    <c>Format-2 (No IP/UDP Headers)</c>
    <c>STAMP G-ACh (TBA1 and TBA2)</c>

    </texttable>

    </section>

    </section>

    <section title="Session-Sender Test Packet" anchor="sect-4">

   <t>
   STAMP Session-Sender test packets are transmitted for an LSP or a PW 
   using an MPLS header with or without an IP/UDP header.
   For PWs, Session-Sender test packets are transmitted using the label stack of the PW, including the PW label and the G-ACh.
   For LSPs, Session-Sender test packets are transmitted using the label stack of the LSP with or without a G-ACh.
   </t>

    <section title="Session-Sender Test Packet with IP/UDP Header" anchor="sect-4.1"><t>
   The content of an example STAMP Session-Sender test packet for an LSP or a PW encapsulated using a
   G-ACh and an IP/UDP header is shown in <xref target="ure-stamp-sender-packet1"/>. 
   </t>

    <figure title="Example Session-Sender Test Packet with G-ACh and IP/UDP Header" anchor="ure-stamp-sender-packet1"><artwork><![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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Label(1)               | TC  |0|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    PW Label or Ultimate LSP Label     | TC  |1|      1        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 0 0 1|Version|    Reserved   | IPv4 (0x0021) or IPv6 (0x0057)|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | 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 = As chosen by Session-Sender                    .
 .  Destination Port = User-configured Destination Port or 862   .
 .                                                               .
 +---------------------------------------------------------------+
 | Payload = Test Packet as specified in Section 3 of RFC 8972   |
 .           in Figure 1 and Figure 3                            .
 .                                                               .
 +---------------------------------------------------------------+
]]></artwork>
    </figure>


   <t>
   The destination address in the IP header of a STAMP test packet can be one of the following when adding an MPLS encapsulation for an LSP or a PW.
   </t>

     <ul>
     <li>
     <t>A routable IPv4 address</t>
     </li>
     <li>
     <t>A routable IPv6 address</t>
     </li>
     <li>
     <t>An IPv4 address from the 127/8 range</t>
     </li>
     <li>
     <t>An IPv6 address from the Dummy IPv6 Prefix 100:0:0:1::/64 <xref target="RFC9780"/> <xref target="IANA-IPv6-REG" format="default"/></t>
     </li>
     </ul>

   <t>In the case of IPv6 address from the dummy prefix, as described in Section 1 of <xref target="RFC9780"/>, this source-only prefix is deliberately used as a destination to generate an exception.</t>

<t>
Examples of implementations are:
</t>
<ul>
<li>
<t>An implementation using a routable IP address as the destination address during the initial forwarding step, before the STAMP test packet gets forwarded into the MPLS LSP or PW.</t>
</li>
<li>
<t>An implementation using a non-routable IP address as the destination address while adding both an IP header and an MPLS encapsulation in the same forwarding step.</t>
</li>
</ul>

   <t>
   The G-ACh header <xref target="RFC5586"/> with the channel type for IPv4 or IPv6 MUST immediately follow the bottom of the label stack.
   The payload contains the STAMP Session-Sender test packet defined in <xref target="RFC8972"/>.</t>

   <t>The STAMP Session-Sender test packet G-ACh header contains the following fields:</t>

   <ul>
   <li>
   <t>Version: The Version field is set to 0, as defined in <xref target="RFC4385"/>.</t>
   </li>
   <li>
   <t>Reserved: Reserved bits MUST be set to zero upon transmission and ignored upon receipt.</t>
   </li>
   <li>
   <t>Channel Type: G-ACh type for IPv4 header (0x0021) or IPv6 header (0x0057) <xref target="RFC4385"/>.</t>
   </li>
   </ul>

    </section>

    <section title="Session-Sender Test Packet without IP/UDP Header" anchor="sect-4.2"><t>
   The content of an example STAMP Session-Sender test packet for an LSP or a PW encapsulated using GAL and a
   G-ACh without an IP/UDP header is shown in <xref target="ure-stamp-sender-packet2"/>. 
        </t>

    <figure title="Example Session-Sender Test Packet with GAL and G-ACh without IP/UDP Header" anchor="ure-stamp-sender-packet2"><artwork><![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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Label(1)               | TC  |0|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    PW Label or Ultimate LSP Label     | TC  |0|      1        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    GAL                                | TC  |1|      1        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 0 0 1|Version|    Reserved   | STAMP Sender G-ACh (TBA1)     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Payload = Test Packet as specified in Section 3 of RFC 8972   |
 .           in Figure 1 and Figure 3                            .
 .                                                               .
 +---------------------------------------------------------------+
]]></artwork>
    </figure>

   <t>
   The G-ACh header <xref target="RFC5586"/> 
   with the new STAMP Session-Sender channel type (value TBA1) MUST immediately follow the bottom of the label stack.
   The payload contains the STAMP 
   Session-Sender test packet defined in <xref target="RFC8972"/>.</t>

   <t>The STAMP channel type allows the identification of the
   encapsulated STAMP payload when demultiplexing G-ACh.
   </t>

    <t>The STAMP Session-Sender test packet G-ACh header contains the following fields:</t>

    <ul>
    <li>
    <t>Version: The Version field is set to 0, as defined in <xref target="RFC4385"/>.</t>
    </li>
    <li>
    <t>Reserved: Reserved bits MUST be set to zero upon transmission and ignored upon receipt.</t>
    </li>
    <li>
    <t>Channel Type: G-ACh type for STAMP Session-Sender packet (TBA1).</t>
    </li>
    </ul>

    </section>

    </section>

    <section title="Session-Reflector Test Packet" anchor="sect-5">
    <t>
    The Session-Reflector processes and returns a received STAMP test packet as follows:
    </t>

    <ul>
    <li>
    <t>The Session-Reflector reflects the test packet to the Session-Sender using the same channel in the reverse direction of the LSP or PW on which it was received.</t>
    </li>
    <li>
    <t>The Session-Reflector transmits the reflected test packet on the same path in the reverse direction of the LSP or PW.</t>
    </li>
    <li>
    <t>The reflected test packet includes an IP/UDP header if the received Session-Sender test packet includes an IP/UDP header; otherwise, it is sent without an IP/UDP header.</t>
    </li>
    <li>
    <t>The Session-Reflector uses the PW label or ultimate LSP label in the received packet to find the reverse-direction LSP or PW context.</t>
    </li>
    <li>
    <t>If the received packet context is a PW, the Session-Reflector uses the reverse-direction PW label stack and G-ACh to transmit the Session-Reflector test packet. The reverse-direction PW label stack is determined through static configuration or the signaling protocol used to establish the PW.</t>
    </li>
    <li>
    <t>If the received packet context is an LSP, the Session-Reflector uses the reverse-direction LSP label stack, with or without a G-ACh as applicable, to transmit the Session-Reflector test packet.</t>
    </li>
    <li>
    <t>When a G-ACh is used, the Session-Reflector test packet uses the same G-ACh as the received Session-Sender test packet.</t>
    </li>
    <li>
    <t>If the Session-Reflector cannot find a reverse-direction LSP or PW context for the received test packet, it MUST discard the received packet and MUST NOT transmit a reply.</t>
    </li>
    </ul>


   <section title="Session-Reflector Test Packet with IP/UDP Header" anchor="sect-5.1"><t>
   The content of an example STAMP Session-Reflector test packet for an LSP or a PW encapsulated using a
   G-ACh and an IP/UDP header is shown in <xref target="ure-test-reply-packet1"/>. 
   </t>

   <figure title="Example Session-Reflector Test Packet with G-ACh and IP/UDP Header" anchor="ure-test-reply-packet1"><artwork><![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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Label(1)               | TC  |0|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    PW Label or Ultimate LSP Label     | TC  |1|      1        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 0 0 1|Version|    Reserved   | IPv4 (0x0021) or IPv6 (0x0057)|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | IP Header                                                     |
 .  Source IP Address                                            .
 .     = Configured on Session-Reflector                         .
 .  Destination IP Address                                       .
 .     = Source IP Address from Session-Sender Test Packet       .
 .  IPv4 Protocol or IPv6 Next Header = UDP (17)                 .
 .                                                               .
 +---------------------------------------------------------------+
 | UDP Header                                                    |
 .  Source Port = As chosen by Session-Reflector                 .
 .  Destination Port                                             .
 .     = Source Port from Session-Sender Test Packet             .
 .                                                               .
 +---------------------------------------------------------------+
 | Payload = Test Packet as specified in Section 3 of RFC 8972   |
 .           in Figure 2 and Figure 4                            .
 .                                                               .
 +---------------------------------------------------------------+
]]></artwork>
    </figure>

   <t>
   The G-ACh header <xref target="RFC5586"/> 
   with the channel type IPv4 or IPv6 MUST immediately follow the bottom of the label stack.
   The payload contains the STAMP Session-Reflector test 
   packet defined in <xref target="RFC8972"/>.
   </t>

   <t>
   The STAMP Session-Reflector test packet MUST use the IP/UDP 
   information from the received test packet when an IP/UDP header 
   is present in the received test packet.
   </t>

    <t>The STAMP Session-Reflector test packet G-ACh header contains the following fields:</t>

     <ul>
     <li>
     <t>Version: The Version field is set to 0, as defined in <xref target="RFC4385"/>.</t>
     </li>
     <li>
     <t>Reserved: Reserved bits MUST be set to zero upon transmission and ignored upon receipt.</t>
     </li>
     <li>
     <t>Channel Type: G-ACh type for IPv4 header (0x0021) or IPv6 header (0x0057) <xref target="RFC4385"/>.</t>
     </li>
     </ul>

   </section>

   <section title="Session-Reflector Test Packet without IP/UDP Header" anchor="sect-5.2">
   <t>
   The content of an example STAMP Session-Reflector test packet for an LSP or a PW encapsulated using GAL and a
   G-ACh without an IP/UDP header is shown in <xref target="ure-test-reply-packet2"/>. 
   </t>

  <figure title="Example Session-Reflector Test Packet with GAL and G-ACh without IP/UDP Header" anchor="ure-test-reply-packet2"><artwork><![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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Label(1)               | TC  |0|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    PW Label or Ultimate LSP Label     | TC  |0|      1        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    GAL                                | TC  |1|      1        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 0 0 1|Version|    Reserved   | STAMP Reflector G-ACh (TBA2)  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Payload = Test Packet as specified in Section 3 of RFC 8972   |
 .           in Figure 2 and Figure 4                            .
 .                                                               .
 +---------------------------------------------------------------+
]]></artwork>
    </figure>

   <t>
   The G-ACh header <xref target="RFC5586"/> with the new STAMP Session-Reflector
   channel type (value TBA2) MUST immediately follow the bottom of 
   the label stack.  The payload contains the STAMP 
   Session-Reflector test packet defined in <xref target="RFC8972"/>.
   </t>

   <t>The STAMP channel type allows the identification of the
   encapsulated STAMP payload when demultiplexing G-ACh.
   </t>

   <t>The STAMP Session-Reflector test packet G-ACh header contains the following fields:</t>

     <ul>
     <li>
     <t>Version: The Version field is set to 0, as defined in <xref target="RFC4385"/>.</t>
     </li>
     <li>
     <t>Reserved: Reserved bits MUST be set to zero upon transmission and ignored upon receipt.</t>
     </li>
     <li>
    <t>Channel Type: G-ACh type for STAMP Session-Reflector packet (TBA2).</t>
     </li>
     </ul>

    </section>

    </section>

    <section title="Operational Considerations" anchor="sect-6">

    <t>The operational considerations specified in Section 5 of <xref target="RFC8762"/> also apply to the procedure described in this document. 
    Further, the operation and management of performance measurement based on STAMP specified in Section 3 of <xref target="RFC8762"/>
    also apply to the procedure described in this document.
    </t>

    <t>
    Based on local policy, an operator may add the MPLS encapsulation only for STAMP test packets destined
    to addresses within the MPLS administrative domain.
    </t>

    <t>
    The encapsulation procedure defined in this document uses a G-ACh for STAMP test packets
    to follow the path of the data packets with CW.
    This assumes that intermediate nodes apply the same ECMP hashing behaviour
    to STAMP test packets with G-ACh as to data packets with CW when using the same label stack.
    </t>

    <section title="Rate Limiting" anchor="sect-6.1">

    <t>
    On both Session-Sender and Session-Reflector nodes, each STAMP test packet is punted to the control plane and is subject to rate limiting.
    Such policing on the punt path is indistinguishable from the actual loss in the network and can therefore be reported as packet loss.
    Operators should account for this when configuring punt-path rate limiters, as discussed in Section 9 of <xref target="RFC5085"/>
    and Section 5 of <xref target="RFC9780"/>.
    </t>

    </section>

    <section title="Bandwidth Rate" anchor="sect-6.2">

    <t>
    The rate at which STAMP test packets are transmitted needs to be configured
    and accounted for when provisioning the bandwidth of the LSP or PW. This
    applies to both Format-1 and Format-2 test packets, including the
    encapsulation overhead. The congestion and bandwidth usage considerations
    for VCCV applications in Section 9 of <xref target="RFC5085"/> apply to
    STAMP test packets carried over PWs, including Format-2 packets that do not
    contain UDP. Operators should also consider the additional traffic generated
    by the Session-Reflector and the rate of control packets passed to the
    control plane, as described in Section 6 of <xref target="RFC9780"/>.
    </t>

    <t>
    Because the Session-Reflector responds to each received test packet, the
    following considerations apply when provisioning bandwidth:
    </t>

    <ul>
    <li>
    <t>The reflected direction can generate a comparable test packet rate and needs
    to be considered independently when provisioning the reverse-direction LSP or PW.</t>
    </li>
    <li>
    <t>The configured test rate needs to be appropriate for the capacity of both directions.</t>
    </li>
    <li>
    <t>The configured rate needs to account for cases where the reverse direction
    has less capacity than the forward direction.</t>
    </li>
    <li>
    <t>Any rate limit or bound applied to the Session-Sender rate needs to prevent
    the corresponding reflected traffic from exceeding the reverse-direction capacity.</t>
    </li>
    </ul>

    </section>

    <section title="MTU Handling" anchor="sect-6.3">

    <t>
    The size of a STAMP test packet, including the encapsulation overhead, needs to fit within the LSP or PW MTU independently in both directions. 
    Further, the padding defined in <xref target="RFC8972"/> needs to be considered when selecting the test packet size.  
    </t>

    <t>
    A test packet with G-ACh encapsulation that exceeds the LSP or PW MTU is dropped rather than
    fragmented and can therefore appear as packet loss.  Format-1 test packets should be sized to avoid IP fragmentation.
    </t>

    </section>

    <section title="Considerations for Broken LSPs" anchor="sect-6.4">
    <t>
    Forwarding STAMP test packets on a broken LSP would cause the STAMP session to be down when all packets on the LSP are dropped.
    Otherwise, when the packets are incorrectly forwarded by MPLS or IP to the egress node (hosting the STAMP Session-Reflector), 
    it could lead to an invalid measurement of the LSP, for example, if the packets followed a different path than the LSP.
    A non-routable IPv4/IPv6 destination address, described in <xref target="sect-4.1"/>, avoids IP forwarding of
    the Session-Sender test packets to the egress node on a different path than the LSP.
    However, there is a potential risk of receiving Session-Reflector test packets from an unintended
    STAMP Session-Reflector hosted on the node where the broken LSP terminates, since the STAMP
    Session-Reflector may not know that the test packets were received due to a broken LSP.
    In this case, network analytics would detect invalid measurements reported by STAMP over a broken LSP path.
    </t>

    <t>
    Further, the destination IP address-based filtering SHOULD be provisioned on the edges of the MPLS administrative domain
    to prevent the IP-forwarded STAMP test packets for a broken LSP within the domain from leaking outside the domain.
    A non-routable IPv4/IPv6 destination address, described in <xref target="sect-4.1"/>, MAY be used in STAMP test packets to help avoid this.
    </t>

    <t>
    The considerations described above also apply to the reverse direction.  In particular, when the reverse LSP is broken,
    a Session-Reflector test packet with an IP/UDP header may be incorrectly forwarded by MPLS 
    or IP to the ingress node (hosting the STAMP Session-Sender). This is 
    because its destination address is the Session-Sender's source address, which is routable.
    The non-routable destination address technique described above does not protect the reflected packet.
    Operators SHOULD therefore apply appropriate filtering policies at the edges of the MPLS administrative domain
    to prevent reflected STAMP test packets from leaking outside the domain.
    </t>

    </section>
    </section>

    <section title="Security Considerations" anchor="sect-7">
   <t>
   The procedures defined in this document are intended for deployment in a single 
   network administrative domain.  As such, the Session-Sender address, Session-Reflector address, and IP and
   MPLS forward and return paths are provisioned by the operator for the STAMP session.
   It is assumed that the operator has verified the integrity of the IP and MPLS forward 
   and return paths used to transmit STAMP test packets.</t>

   <t>The security considerations specified in <xref target="RFC8762"/>
   and <xref target="RFC8972"/> also apply to the procedure
   described in this document. Specifically,
   the message integrity protection using HMAC, as defined in Section 4.4 of <xref target="RFC8762"/>,
   also applies to the procedure described in this document.
   The measures specified in Section 7 of <xref target="RFC8762"/> to mitigate attacks using the registered UDP port number also apply.
   </t> 

   <t>Routers that support G-ACh are subject to the same security
   considerations as defined in <xref target="RFC4385"/> and <xref target="RFC5586"/>.</t>

   <t>The message throttling mechanisms described in the security considerations in Section 10 of <xref target="RFC5085"/> 
   to protect against potential (deliberate or unintentional) attacks also apply to the procedure described in this document.
   </t>

   <t>If desired, attacks can be mitigated by performing basic validation
   checks (such as whether timestamp T2 is later than timestamp T1 in the STAMP Reference Topology shown in <xref target="ure-stamp-reference-top"/>, 
   when the Session-Sender and Session-Reflector clocks are synchronized)   
   in Session-Reflector test packets received at the Session-Sender.  The minimal state
   associated with this protocol also limits the extent of measurement
   disruption that can be caused by a corrupt or invalid test packet to a
   single test cycle.</t>

   <t>
   An attacker can send a forged STAMP test packet to the ingress or egress node of an LSP, causing 
   the STAMP session to be terminated prematurely.  To mitigate these threats, operators SHOULD filter STAMP test
   packets at the edges of the MPLS administrative domain.
   </t>

   <t>
   Furthermore, implementations SHOULD NOT assign SSIDs <xref target="RFC8972"/> in a predictable
   manner. To avoid predictability, implementations can leverage a Cryptographically Secure Pseudorandom Number Generator
   <xref target="NIST-CSPRNG" format="default"/>.
   </t>

   <t>
   The STAMP test packets received via a PW or an LSP are processed in the context of that PW or
   LSP, and the encapsulations defined in this document do not introduce a mechanism for
   cross-service OAM interactions.
   </t>

    </section>

    <section title="IANA Considerations" anchor="sect-8">
  
    <t>IANA maintains the G-ACh Type Registry 
    (see <eref target="https://www.iana.org/assignments/g-ach-parameters/g-ach-parameters.xhtml"/>).  
    IANA is requested to allocate values for the G-ACh Types for STAMP  
    from the "MPLS Generalized Associated Channel (G-ACh) 
    Types (including Pseudowire Associated Channel Types)" registry.</t>

    <texttable anchor="iana-gach-tbl" title="STAMP G-ACh Types">

    <ttcol align="left">Value</ttcol>
    <ttcol align="left">Description</ttcol>
    <ttcol align="left">Reference</ttcol>
    <c>TBA1</c>
    <c>STAMP Session-Sender G-ACh Type</c>
    <c>This document</c>
    <c>TBA2</c>
    <c>STAMP Session-Reflector G-ACh Type</c>
    <c>This document</c>
    </texttable>

    </section>


    </middle>

    <back>

    <references>
      <name>References</name>

    <references title="Normative References">
    &RFC2119; 
    &RFC3032;
    &RFC4385;
    &RFC5082;
    &RFC5085;
    &RFC5586;
    &RFC6790;
    &RFC8174;
    &RFC8762;
    &RFC8972;
    &RFC9780;
    </references>

    <references title="Informative References">
    &RFC2104;
    &RFC3931;
    &RFC4026;
    &RFC4448;
    &RFC5087;
    &RFC5462;
    &RFC5921;
    &RFC5960;
    &RFC6374;
    &RFC6658;
    &RFC7708;
    &RFC7820;
    &RFC6936;
    &RFC8085;
    &RFC9801;
    &I-D.ietf-spring-stamp-srpm-mpls; 
        

    <reference anchor="NIST-CSPRNG">
          <front>
            <title>Recommendation for Random Number Generation Using Deterministic Random Bit Generators, Revision 1</title>
            <author>
              <organization>NIST Special Publication 800-90A Revision 1</organization>
            </author>
            <date month="June" year="2015"/>
          </front>
    </reference>

    <reference anchor="IANA-IPv6-REG" target="https://www.iana.org/assignments/iana-ipv6-special-registry" quoteTitle="true" derivedAnchor="IANA-IPv6-REG">
          <front>
            <title>IANA IPv6 Special-Purpose Address Registry</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
    </reference>

    </references>

    </references>

    <section title="Acknowledgments" numbered="no" anchor="acknowledgments">

    <t>
    The authors would like to thank 
    Bharath Vasudevan, Ali Sianati, and Parag Jain for the discussions on the method to punt STAMP test packets to the control plane for processing.
    The authors would also like to thank Greg Mirsky, Loa Andersson, Li Zhang, Richard Foote (Footer), and Stewart Bryant 
    for reviewing this document and providing useful comments and suggestions. 
    Thanks to Carlos Pignataro for the PerfMetrdir review, Russ White for the early Rtgdir review,
    Russ Housley for the Gen-ART review, Vidhi Goel for the TSVART review,
    Giuseppe Fioccola for the Opsdir review,
    and Yaron Sheffer for the early Secdir review which helped improve this document.
    </t>

    </section>

    </back>

    </rfc>
