<?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-asymmetrical-pkts-03" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.6.0 -->
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<front>
    <title abbrev="Asymmetrical Packets in STAMP">Performance Measurement with Asymmetrical Packets in STAMP</title>
    <seriesInfo name="Internet-Draft" value="draft-mirsky-ippm-asymmetrical-pkts-03"/>
    
    <author initials="G." surname="Mirsky" fullname="Greg Mirsky">
      <organization>Ericsson</organization>
      <address>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    
     <author fullname="Ernesto Ruffini" initials="E." surname="Ruffini">
      <organization>OutSys</organization>
      <address>
        <postal>
          <street>via Caracciolo, 65</street>
          <city>Milano</city>
          <code>20155</code>
          <country>Italy</country>
        </postal>
        <email>eruffini@outsys.org</email>
      </address>
    </author>
    
     <author fullname="Henrik Nydell" initials="H." surname="Nydell">
      <organization>Accedian Networks</organization>
      <address>
        <email>hnydell@cisco.com</email>
      </address>
    </author>
    
  	<author initials="R." surname="Foote" fullname="Richard Foote">
		<organization>Nokia</organization>
		<address>
			<email>footer.foote@nokia.com </email>
		</address> 
	</author>
    
    <date year="2024"/>
    
    <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 a Simple Two-way Active Measurement Protocol (STAMP)
that enables the use of STAMP test and reflected packets of variable length during a single STAMP test session.
In some use cases, the use of asymmetrical test packets allow for the creation of more realistic flows of test packets and,
thus, a closer approximation between active performance measurements and conditions experienced by the monitored application.
	 </t>
	 <t>
       Also, the document includes an analysis of challenges related to performance monitoring in a multicast network.
       It defines procedures and STAMP extensions to
      achieve more efficient measurements with a lesser impact on a network.
        </t>
    </abstract>
  </front>
  
  <middle>
    <section anchor="intro" title="Introduction">
    <t>
    Simple Two-way Active Measurement Protocol (STAMP) <xref target="RFC8762"/> defined the STAMP base functionalities.
    STAMP Protocol Optional Extensions <xref target="RFC8972"/> introduces a TLV structure that allows
    the Session-Sender to include optional instructions for Session-Reflector.
    New STAMP TLVs can be defined to support the scenarios in <xref target="RFC7497"/>,
    which discusses the coordination of messaging between the source
    and destination to help deliver one of the fundamental principles
    of IP performance metric measurements, minimizing the test traffic effect on user flows. In some scenarios,
    e.g., rate measurements discussed in <xref target="RFC7497"/>, it is beneficial not only
    to use a variable size of the test packets transmitted downstream while controlling length,
    number, and interpacket interval for reflected test packets.
    </t>
        <t>
        Measurement of performance metrics in a multicast network using an active measurement method
        has specific challenges compared to what operators experience monitoring in a unicast network.
        This document analyzes these challenges, and defines procedures and STAMP extensions to
        achieve more efficient measurements with a lesser impact on a network.
        </t>
        
       <section anchor="acronyms-sec" numbered="true" toc="default">
        <name>Abbreviations</name>
        <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="problem-statement" numbered="true" toc="default">
      <name>Problem Statement</name>
      <t>
STAMP (<xref target="RFC8762"/>) allows for variable lengths of the test packets transmitted by a Session-Sender.
<xref target="RFC7497"/> analyses rate measurement scenarios where it is beneficial to enable control
of the responding node reflecting the received test packet with a different length and, in some cases,
with a series of equally timed test packets.
</t>
<t>
Measuring performance metrics using an active method in a multicast network
is another use case where the ability to control the behavior of the Session-Reflector
is beneficial. In some environments, an operator may request that reflected packets
be as small as the protocol allows. In another scenario, an operator may request the suppression of test packet reflection altogether.
Another scenario may need the ability to define a subset of nodes processing received test packets.
</t>
    </section>
  -->
    
      <section anchor="reflected-cntrl-tlv" numbered="true" toc="default">
      <name>Reflected Test Packet Control TLV</name>
      <t>
      This document defines a new optional STAMP extension, Reflected Test Packet Control TLV.
The format of the Reflected Test Packet Control TLV is presented in <xref target="reflected-cntrl-tlv-fig"/>.
      </t>
      
        <figure anchor="reflected-cntrl-tlv-fig">
        <name>Reflected Test Packet Control TLV Format</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|      Type     |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  Length of the Reflected Packet               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                 Number of the Reflected Packets               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Interval Between the Reflected Packets            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                            Sub-TLVs                           ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>
  The interpretation of the fields is as follows:
      </t>
      <ul empty="true" spacing="normal">
        <li>STAMP TLV Flags is a one-octet field.</li>
        <li>Type is a one-octet field that identifies the Reflected Test Packet Control TLV.
        IANA is requested (<xref target="iana-pkt-cntrl-tlv"/>) to assign (TBA1) value.</li>
        <li>Length is a two-octet field. The value is variable, not smaller than 12 octets.</li>
        <li>Length of the Reflected Packet is a four-octet field.
        The value is an unsigned integer that is the requested length of a reflected test packet in octets.</li>
        <li>Number of the Reflected Packets is a four-octet field. The value is an unsigned integer that is the number of reflected test packets
        the Session-Reflector is requested to transmit in response to receiving a STAMP test packet with
        the Reflected Test Packet Control TLV.</li>
        <li>Interval Between the Reflected Packets is a four-octet field. The value is an unsigned integer set to the interval in nanoseconds between
        the transmission of the consecutive reflected test packets in response to receiving
        a STAMP test packet with the Reflected Test Packet Control TLV.</li>
        <li> Sub-TLVs - an optional field that includes additional information communicated by a Session-Sender.</li>
      </ul>
      <t>
   A Session-Sender MAY include the Reflected Test Packet Control TLV in a STAMP
   test packet. If the received STAMP test packet includes the Reflected Test Packet Control TLV,
   the Session-Reflector MUST transmit a sequence of reflected test packets according to the following rules:
   </t>
         <ul empty="true" spacing="normal">
         <li>The length of the reflected test packet MUST be the largest of the length
         of the Session-Reflector packet in the mode matching mode of the received STAMP test packet,
         as defined in Section 4.3 of <xref target="RFC8762"/> with all the present in the received STAMP test packet
         STAMP extension TLVs <xref target="RFC8972"/>, excluding the Extra Padding TLV, present in the received STAMP test packet,
         and the value in the Length of the Reflected Packet aligned at a four-octets boundary.
         The Session-Reflector MUST use the Extra Padding TLV (Section 4.1 of <xref target="RFC8972"/>)
         to increase the length of the reflected test packet.</li>
        <li>The number of reflected test packets in the sequence MUST equal to the value of the Number of the Reflected Test Packets.</li>
  <li>If the value of the Number of the Reflected Packets is larger than one,
the interval between the transmission of two consecutive reflected packets in the sequence MUST be equal to the value
in the Interval Between the Reflected Packets in nanoseconds.
If a Session-Reflector that recognizes the Reflected Test Control TLV cannot sustain 
the transmission of reflected test packets at the interval requested
in the Interval Between the Reflected Packets field on the received TLV,
the Session-Reflector MUST set the U flag <xref target="RFC8972"/> to 1, and MUST transmit a single reflected packet.
Otherwise, the Session-Reflector MUST set the U flag to 0 in each of reflected test packets.
</li>
  <li>If the value of the Number of the Reflected Packets equals zero, then the Session-Reflector MUST NOT send a reflected packet.
  Processing of the received STAMP test packet with the Reflected Test Packet Control TLV,
  in which the value of the Number of the Reflected Packets equals zero, is according to the local nodal policy.
  The received STAMP test packet is discarded if no policy to handle these cases is configured on the node.</li>
  <li>Each reflected test packet in the sequence is formed according to Section 4.3 of <xref target="RFC8762"/>.</li>
  </ul>
  
        <section anchor="address-group-sub-tlv" numbered="true" toc="default">
      <name>Address Group Sub-TLVs</name>
 
        <section anchor="l2-addr-grp-sub-tlv" numbered="true" toc="default">
      <name>Layer 2 Address Group Sub-TLV</name>
     <t>
      Layer 2  Address Group sub-TLV:  A 16-octet sub-TLV that includes the
      EUI-48 Address Group Mask and EUI-48 Address Group.  The Type
      value is TBA2 (<xref target="iana-l2-l3-sub-tlv"/>).  The value of the Length field MUST be equal to 12.
      The format of Layer 2 Address Group sub-TLV is presented in <xref target="l2-addr-grp-sub-tlv-fig"/>.
      </t>
        <figure anchor="l2-addr-grp-sub-tlv-fig">
        <name>Layer 2 Address Group Sub-TLV Format</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     EUI-48 Address Group Mask                 |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|                               |
|                       EUI-48 Address Group                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>The Value field consists of the following fields:</t>
      <ul empty="true" spacing="normal">
      <li>EUI-48 Address Group Mask:  A six-octet field that represents the
         bitmask to be applied to the Session-Reflector MAC Address.</li>
     <li>EUI-48 Address Group:  A six-octet field that represents the
         group this TLV is addressed to.  If the Session-Reflector
         applies EUI-48 Address Group Mask to its MAC Address and the
         result is different from EUI-48 Address Group, then the
         Session-Reflector MUST stop processing the received test packet.</li>
      </ul>
    </section>
    
            <section anchor="l3-addr-grp--sub-tlv" numbered="true" toc="default">
      <name>Layer 3 Address Group Sub-TLV</name>
     <t>
      Layer 3  Address Group sub-TLV:  A variable-length sub-TLV that includes the
      IP Address Family, IP Network Prefix, and IP Prefix Length.  The Type
      value is TBA3 (<xref target="iana-l2-l3-sub-tlv"/>).  The value of the Length field MUST be equal to 8 or 20.
      The format of Layer 3 Address Group sub-TLV is presented in <xref target="l3-addr-grp-sub-tlv-fig"/>.
      </t>
              <figure anchor="l3-addr-grp-sub-tlv-fig">
        <name>Layer 3 Address Group Sub-TLV Format</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family| Prefix Length |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                       IP Network Prefix                       ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>The Value field consists of the following fields:</t>
      <ul empty="true" spacing="normal">
      <li>Address Family: A one-octet field that indicates the type of IP address contained in the IP Network Prefix field.
      If that is IPv4 address, then the value MUST be set to 1. For the IPv6 address, the value MUST be set to 2.
      Other values MUST be considered invalid.</li>
      <li>Prefix Length: A one-octet unsigned integer field that contains the length, in bits,
      of the network prefix part of the value in the IP Network Prefix field.</li>
      <li>Reserved: A two-octet field. The field MUST be zeroed on transmission and ignored on receipt.</li>
      <li>IP Network Prefix: A variable-length field. Depending on the value of the Address Family field,
      the field contains either IPv4, or IPv6 address. If the former, the length is four octets; if the latter - 16 octets.</li>
      </ul>
    </section>
    </section>
    </section>

      <section anchor="theory-of-operation" numbered="true" toc="default">
      <name>Theory of Operation</name>

      <section anchor="rate-measurement" numbered="true" toc="default">
      <name>Rate Measurement</name>
      <t>
      <xref target="RFC7497"/> defines the problem of access rate measurement in access
   networks. Essential requirements identified for a test protocol are the
   ability to control packet characteristics on the tested path, such as
   asymmetric rate and asymmetric packet size. The Reflected Test
   Packet Control TLV, defined in <xref target="reflected-cntrl-tlv"/>, conforms to the
   requirements for measuring access rate by providing optional controls
   of the number of reflected test packets, the size of the reflected
   packet(s), and the time interval, i.e., rate, in transmitting the sequence of the reflected test packets.
      </t>
    </section>

  <section anchor="multicast-measurement" numbered="true" toc="default">
<name>Active Performance Measurement in Multicast Environment</name>
      <t>
      According to <xref target="RFC8972"/>, a STAMP Session is demultiplexed by a Session-Reflector by the tuple
      that consists of source and destination IP addresses, source and destination UDP port numbers, or
      the source IP address and STAMP Session Identifier. That is also the case of the monitoring performance of a multicast flow,
      despite that the destination IP address is multicast. Therefore the behavior of a Session-Reflector upon receiving
      a STAMP test packet over a multicast tree is as defined in <xref target="RFC8762"/> and <xref target="RFC8972"/>.
      The Session-Reflector MUST use the source IP address of the received STAMP test packet as the destination IP address of the reflected test packet,
      and MUST use one of the IP addresses associated with the node as the source IP address for that packet.
</t>
<t>
The Session-Sender has to pay more attention when sending a multicast STAMP packet. Instead of possibly,
receiving a reply from a Session-Reflector may now receive multiple replies from multiple counterparts:
its STAMP Session has a 1:N relation. Network traffic is another aspect that needs attention:
network congestion may happen if a single packet can generate millions of concurrent replies,
all directed to the same endpoint. Adding a Reflected Test Packet Control TLV allows Session-Sender to limit the number of replies.
It may do so by selecting Session-Reflectors, for example:
</t>
<ul empty="true" spacing="normal">
<li>Randomly by specifying a Layer 2 Address Group Sub-TLV: for example,
setting the EUI-48 Address Group Mask to 0xF and the EUI-48 Address Group to 0x1.
As a result, only 1 out of 16 reflectors will reply;</li>
<li>Having a specific vendor NIC by specifying a Layer 2 Address Group Sub-TLV
with the EUI-48 Address Group Mask set to 0xFFFFFF000000;</li>
<li>Belonging to specific IP networks, for example, a subnet dedicated to IPv6 over IPv4
encapsulation by specifying the appropriate Layer 3 Address Group Sub-TLV.</li>
</ul>
<t>
 Multicast traffic is also intrinsically asymmetrical, and focus on the return path is usually limited.
 The Length of the Reflected Packet value can be used to ensure the reflected packet transports
 all the timestamps and requested information, crucial for the underlying measure,
 but is as short as possible so as not to flood the network with useless data.
</t>
<t>
<xref target="I-D.ietf-ippm-stamp-srpm"/> defines the Return Path TLV that, when used
    in the combination with the Return Address Sub-TLV, allows a Session-Sender to request
    the reflected packet be sent to a different address from the
    Session-Sender one.  These STAMP extensions could be used in combination
    with the Reflected Packet Control TLV, defined in this document, to direct
    the reflected STAMP test packets to a collector of measurement data (according to the <xref target="RFC7594"/>)
    for further processong and network analytics.
    An example of the use case could be used in the multicast scenario
    when, for example, the Session-Sender is close to the actual
    multicast frames generator (for example, a camera transmitting live
    video) so that the test packets follow the same path as the
    video stream packets in one direction.  The data center where the test
    data are analyzed could be far away, and it would be better to have
    reflected packets return there.
    </t>
    </section>
  </section>

      <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
 Security considerations discussed in <xref target="RFC8762"/>,<xref target="RFC8972"/>, and <xref target="I-D.ietf-ippm-stamp-srpm"/>
 apply to this document.  Furthermore,
   spoofed STAMP test packets with the Reflected Test Packet Control TLV
   can be exploited to conduct a Denial-of-Service attack. Hence,
   implementations MUST use an identity protection mechanism.
   For example, verify the information about the source of the STAMP packet against a pre-defined list of trusted nodes.
   Also, STAMP authentication mode <xref target="RFC8762"/> or HMAC TLV <xref target="RFC8972"/> could be used
   for a STAMP test session containing the Reflected Test Packet Control TLV. 
      </t>
      <t>
   Considering the potential number of reflected packets that can be
   generated by a single test packet sent to a Multicast address, when
   sending such messages a Session-Sender SHOULD sign packets using the
   HMAC TLV.
</t>
<t>
A Session-Sender SHOULD NOT send the next STAMP test packet with the Reflected Test Packet Control TLV
before the Session-Reflector is expected to complete transmitting all reflected packets in response to the Reflected Test Packet Control TLV
in the previous test packet.
</t>
    </section>

        <section numbered="true" toc="default">
      <name>Acknowledgments</name>
      <t>
TBA
      </t>
    </section>
      
    <section anchor="iana-consider" numbered="true" toc="default">
      <name>IANA Considerations</name>
      
    <section anchor="iana-pkt-cntrl-tlv" numbered="true" toc="default">
      <name>Reflected Test Packet Control TLV Type</name>
        <t>
     The IANA is requested to assign a new value for the Reflected Test Packet Control TLV
     from the STAMP TLV Types sub-registry according to <xref target="refl-cntrl-table"/>.
        </t>
        <table anchor="refl-cntrl-table" align="center">
          <name>New Reflected Test Packet Control Type TLV</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">&nbsp;TBA1</td>
              <td align="left">Reflected Test Packet Control TLV</td>
              <td align="left">This&nbsp;document</td>
            </tr>
          </tbody>
        </table>
      </section>

    <section anchor="iana-l2-l3-sub-tlv" numbered="true" toc="default">
      <name>Reflected Test Packet Control TLV Type</name>
      <t>
     The IANA is requested to assign a new value for the Reflected Test Packet Control TLV
     from the STAMP Sub-TLV Types sub-registry according to <xref target="sub-tlv-type-tbl"/>.
     </t>
             <table anchor="sub-tlv-type-tbl" align="center">
          <name>STAMP sub-TLV Types for the Reflected Test Packet Control TLV</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Description</th>
              <th align="left">TLV Used</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">&nbsp;TBA2</td>
              <td align="left">Layer 2 Address Group</td>
              <td align="left">Reflected Test Packet Control TLV</td>
              <td align="left">This&nbsp;document</td>
           </tr>
            <tr>
              <td align="left">&nbsp;TBA3</td>
              <td align="left">Layer 3 Address Group</td>
              <td align="left">Reflected Test Packet Control TLV</td>
              <td align="left">This&nbsp;document</td>
            </tr>
          </tbody>
        </table>
      </section>
</section>
</middle>

  <back>
      <references>
      <name>References</name>
    <references>
      <name>Normative References</name>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8762.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8972.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7594.xml"/>
      
     <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ippm-stamp-srpm.xml"/>
    </references>
    
      <references title="Informative References">
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7497.xml"/>
      </references>
      </references>
      
  </back>
</rfc>
