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

<front>
    <title abbrev="Update of the STAMP CoS Extension">Update of the Simple Two-way Active Measurement Protocol (STAMP) Class-of-Service Optional Extension</title>
    <seriesInfo name="Internet-Draft" value="draft-mirsky-ippm-stamp-cos-ext-00"/>
    <author fullname="Greg Mirsky" initials="G." surname="Mirsky">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country/>
        </postal>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    <date year="2025"/>
    <area>Transport</area>
    <workgroup>Network Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>IPPM</keyword>
    <keyword>Performance Measurement </keyword>
    <abstract>
      <t>
   This document describes an optional extension to the Class of Service
   monitoring functionality of Simple Two-way Active Measurement
   Protocol that enables the upstream monitoring of the Explicit
   Congestion Notification and thus updates RFC 8972.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
<xref target="RFC8972"/> defined several extensions to Simple Two-way Active Measurement Protocol (STAMP).
Among those is Class of Service TLV that enables monitoring of the Differential Services Code Point (DSCP) marking
in downstream and upstream directions. Also, Class of Service TLV supports downstream monitoring of the Explicit Congestion Notification (ECN).
Experience deploying STAMP and its extensions
   demonstrated that it is helpful to an operator to monitor ECN's consistency in the upstream direction. This specification
   defines the extension of the Class of Service TLV in a backward
   compatible manner to support monitoring of ECN in the upstream
   direction of the STAMP test session.
      </t>
    </section>
    <section numbered="true" toc="default">
      <name>Conventions Used in This Document</name>
      <section numbered="true" toc="default">
        <name>Acronyms</name>
        <t>CoS         Class of Service</t>
        <t>DSCP   Differentiated Services Code Point</t>
        <t>ECN   Explicit Congestion Notification</t>
        <t>STAMP   Simple Two-way Active Measurement Protocol</t>
      </section>
      <section numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
   "MAY", and "OPTIONAL" in this document are to be interpreted as
   described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> 
   when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section anchor="stamp-extension-section" numbered="true" toc="default">
      <name>TLV Extensions to STAMP</name>

      <section anchor="cos-info-section" numbered="true" toc="default">
        <name>Class of Service TLV</name>
        <t>
  The STAMP Session-Sender MAY include  a Class of Service (CoS) TLV in the STAMP test packet.
  The format of the CoS TLV is presented in <xref target="cos-tlv-figure" format="default"/>.

        </t>
        <figure anchor="cos-tlv-figure">
          <name>Class of Service TLV</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[    
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |STAMP TLV Flags|    CoS Type   |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   DSCP1   |   DSCP2   |ECN| RP|REC|       Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t> 
         where fields are defined as the following:
        </t>
        <ul spacing="normal">
          <li>STAMP TLV Flags - is an eight-bit-long field. Its format is presented in Section 4 of <xref target="RFC8972"/>.</li>
          <li>CoS (Class of Service) Type - is a one-octet-long field, the value MUST be set to 4.</li>
          <li>Length - two-octet-long field, set equal to the value 4.</li>
          <li>DSCP1 - The Differentiated Services Code Point (DSCP) intended by the Session-Sender
        to be used as the DSCP value of the reflected test packet.</li>
          <li>DSCP2 - The received value in the DSCP field at the ingress of the Session-Reflector.</li>
          <li>ECN - is a two-bit-long field. The received value in the ECN field at the ingress of the Session-Reflector.</li>
          <li>RP (Reverse Path) - is a two-bit-long field. A Session-Sender MUST set the value of the RP field to 0 on transmission.</li>
          <li>REC - is a two-bit-long field. The value intended by the Session-Sender to be used as the ECN value of the reflected test packet.</li>
          <li>Reserved - 14-bit-long field. It MUST be zeroed on transmission and ignored on receipt.</li>
        </ul>
        <t>
Processing and handling of DSCP1, DSCP2, and ECN fields as defiend in Section 4.4 of <xref target="RFC8972"/>.
A system that supports this
   specification MUST set the ECN value in the data plane encapsulation of the reflected STAMP test packet to the value of the REC field.
   Furthermore, such a system MUST add 0b10 to the value of the RP field in
   the Class of Service TLV in the reflected test packet. As a
   result, the Session-Sender can detect whether the recommended values for DSCP and ECN fields in the reflected packets
   were used by inspecting the value of the RP field in the received reflected test packet.
        </t>
        <t>
        The extended Class of Service TLV defined in this dradft s backward compatible with the specification in Section 4.4 of <xref target="RFC8972"/>.
        Consider a case when implementation that supports this specification performs as Session-Sender, 
        nd the intended Session-Reflector support of the Class of Service TLV is according to Session 4.4 of <xref target="RFC8972"/>.
        If the operator requires monitoring ECN in the upstream direction, the value of the REC field will be set to a non-zero value.
        Because the Session-Reflector would treat the REC field as part of the Reserved field and ignore its value,
        the Session-Reflector would not add 0b10 to the value of the RP field in the reflected STAMP packet. Consequently,
        the Session-Sender will determine that the ECN value in the IP/UDP encapsulation of the reflected test packet was not set to the requested value.
        </t>
      </section>
      <!--
      <section anchor="follow-up-tlv" numbered="true" toc="default">
        <name>Follow-up Telemetry TLV</name>
        <t>
    A Session-Reflector might be able to put in the Timestamp field only an "SW Local"
    (see <xref target="timestamp-method-new-tbl" format="default"/>) timestamp. But the hosting
    system might provide a timestamp closer to the start of the actual packet transmission
    even though it is not possible to deliver the information to the Session-Sender in time for the packet itself.
    This timestamp might nevertheless be important for the Session-Sender, as it
    improves the accuracy of measuring network delay by minimizing the impact of egress queuing delays
    on the measurement.
        </t>
        <t>
  A STAMP Session-Sender MAY include the Follow-up Telemetry TLV to
   request information from the Session-Reflector. The Session-Sender
   MUST set the Follow-up Telemetry Type and Length fields to their appropriate values.
   The Sequence Number and Timestamp fields MUST be zeroed on transmission by the Session-Sender
   and ignored by the Session-Reflector upon receipt of the STAMP test packet that includes the Follow-up Telemetry TLV.
   The Session-Reflector MUST validate the Length value of the STAMP
   test packet.  If the value of the Length field is invalid, the
   Session-Reflector MUST zero the Sequence Number and Timestamp fields and set the M flag in the STAMP TLV Flags field
   in the reflected packet. If the Session-Reflector is in
   stateless mode (defined in Section 4.2 <xref target="RFC8762" format="default"/>),
   it MUST zero the Sequence Number and Timestamp fields.
        </t>
        <figure anchor="follow-up-tlv-fig">
          <name>Follow-up Telemetry TLV</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[    
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |STAMP TLV Flags| Follow-up Type|           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sequence Number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Follow-up Timestamp                      |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Timestamp M  |                     Reserved                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t> 
        where fields are defined as follows:
        </t>
        <ul spacing="normal">
          <li>
            <t>STAMP TLV Flags - is an eight-bit-long field. Its format presented in <xref target="tlv-flags-format" format="default"/>.</t>
          </li>
          <li>
            <t>Follow-up (Telemetry) Type - is a one-octet-long field, value TBA7 allocated by IANA <xref target="iana-stamp-tlv-registry" format="default"/>.</t>
          </li>
          <li>
            <t>Length - two-octet-long field, set equal to the value 16 octets.</t>
          </li>
          <li>
            <t>
        Sequence Number - four-octet-long field indicating the sequence
number of the last packet reflected in the same STAMP-test session.
Since the Session-Reflector runs in the stateful mode
(defined in Section 4.2 <xref target="RFC8762" format="default"/>),
it is the Session-Reflector’s Sequence Number of the previous reflected packet.
</t>
          </li>
          <li>
            <t>
     Follow-up Timestamp - eight-octet-long field, with the format indicated by
      the Z flag of the Error Estimate field of the STAMP base packet, which is contained
      in this reflected test packet transmitted by a Session-Reflector,
      as described in Section 4.2.1 <xref target="RFC8762" format="default"/>.
      It carries the timestamp when the reflected packet with the
      specified sequence number was sent.
</t>
          </li>
          <li>
            <t>
Timestamp M(ode) - one-octet-long field that characterizes the
method by which the entity that transmits a reflected STAMP packet obtained the Follow-up Timestamp.
The value is one of those listed in <xref target="timestamp-method-new-tbl" format="default"/>.
</t>
          </li>
          <li>
            <t> Reserved - three-octet-long field. Its value MUST be zeroed on transmission and ignored on receipt.</t>
          </li>
        </ul>
    </section>
    -->
    </section>
    
    <section anchor="iana-consider" numbered="true" toc="default">
      <name>IANA Considerations</name>
        <t>
  This document makes no requests to IANA.
        </t>
    </section>
    
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
This document extends the functionality of the Class of Service TLV (<xref target="RFC8972"/>) and inherits all the security considerations
applicable to the base STAMP specification <xref target="RFC8762"/> and <xref target="RFC8972"/>.
</t>

      <t>
     As this specification defined the mechanism to test ECN mapping,
   this document inherits all the security considerations discussed in <xref target="RFC2474" format="default"/>.
   Monitoring and optional control of ECN for a reflected STAMP test packet using the extended CoS TLV may be used across the Internet so that
     the Session-Sender and the Session-Reflector are located in different domains.
      </t>
    </section>
    <section numbered="true" toc="default">
      <name>Acknowledgments</name>
      <t>
 TBA
      </t>
    </section>
   </middle>
   
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>

      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8762.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8972.xml"/>
      </references>
      
      <references>
        <name>Informative References</name>

      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml"/>

      </references>
    </references>
  </back>
</rfc>
