<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!ENTITY RFC0768 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3931 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3931.xml">
<!ENTITY RFC4448 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4448.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 RFC4868 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4868.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 RFC6335 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6335.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 RFC7708 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7708.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC8186 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8186.xml">
<!ENTITY RFC8545 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8545.xml">
<!ENTITY I-D.ietf-pals-ple SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pals-ple.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-mpls-stamp-pw-01" category="std" consensus="yes" ipr="trust200902">
    <!-- 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="no"?>
    <?rfc symrefs="yes"?>
    <?rfc strict="yes"?>
    <?rfc toc="yes"?>
    <front>
    <title abbrev="STAMP for MPLS PWs and LSPs">Encapsulation of Simple Two-Way Active Measurement Protocol for Pseudowires and LSPs in MPLS Networks</title>
    <author fullname="Rakesh Gandhi" initials="R." role="editor" surname="Gandhi">
    <organization>Cisco Systems, Inc.</organization>
    <address>
    <postal><street>Canada</street>
    </postal>
        <email>rgandhi@cisco.com</email>
    </address>
    </author>

    <author fullname="Patrice Brissette" initials="P." surname="Brissette">
    <organization>Cisco Systems, Inc.</organization>
        <address>
    <postal><street>Canada</street>
    </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="2025"/>
    <workgroup>MPLS Working Group</workgroup>
    <abstract><t>
    Pseudowires (PWs) and Label Switched Paths (LSPs) are used in MPLS networks for various services
    including carrying layer 2 and layer 3 data packets.
    This document describes the procedure for encapsulation of 
    the Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762 and its optional 
    extensions defined in RFC 8972 for PWs and LSPs in MPLS networks.  
    The procedure uses Generic Associated Channel (G-ACh) to encapsulate the  
    STAMP test packets with or without adding an IP/UDP header for PWs and LSPs.
   </t>
    </abstract>
    </front>

    <middle>
    <section title="Introduction" anchor="sect-1">
  
   <t>The Simple Two-way Active Measurement Protocol (STAMP) provides
   capabilities for the measurement of 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>Pseudowires (PWs) are used in MPLS networks for various services
   including carrying layer 2 and layer 3 data packets
   <xref target="RFC6658"/>.
   The PWs are bidirectional in nature. 
   The PWs can be point-to-point or point-to-multipoint. 
   The PWs may use optional Control Word (CW) as defined in the Section 3, "Generic PW MPLS Control Word" of <xref target="RFC4385"/>.
   </t>

   <t>Label Switched Paths (LSPs) are used in MPLS networks for various services
   including carrying layer 2 and layer 3 data packets
   The MPLS LSPs may use optional CW as defined in the Section 3, "Generic PW MPLS Control Word" of <xref target="RFC4385"/>.
   </t>

   <t>
   MPLS Transport Profile (MPLS-TP) <xref target="RFC5960"/> was designed to use the MPLS data plane without any changes,
   therefore when we specify STAMP over an MPLS data plane, it is equally
   applicable to the 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>
   When using STAMP for MPLS and MPLS-TP for both PWs and LSPs, 
   there are unique aspects that need to be considered concerning the CW,
   and these aspects are addressed in this document.
   </t>

   <t>
   A Generic Associated Channel (G-ACh) <xref target="RFC5586"/> provides a mechanism 
   to transport Operations, Administration, and Maintenance (OAM) and 
   other control messages over MPLS data plane. The G-ACh 
   types identify the various OAM messages being transported over the channel.
   </t> 

   <t>
   Virtual Circuit Connectivity Verification (VCCV) is used as 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>This document describes the procedure for encapsulation of the STAMP 
   defined in <xref target="RFC8762"/> and its optional extensions defined 
   in <xref target="RFC8972"/> for point-to-point PWs and LSPs in MPLS networks.  
   The procedure uses G-ACh to encapsulate 
   STAMP test packets with or without an IP/UDP header for PWs and LSPs. 
   This document defines two new G-ACh types when using STAMP without an IP/UDP header, those are 
   PW demultiplexer agnostic and hence applicable to both 
   PWs and Layer 2 Tunneling Protocol version 3 (L2TPv3) PW demultiplexers. 
   This document uses existing G-ACh types for IPv4 and IPv6 when using STAMP with an IP/UDP header for PWs and LSPs.
   </t>

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

   <t>
   The STAMP test packets need to be transmitted with the same 
   label stack that is used by the PW and LSP to ensure proper validation 
   of underlay path taken by the actual data traffic. Also, the test packets need 
   to follow the same ECMP underlay path taken by the PW and LSP data traffic in the network. 
   The PW data traffic may be encapsulated using CW <xref target="RFC4385"/> with an IP header.
   As such, the STAMP test packets need to be transmitted over the PW using G-ACh and an IP/UDP header.
   </t>

   <t>
   The data traffic over L2-Specific Sublayer (L2SS) as used in L2TP PW carry CW but do not carry an IP/UDP header.
   As such, the STAMP packets need to be transmitted over L2-Specific Sublayer (L2SS) as used in L2TP PW 
   using G-ACh without any IP/UDP header (as raw STAMP payload).
   </t>

   <t>
   The Private Line Emulation (PLE) <xref target="I-D.ietf-pals-ple"/> 
   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, the STAMP test packets need to be transmitted using the same label stack 
   including VPWS PW Label <xref target="I-D.ietf-pals-ple"/> as the PLE traffic 
   and encapsulated using G-ACh but without any IP/UDP header.
   This allows the STAMP test packets to experience the same forwarding 
   behaviour, follow the same underlay path as the PLE traffic and avoid different ECMP behavior on intermediate nodes.</t> 

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

   <t>
   The G-ACh provides support for OAM Control Channel associated 
   with the MPLS Transport Profile (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 to demultiplex OAM Control Channel for MPLS-TP.
   </t>
   
   <t>
   The requirements for the encapsulation of 
   the STAMP test packets for the PWs and LSPs in MPLS networks can be summarized as follows:
   </t>

   <t>
   o    The G-ACh MUST support STAMP test packets with an IP/UDP header.
   </t>

   <t> 
   o    The G-ACh MUST support STAMP test packets without an IP/UDP header. 
   </t>

   <t> 
   o    The G-ACh MUST support STAMP to demultiplex Control Channel. 
   </t>

   <t> 
   o    The Session-Sender test packets MUST follow the underlay path taken by the data traffic that is using CW.
   </t>

   <t> 
   o    The Session-Sender test packets MUST follow the same ECMP underlay path taken by the data traffic that is using CW and Entropy Label defined in <xref target="RFC6790"/>.
   </t>

   <t> 
   o    The Session-Sender test packets MUST follow the same ECMP underlay path taken by the data traffic that is using CW but not using Entropy Label defined in <xref target="RFC6790"/>.
   </t>

   <t> 
   o    The Session-Reflector test packets MAY follow the reverse underlay path taken by Session-Sender test packets.
   </t>

   <t> 
   o    The Session-Reflector test packets MAY follow the same reverse ECMP underlay path taken by Session-Sender test packets.
   </t>

   <t>
   This document concerns with the STAMP operation for the P2P Single-Segment PWs (SS-PWs). 
   The procedure for STAMP operation for point-to-multipoint (P2MP) PWs is outside the scope of this document.
   </t>

   </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: </t>
    <list style="hanging">
    <t> 1. MPLS PW Data Traffic (with CW and IP header) </t>
    <t> 2. MPLS-TP PW Data Traffic (with CW and IP header) </t>
    <t> 3. MPLS LSP Data Traffic (with IP header) </t>
    </list>
    
   <t>Examples of MPLS data traffic use cases for STAMP test packets without IP/UDP headers: </t>
    <list style="hanging">
    <t> 1. MPLS Ethernet PW Data Traffic <xref target="RFC4448"/>  </t>
    <t> 2. L2-Specific Sublayer (L2SS) used in L2TPv3 PW Data Traffic <xref target="RFC3931"/> </t>
    <t> 3. Private Line Emulation <xref target="I-D.ietf-pals-ple"/> PW Data Traffic </t>
    <t> 4. TDM over IP <xref target="RFC5087"/>  PW Data Traffic (with no IP header) </t>
    <t> 5. MPLS-TP LSP Data Traffic </t>
    </list>

    </section>

   </section>

   <section title="Conventions Used in This Document" anchor="sect-2">
       
   <section title="Requirements Language" anchor="sect-2.1">
        <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 title="Abbreviations" anchor="sect-2.2"><t>
   ECMP: Equal Cost Multi-Path.</t>

    <t>
   G-ACh: Generic Associated Channel.</t>

    <t>
   GAL: G-ACh Label.</t>

    <t>
   HMAC: Hashed Message Authentication Code.</t>

    <t>
   MPLS: Multiprotocol Label Switching.</t>

    <t>
   OAM: Operations, Administration, and Maintenance.
    </t>

    <t>
   PLE: Private Line Emulation.</t>

    <t>
   PW: Pseudowire.</t>

    <t>
   SHA: Secure Hash Algorithm.</t>

    <t>
   STAMP: Simple Two-way Active Measurement Protocol.</t>

    <t>
   TC: Traffic Class.</t>

    <t>
   TTL: Time-To-Live.</t>

   </section>

   <section title="STAMP Reference Topology" anchor="sect-2.3">
   <t>
   In the STAMP reference topology shown in Figure 1, 
   there exists a PW or an LSP 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 test packet.  The Session-Reflector reply test packet may be transmitted 
   to the STAMP Session-Sender node S1 on the same path (same set
   of links and nodes) in the reverse direction of 
   the path taken towards the Session-Reflector node R1.
   </t>

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

   <figure title="STAMP Reference Topology using PW and LSP" 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>
    </section>

   </section>
   
    <section title="Overview" anchor="sect-3"><t>
    The STAMP Session-Sender and Session-Reflector test packets defined 
    in <xref target="RFC8972"/> are encapsulated and transmitted over the PWs in MPLS networks.  
    The base STAMP test packets can be encapsulated using an IP/UDP 
    header and may use destination UDP port 862 <xref target="RFC8762"/>.
    The source UDP port is chosen by the Session-Sender.
    </t> 

     <section title="G-ACh Types for STAMP" anchor="sect-3.1">
    <t>There are two ways in which STAMP test packets may be encapsulated over a 
    G-ACh, either using an IP/UDP header, referred to as Format1 or without using an IP/UDP header, referred to as Format2.
    </t>

    <t>For encapsulating the STAMP test packets over a G-ACh with IP/UDP headers (in Format1), 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 discriminate the test packets.
    The IP version (IPv4 or IPv6) MUST match the IP version used for
    for the PWs and LSPs being measured. 
    </t>

    <t>For encapsulating the STAMP test packets over a G-ACh without adding IP/UDP headers (in Format2),
    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 them.
    </t>

    </section>

    <section title="Using STAMP for PWs and LSPs" anchor="sect-3.2">
    <t>
    The STAMP test packets are encapsulated with MPLS 
    header using the same label stack as the PW data traffic (including the PW label) and G-ACh header 
    (instead of CW used by the data traffic). 
    The encapsulation allows the STAMP test packets to follow the 
    same path as the PW data traffic, and provide the same ECMP behaviour on the intermediate nodes.
    </t>

    <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, and hence the IPv4 and MPLS TTL and IPv6 Hop Limit MUST be set to 255.
    </t>

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

    <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 when measuring PW with CW to avoid the different ECMP hashing behaviour.
    </t>

    <t>
    The method for "TTL Expiry VCCV (Type 3)" defined in Section 5.1.3 of <xref target="RFC5085"/> 
    allows to terminate the OAM messages on the remote PE endpoint nodes.
    This method is applied to the STAMP test packets to force test packets 
    to be processed on Session-Sender and Session-Reflector control-planes by adding the PW label with TTL value 1.
    </t>

    <t>
    The VCCC Type 2 is also referred to as 'MPLS Router Alert Label" <xref target="RFC5085"/>. 
    This method could result in a different Equal Cost Multi-Path (ECMP) hashing behavior, 
    and thus result in the STAMP packets taking a path which differs from that of the actual data traffic under test
    <xref target="RFC5085"/>. 
    Hence, the VCCV Type 2 is not supported for STAMP for measuring the PW traffic.
    </t>

    <t>
    The procedure to encapsulate STAMP packets for PWs, is also applicable to MPLS LSPs and MPLS-TP LSPs when using CW.
    For measuring the data traffic over MPLS LSPs using an IP header, STAMP test packet in Format1 is transmitted.
    For measuring the data traffic over MPLS-TP LSPs, not using an IP header, 
    STAMP test packet in Format2 is transmitted with TTL value 1 with the ultimate LSP label in the MPLS header.
    </t>

    <t>
    The G-ACh label (GAL) <xref target="RFC5586"/> along with Generic Associated Channel (G-ACh) types defined in this document  
    can be used with STAMP test packets without an IP/UDP header (in Format2), similar to the case of MPLS-TP LSP performance measurement defined in <xref target="RFC6374"/>. 
    </t>

    </section>

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

    <t>Control Channel Types defined in <xref target="RFC5085"/> are applicable to STAMP Test Packets for PWs and LSPs as follows: </t>

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

    <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>Format1 (IP/UDP Headers)</c>
    <c>IPv4 G-ACH (0x21) and IPv6 G-ACH (0x57)</c>

    <c>Type 1</c>
    <c>In-band: Control Word with 0001b as first nibble</c>
    <c>Format2 (No IP/UDP Headers)</c>
    <c>G-ACH Type STAMP G-ACH (TBD1/TBD2)</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 (0x21) and IPv6 G-ACH (0x57)</c>

    <c>Type 3</c>
    <c>TTL Expiry: Label with TTL as 1</c>
    <c>Format2 (No IP/UDP Headers)</c>
    <c>G-ACH Type STAMP G-ACH (TBD1/TBD2)</c>

    </texttable>

    </section>

 
    </section>

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

    <t>
   The STAMP Session-Sender test packets are transmitted for a PW or an LSP 
   using an MPLS header with or without an IP/UDP header.
   The Session-Sender STAMP test packets are transmitted using the label stack of the PW, including the PW label of the PW and G-ACh.
   The Session-Sender STAMP test packets are transmitted using the label stack of the LSP as well as 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 a PW or an LSP encapsulated using a  
   G-ACh and an IP/UDP header is shown in Figure 2. 
   </t>

    <figure title="Example Session-Sender Test Packet with 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  |S|      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 | 862    .
 .                                                               .
 +---------------------------------------------------------------+
 | Payload = Test Packet as specified in Section 3 of RFC 8972   |
 .           in Figure 1 and Figure 3                            .
 .                                                               .
 +---------------------------------------------------------------+
 | Optional STAMP Extension TLVs                                 |
 .                                                               .
 +---------------------------------------------------------------+
]]></artwork>
    </figure>

   <t>
   The G-ACh header <xref target="RFC5586"/> with 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 following fields:</t>

   <t><list style="hanging" hangIndent="2">

   <t hangText="Version:">
     The Version field is set to 0, as defined in <xref target="RFC4385"/>.
   </t>
  
    <t hangText="Reserved:">
      Reserved Bits MUST be set to zero upon transmission and ignored upon receipt.
   </t>

    <t hangText="Channel Type:">
      G-ACh type for IPv4 header (0x0021) or IPv6 header (0x0057) <xref target="RFC4385"/>. 
    </t>

    </list>
    </t>

    </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 a PW or an LSP encapsulated using a  
   G-ACh without an IP/UDP header is shown in Figure 3. 
        </t>

    <figure title="Example Session-Sender Test Packet 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  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    PW Label or Ultimate LSP Label     | TC  |1|      1        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 0 0 1|Version|    Reserved   | STAMP Sender G-ACh (TBD1)     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Payload = Test Packet as specified in Section 3 of RFC 8972   |
 .           in Figure 1 and Figure 3                            .
 .                                                               .
 +---------------------------------------------------------------+
 | Optional STAMP Extension TLVs                                 |
 .                                                               .
 +---------------------------------------------------------------+
]]></artwork>
    </figure>

   <t>
   The G-ACh header <xref target="RFC5586"/> 
   with new STAMP Session-Sender channel type (value TBD1) 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
   encased STAMP payload when demultiplexing G-ACh.
   </t>

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

    <t><list style="hanging" hangIndent="2">

    <t hangText="Version:">
       The Version field is set to 0, as defined in <xref target="RFC4385"/>.
    </t>
  
    <t hangText="Reserved:">
       Reserved Bits MUST be set to zero upon transmission and ignored upon receipt.
    </t>

    <t hangText="Channel Type:">
       G-ACh type for STAMP Session-Sender packet (TBD1). 
    </t>

    </list>
    </t>

    </section>

    </section>

    <section title="Session-Reflector Test Packet" anchor="sect-5">
    <t>
   The STAMP Session-Reflector reflects the test packet back to the
   Session-Sender using the same channel in the reverse direction of the
   PW or the LSP on which it was received.  The Session-Reflector has enough
   information to reflect the test packet received by it to the Session-
   Sender using the PW or the LSP context.
   </t>
   <t>
   The STAMP Session-Reflector reply test packet is transmitted on the same path 
   in the reverse direction of the PW or the LSP. The STAMP test packet can 
   be transmitted using an MPLS header with or without an IP/UDP header.
   The Session-Reflector test packet is sent with an IP/UDP header 
   if the Session-Sender test packet is received with an IP/UDP 
   header, otherwise, it is sent without an IP/UDP header.
   </t>
   <t>
   The Session-Reflector can use the PW label or the ultimate LSP label in the received packet to find the PW or the LSP in the reverse direction.
   The Session-Reflector uses the label stack of that PW or LSP as well as G-ACh, 
   to transmit the Session-Reflector test packet.
   The Session-Reflector test packet uses the same G-ACh as the received in the Session-Sender test packet.
   </t>

   <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 a PW or an LSP encapsulated using a 
   G-ACh and an IP/UDP header is shown in Figure 4. 
   </t>

   <figure title="Example Session-Reflector Test Packet with 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  |S|      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                                            .
 .     = Destination IP Address from Session-Sender Test Packet  . 
 .  Destination IP Address                                       .
 .     = Source IP Address from Session-Sender Test Packet       .
 .  IPv4 Protocol or IPv6 Next header = UDP (17)                 .
 .                                                               .
 +---------------------------------------------------------------+
 | UDP Header                                                    |
 .  Source Port = 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                            .
 .                                                               .
 +---------------------------------------------------------------+
 | STAMP TLVs from Session-Sender Test Packet                    |
 .                                                               .
 +---------------------------------------------------------------+
]]></artwork>
    </figure>

   <t>
   The G-ACh header <xref target="RFC5586"/> 
   with 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 reply 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 following fields:</t>

    <t><list style="hanging" hangIndent="2">

    <t hangText="Version:">
       The Version field is set to 0, as defined in <xref target="RFC4385"/>.
    </t>
  
    <t hangText="Reserved:">
       Reserved Bits MUST be set to zero upon transmission and ignored upon receipt.
    </t>

    <t hangText="Channel Type:">
       G-ACh type for IPv4 header (0x0021) or IPv6 header (0x0057) <xref target="RFC4385"/>. 
    </t>

    </list>
    </t>

   </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 a PW or an LSP encapsulated using a 
   G-ACh without an IP/UDP header is shown in Figure 5. 
   </t>

   <figure title="Example Session-Reflector Test Packet 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  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    PW Label or Ultimate LSP Label     | TC  |1|      1        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 0 0 1|Version|    Reserved   | STAMP Reflector G-ACh (TBD2)  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Payload = Test Packet as specified in Section 3 of RFC 8972   |
 .           in Figure 2 and Figure 4                            .
 .                                                               .
 +---------------------------------------------------------------+
 | STAMP TLVs from Session-Sender Test Packet                    |
 .                                                               .
 +---------------------------------------------------------------+
]]></artwork>
    </figure>

   <t>
   The G-ACh header <xref target="RFC5586"/> with new STAMP Session-Reflector  
   channel type (value TBD2) 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
   encased STAMP payload when demultiplexing G-ACh.
   </t>

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

    <t><list style="hanging" hangIndent="2">

    <t hangText="Version:">
       The Version field is set to 0, as defined in <xref target="RFC4385"/>.
    </t>
  
    <t hangText="Reserved:">
       Reserved Bits MUST be set to zero upon transmission and ignored upon receipt.
    </t>

    <t hangText="Channel Type:">
       G-ACh type for STAMP Session-Reflector packet (TBD2). 
    </t>

    </list>
    </t>

    </section>

    </section>

    <section title="Security Considerations" anchor="sect-6">
   <t>
   The procedures defined in this document is intended for deployment in a single 
   network administrative domain.  As such, the Session-Sender address, Session-Reflector address, and 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 apply to the procedure described in this document.
   </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 Security Section of <xref target="RFC5085"/> 
   also apply to the procedure described in this document.
   </t>

      <t>STAMP uses the well-known UDP port number that could become 
   a target of denial of service (DoS) or could
   be used to aid on-path attacks.
   Thus, the security considerations and measures to mitigate the 
   risk of the attack documented in 
   <xref target="RFC8545" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8545#section-6" derivedContent="RFC8545"/>
   equally apply to the STAMP extensions in this document.</t>

      <t>If desired, attacks can be mitigated by performing basic validation
   checks of the timestamp fields (such as T2 is later than T1 in the STAMP Reference Topology shown in Figure 1  
   in received reply test packets at the Session-Sender.  The minimal state
   associated with these protocols also limit the extent of measurement
   disruption that can be caused by a corrupt or invalid test packet to a
   single test cycle.</t>

    </section>

    <section title="IANA Considerations" anchor="sect-7">
  
    <t>IANA maintains 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 "MPLS Generalized Associated Channel (G-ACh) 
    Types (including Pseudowire Associated Channel Types)" registry.</t>

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

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

    </section>


    </middle>

    <back>
    <references title="Normative References">
    &RFC2119; 
    &RFC4385;
    &RFC5085;
    &RFC5586;
    &RFC8174;
    &RFC8762;
    &RFC8972;
    </references>
    <references title="Informative References">
    &RFC3931;
    &RFC4448;
    &RFC5082;
    &RFC5087;
    &RFC5921;
    &RFC5960;
    &RFC6374;
    &RFC6658;
    &RFC6790;
    &RFC7708;
    &RFC8545;
    &I-D.ietf-pals-ple;
    </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 method to punt STAMP test packets to control-plane for processing.
    The authors would also like to thank Greg Mirsky, Loa Andersson, and Stewart Bryant 
    for reviewing this document and providing useful comments and suggestions. 
    </t>
    </section>

    </back>

    </rfc>
