<?xml version="1.0" encoding="US-ASCII"?> encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?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"?> "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8762" consensus="true" category="std" docName="draft-ietf-ippm-stamp-10" ipr="trust200902">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.39.0 -->

<front>
    <title abbrev="STAMP">Simple Two-way Two-Way Active Measurement Protocol</title>
    <seriesInfo name="RFC" value="8762"/>
    <author fullname="Greg Mirsky" initials="G." surname="Mirsky">
      <organization>ZTE Corp.</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country/>
        </postal>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    <author fullname="Guo Jun" initials="G." surname="Jun">
      <organization>ZTE Corporation</organization> Corp.</organization>
      <address>
        <postal>
          <street>68# Zijinghua Road</street>
          <city>Nanjing</city>
          <region>Jiangsu</region>
          <code>210012</code>
          <country>P.R.China</country>
          <country>China</country>
        </postal>
        <phone>+86 18105183663</phone>
        <email>guo.jun2@zte.com.cn</email>
      </address>
    </author>
    <author fullname="Henrik Nydell" initials="H." surname="Nydell">
      <organization>Accedian Networks</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country/>
        </postal>
        <email>hnydell@accedian.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="2019"/> month="March" year="2020"/>
    <area>Transport</area>
    <workgroup>Network Working Group</workgroup>

    <keyword>Internet-Draft</keyword>
    <keyword>IPPM</keyword>
    <keyword>Performance Measurement </keyword>
    <abstract>
      <t>
	This document describes a the Simple Two-way Active Measurement
	Protocol (STAMP), which enables the measurement of both one-way and round-trip
	performance metrics metrics, like delay, delay variation, and packet loss.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
Development and deployment of the Two-Way Active Measurement Protocol (TWAMP)
<xref target="RFC5357"/> target="RFC5357" format="default"/> and its extensions, e.g., extensions (e.g.,
<xref target="RFC6038"/> that defined target="RFC6038" format="default"/>, which defines Symmetrical Size for TWAMP, TWAMP)
provided invaluable experience. Several independent implementations of both
TWAMP and TWAMP Light exist, have been deployed, and provide
important operational performance measurements.
</t>
      <t>
At the same time, there has been noticeable interest in using a more straightforward
mechanism for active performance monitoring that can provide deterministic
behavior and inherent separation of control
(vendor-specific configuration or orchestration) and test functions.
Recent work on "Performance Measurement from IP Edge to Customer Equipment using TWAMP Light from Light"
<xref target="BBF.TR-390" format="default"/> by the
Broadband Forum <xref target="BBF.TR-390"/>
demonstrated demonstrates that interoperability among
implementations of TWAMP Light is difficult because the composition
and operation of TWAMP Light were not sufficiently specified in <xref target="RFC5357"/>. target="RFC5357" format="default"/>.
According to <xref target="RFC8545"/>, target="RFC8545" format="default"/>, TWAMP Light includes a sub-set subset of TWAMP-Test
functions. Thus, to have a comprehensive tool to measure packet loss and delay requires
support by other applications that provide, for example, control and security.
</t>
      <t>
This document defines an active performance measurement test protocol, Simple
Two-way Active Measurement Protocol (STAMP),
that enables measurement of both one-way and round-trip performance metrics metrics,
like delay, delay variation, and packet loss. Some Support of some
optional TWAMP extensions, e.g., <xref target="RFC7750"/> are supported by the extensions to STAMP base specification target="RFC7750" format="default"/>, is discussed in <xref target="I-D.ietf-ippm-stamp-option-tlv"/>. target="I-D.ietf-ippm-stamp-option-tlv" format="default"/>.
</t>
    </section>
    <section title="Conventions used numbered="true" toc="default">
      <name>Conventions Used in this document"> This Document</name>
      <section title="Terminology">

<t>STAMP - Simple numbered="true" toc="default">
        <name>Terminology</name>
        <dl newline="false" spacing="normal" indent="12">
         <dt>STAMP:</dt>
         <dd>Simple Two-way Active Measurement Protocol</t>
 <t>NTP   - Network Protocol</dd>
         <dt>NTP:</dt>
         <dd>Network Time Protocol</t>
 <t>PTP  - Precision Protocol</dd>
         <dt>PTP:</dt>
         <dd>Precision Time Protocol</t>
<t>HMAC     Hashed Protocol</dd>
         <dt>HMAC:</dt>
         <dd>Hashed Message Authentication Code</t>
<t>OWAMP   One-Way Code</dd>
         <dt>OWAMP:</dt>
         <dd>One-Way Active Measurement Protocol</t>
<t>TWAMP    Two-Way Protocol</dd>
         <dt>TWAMP:</dt>
         <dd>Two-Way Active Measurement Protocol</t>
<t>MBZ          Must be Zero</t> Protocol</dd>
         <dt>MBZ:</dt>
         <dd>Must be Zero</dd>
         <dt>PDU:</dt>
         <dd>Protocol Data Unit</dd>
        </dl>
      </section>
      <section title="Requirements Language"> 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", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section anchor="simple-pm-section" title="Operation numbered="true" toc="default">
      <name>Operation and Management of Performance Measurement Based on STAMP"> STAMP</name>
      <t>
<xref target="STAMP-ref-model"/> target="STAMP-ref-model" format="default"/> presents the Simple Two-way
Active Measurement Protocol (STAMP)
Session-Sender,
Session-Sender and Session-Reflector with a measurement session. In this
document, a measurement session session,
also referred to as STAMP session, a "STAMP session", is the bi-directional bidirectional
packet flow between one specific Session-Sender and one particular
Session-Reflector for a time duration.
The configuration and management of the STAMP Session-Sender,
Session-Reflector, and
management of the STAMP sessions are outside the scope of this
document and can be achieved through various means.
A few examples are:&#160; are Command Line Interface, telecommunication
services' OSS/BSS systems, Operational Support System (OSS) / Business Support System (BSS),
SNMP, and Netconf/YANG-based SDN NETCONF/YANG-based Software-Defined Networking (SDN) controllers.

</t>
      <figure align="left" anchor="STAMP-ref-model" title="STAMP anchor="STAMP-ref-model">
        <name>STAMP Reference Model">
          <artwork>
          <![CDATA[ Model</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
      o----------------------------------------------------------o
      |                      Configuration and                   |
      |                         Management                       |
      o----------------------------------------------------------o
             ||                                          ||
             ||                                          ||
             ||                                          ||
  +----------------------+                +-------------------------+
  | STAMP Session-Sender | <--- STAMP---> | STAMP Session-Reflector |
  +----------------------+                +-------------------------+
         ]]>
          </artwork>
]]></artwork>
      </figure>
    </section>
    <section anchor="stamp-section" title="Theory numbered="true" toc="default">
      <name>Theory of Operation"> Operation</name>
      <t>
The STAMP Session-Sender transmits test packets over UDP transport
toward the STAMP Session-Reflector. The STAMP Session-Reflector
receives the Session-Sender's packet and acts according to the configuration.

             Two modes of the STAMP Session-Reflector characterize the expected
	     behavior and, consequently, performance metrics that can be
	     measured:
             <list style="symbols">
             <t>
             Stateless -
      </t>
      <dl newline="true" spacing="normal">
        <dt>Stateless:</dt>
         <dd>The STAMP Session-Reflector does not maintain test
             state and will use the value in the Sequence Number field in
             the received packet as the value for the Sequence Number field
             in the reflected packet.
             As a result, values in the Sequence Number and Session-Sender
	     Sequence Number fields
             are the same, and only round-trip packet loss can be calculated
	     while the reflector is operating in stateless mode.
             </t>
             <t>
             Stateful -
             </dd>
        <dt>Stateful:</dt>
      <dd>          STAMP Session-Reflector maintains the test state state, thus enabling
      allowing the ability Session-Sender to determine forward loss, directionality of loss using
      the combination of gaps recognized in the received sequence number. Session Sender Sequence
      Number and Sequence Number fields, respectively.
As a result, both near-end (forward) and far-end (backward) packet loss can be
computed.
      That implies that the STAMP Session-Reflector MUST
             keep <bcp14>MUST</bcp14> maintain a state
      for each configured STAMP-test STAMP-Test session, thereby uniquely identifying STAMP-test associating
      STAMP-Test packets to with one such session instance, and instance and, thus, enabling
             adding
      the addition of a sequence number in the test reply that is individually
      incremented by one on a per-session basis.
             </t>
             </list>

             </t>

             </dd>
      </dl>
      <t>
   STAMP supports two authentication modes:
   unauthenticated and authenticated. Unauthenticated STAMP test STAMP-Test packets,
   defined in Sections <xref target="session-sender-packet-unauthenticated-section"/> target="session-sender-packet-unauthenticated-section" format="counter"/> and
   <xref target="session-reflector-packet-unauthenticated-section"/>, target="session-reflector-packet-unauthenticated-section" format="counter"/>, ensure interworking
   between STAMP and TWAMP Light Light, as described in <xref target="interoperation-twamp"/> target="interoperation-twamp" format="default"/> regarding
   packet formats.
</t>
      <t>
By default, STAMP uses symmetrical packets, i.e., the size of the packet
transmitted by the Session-Reflector equals the size of
the packet received by the Session-Reflector.
</t>
      <section anchor="stamp-port-sec" title="UDP numbered="true" toc="default">
        <name>UDP Port Numbers in STAMP Testing"> Testing</name>
        <t>
A STAMP Session-Sender MUST <bcp14>MUST</bcp14> use
UDP port 862 (TWAMP-Test Receiver Port) as the default destination UDP port
number. A STAMP implementation of the Session-Sender MUST <bcp14>MUST</bcp14>
be able to use be used as the destination UDP port numbers from User, a.k.a. Registered, the User Ports
(aka Registered Ports) and
Dynamic, a.k.a. Dynamic Ports (aka Private or Ephemeral, Ports Ephemeral Ports)
ranges defined in <xref target="RFC6335"/>. target="RFC6335" format="default"/>. Before using
numbers from the User Ports range, the possible impact on the network MUST
<bcp14>MUST</bcp14> be carefully studied and agreed on by all users of the
network domain where the test has been planned.
</t>
        <t>
 An
 By default, an implementation of the STAMP Session-Reflector by default
MUST
 <bcp14>MUST</bcp14> receive STAMP test STAMP-Test packets on UDP port 862.

 An
implementation of the Session-Reflector
that supports this specification MUST <bcp14>MUST</bcp14> be able to define the
port number to receive STAMP test STAMP-Test packets
from User Ports and Dynamic Ports ranges that ranges, which are defined in <xref target="RFC6335"/>. target="RFC6335" format="default"/>.
STAMP defines two different test packet formats, formats: one for
   packets transmitted by the STAMP-Session-Sender STAMP Session-Sender and one for packets
   transmitted by the STAMP-Session-Reflector. STAMP Session-Reflector.
        </t>
      </section>
      <section anchor="stamp-session-sender" title="Session-Sender numbered="true" toc="default">
        <name>Session-Sender Behavior and Packet Format"> Format</name>
        <t>
             A STAMP Session-Reflector supports the symmetrical size of test packets,
             as defined in Section 3 <xref target="RFC6038"/>, target="RFC6038" sectionFormat="of" section="3"/>, as the default behavior.
             A reflected base test packet includes more information and thus from
   the Session-Reflector and, thus, is larger.
             Because of that,
   To maintain the symmetry between base STAMP packets,
   the base STAMP Session-Sender packet
             is padded includes the Must-Be-Zero (MBZ) field to
   match to the size of a base reflected STAMP test packet.
             Hence, the base STAMP Session-Sender packet has a minimum
             size of 44 octets in unauthenticated mode, see mode (see <xref target="session-sender-unauthenticated-format"/>, target="session-sender-unauthenticated-format" format="default"/>)
             and 112 octets in the authenticated mode, see mode (see <xref target="session-sender-authenticated-format"/>.
             The target="session-sender-authenticated-format" format="default"/>).
             Generating variable length of a test packet in STAMP is supported by using
             Extra Padding TLV defined in <xref target="I-D.ietf-ippm-stamp-option-tlv"/>. target="I-D.ietf-ippm-stamp-option-tlv" format="default"/>.
        </t>
        <section anchor="session-sender-packet-unauthenticated-section" title="Session-Sender numbered="true" toc="default">
          <name>Session-Sender Packet Format in Unauthenticated Mode">

               <t>
                STAMP Session-Sender packet format in unauthenticated mode: Mode</name>
          <figure align="left" anchor="session-sender-unauthenticated-format" title=" STAMP anchor="session-sender-unauthenticated-format">
            <name>STAMP Session-Sender test packet format Test Packet Format in unauthenticated mode">
          <artwork><![CDATA[ Unauthenticated Mode</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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Timestamp                            |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Error Estimate        |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   |                                                               |
   |                      Reserved                        MBZ  (30 octets)                       |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
        where
          <t>
        The fields are defined as the following:
        <list style="symbols">
        <t>
          </t>
          <ul spacing="normal">
            <li>
        The Sequence Number field is four octets long field. long. For each new session session,
      its value starts at zero and is incremented by one with each transmitted
      packet.
        </t>
        <t>
        </li>
            <li>
        The Timestamp field is eight octets long field. long. The STAMP node MUST
	<bcp14>MUST</bcp14> support the Network
        Time Protocol (NTP) version 4 64-bit timestamp format <xref target="RFC5905"/>, target="RFC5905" format="default"/>,
        the format used in <xref target="RFC5357"/>. target="RFC5357" format="default"/>. The STAMP
	node MAY <bcp14>MAY</bcp14> support the
        IEEE 1588v2 Precision Time Protocol (PTP) truncated 64-bit timestamp
        format <xref target="IEEE.1588.2008"/>, target="IEEE.1588.2008" format="default"/>, the format
	used in <xref target="RFC8186"/>. target="RFC8186" format="default"/>.
        The use of the specific format, NTP or PTP, is part of configuration
	of the Session-Sender or the particular test session.
        </t>
        </li>
            <li>
              <t>
        The Error Estimate field is two octets long field with the format displayed in <xref target="error-estimate-format"/> target="error-estimate-format" format="default"/>:
              </t>
              <figure align="left" anchor="error-estimate-format" title=" Error anchor="error-estimate-format">
                <name>Error Estimate Format">
          <artwork><![CDATA[ Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
         0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |S|Z|   Scale   |   Multiplier  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
              </figure>
        where
              <t>
        The S, Scale, and Multiplier fields are interpreted as they have been are
	defined in section 4.1.2 <xref target="RFC4656"/>;
        and target="RFC4656" sectionFormat="of" section="4.1.2"/>. The Z field - is interpreted as has been it is defined in section 2.3
	<xref target="RFC8186"/>:
             <list style="symbols">
             <t>0 - NTP 64 bit target="RFC8186" sectionFormat="of" section="2.3"/>:
              </t>
              <dl spacing="normal">
                <dt>0:</dt><dd>NTP 64-bit format of a timestamp;</t>
             <t>1 - PTPv2 timestamp</dd>
                <dt>1:</dt><dd>PTPv2 truncated format of a timestamp.</t>
             </list>
<!--
             The STAMP Session-Sender and Session-Reflector MAY use, not use, or set value of the Z field
             in accordance with the timestamp format in use. This optional field is to enhance operations,
             but local configuration or defaults could be used in its place.
--> timestamp</dd>
              </dl>
              <t>
The default behavior of the STAMP Session-Sender and
Session-Reflector is to use the NTP 64-bit timestamp format
(Z field value of 0) 0). An operator, operator using configuration/management function,
MAY function
<bcp14>MAY</bcp14> configure the STAMP Session-Sender and Session-Reflector
to using use the PTPv2 truncated format of a timestamp (Z field value of 1).
Note,
Note that an implementation of a Session-Sender that supports this specification
MAY
<bcp14>MAY</bcp14> be configured to use the PTPv2 format of a timestamp even
though the Session-Reflector is
configured to use NTP format.
              </t>
        <t>
        Reserved
            </li>
            <li>
        The MBZ field in the Session-Sender unauthenticated packet is 30
	octets long. It MUST <bcp14>MUST</bcp14> be all zeroed on the transmission
	and MUST <bcp14>MUST</bcp14> be ignored on receipt.
        </t>

        <!--
        <t>
        Comp.MBZ is variable length field used to achieve alignment on a word boundary. Thus the length of Comp.MBZ field may be only 0, 1, 2 or 3 octets.
        The value of the field MUST be zeroed on transmission and ignored on receipt.
        </t>
        -->
                </list>
            </t>
  <!--
        <t>
        The unauthenticated STAMP Session-Sender packet MAY include Type-Length-Value encodings that immediately follow the Comp. MBZ field.
        <list style="symbols">
        <t>
        Type field is two octets long. The value of the Type field is the codepoint allocated by IANA
        <xref target="iana-consider"/> that identifies data in the Value field.
        </t>
        <t>
        Length is two octets long field, and its value is the length of the Value field in octets.
        </t>
        <t>
        Value field contains the application specific information. The length of the Value field MUST be four octets aligned.
        </t>
        </list>
        </t>
-->
        </li>
                </ul>
</section>

        <section anchor="session-sender-packet-authenticated-section" title="Session-Sender numbered="true" toc="default">
          <name>Session-Sender Packet Format in Authenticated Mode">
            <t>
                      STAMP Session-Sender packet format in authenticated mode: Mode</name>

          <figure align="left" anchor="session-sender-authenticated-format" title=" STAMP anchor="session-sender-authenticated-format">
            <name>STAMP Session-Sender test packet format Test Packet Format in authenticated mode">
          <artwork><![CDATA[ Authenticated Mode</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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Sequence Number                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                      MBZ (12 octets)                          |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Timestamp                              |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Error Estimate         |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 ~                                                               ~
 |                         MBZ (70 octets)                       |
 ~                                                               ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                       HMAC (16 octets)                        |
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>

  </t>
          <t>
  The field definitions are the same as the unauthenticated mode, listed in
  <xref target="session-sender-packet-unauthenticated-section"/>. target="session-sender-packet-unauthenticated-section" format="default"/>. Also, Must-Be-Zero (MBZ) MBZ fields are used to to make
  the packet length a multiple of 16 octets. The value of the field MUST
  <bcp14>MUST</bcp14> be zeroed on transmission and MUST <bcp14>MUST</bcp14> be
  ignored on receipt.
  Note, that the both MBZ field is fields are used to calculate a key-hashed key hashed message
  authentication code (HMAC) (<xref target="RFC2104"/>) <xref target="RFC2104" format="default"/> hash.
 Also, the packet includes an HMAC hash at the end of the PDU. The detailed
 use of the HMAC field is described in <xref target="integrity-section"/>. target="integrity-section" format="default"/>.
          </t>
<!--
<t>
   The STAMP Session-Sender-packet format (<xref target="session-sender-authenticated-format"/>) is the same in authenticated and
   encrypted modes.  The encryption and authentication operations are,
   however, different and protect the data as follows:
   <list>
   <t>in the authenticated mode the Sequence Number is protected while the
   Timestamp and the Error Estimate are sent in clear text;
   </t>
   <t>
   in encrypted mode all fields, including the timestamp and Error Estimate,
   are protected to provide maximum data confidentiality and integrity protection.
   </t></list>
   Sending the Timestamp in clear text
   in authenticated mode allows more consistent reading of time by a Session-Sender
   on the transmission of the test packet.
   Reading of the time in encrypted mode must be followed by its encryption which introduces
   variable delay thus affecting calculated timing metrics.
</t>
-->
                </section>
      </section>

      <section anchor="stamp-session-reflector" title="Session-Reflector numbered="true" toc="default">
        <name>Session-Reflector Behavior and Packet Format"> Format</name>
        <t>
             The Session-Reflector receives the STAMP test STAMP-Test packet and verifies
	     it. If the base STAMP test STAMP-Test packet is validated,
              the Session-Reflector, Session-Reflector that supports this specification, specification
	      prepares and transmits the reflected test packet symmetric
              to the packet received from the Session-Sender copying the
	      content beyond the size of the base STAMP packet
              (see <xref target="stamp-session-sender"/>). target="stamp-session-sender" format="default"/>).
        </t>
        <section anchor="session-reflector-packet-unauthenticated-section" title="Session-Reflector numbered="true" toc="default">
          <name>Session-Reflector Packet Format in Unauthenticated Mode"> Mode</name>
          <t>
          </t>

               <t>
                For unauthenticated mode:

          <figure align="left" anchor="session-reflector-unauthenticated-format" title="STAMP anchor="session-reflector-unauthenticated-format">
            <name>STAMP Session-Reflector test packet format Test Packet Format in unauthenticated mode">
          <artwork><![CDATA[
	    Unauthenticated Mode</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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Sequence Number                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Timestamp                            |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Error Estimate        |            MBZ                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Receive Timestamp                    |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                 Session-Sender Sequence Number                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  Session-Sender Timestamp                     |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Session-Sender Error Estimate |            MBZ                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Ses-Sender TTL |                   Reserved                      MBZ                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
      where fields
          <t>
      Fields are defined as the following:
        <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>
        The Sequence Number field is four octets long field. long. The value of the Sequence
	Number field is set according to the mode of the STAMP
	Session-Reflector:
        <list>
        <t>
        in
              </t>
              <ul spacing="normal">
                <li>
        In the stateless mode, the Session-Reflector copies the value from the
	received STAMP test STAMP-Test packet's Sequence Number field;
        </t>
        <t>
        in field.
        </li>
                <li>
        In the stateful mode, the Session-Reflector counts the transmitted STAMP test
	STAMP-Test packets.
        It starts with zero and is incremented by one
   for each subsequent packet for each test session.
   The Session-Reflector uses that counter to set the value of the Sequence Number field.
        </t>
        </list>
        </t>
        <t>
        </li>
              </ul>
            </li>
            <li>
        The Timestamp and Receive Timestamp fields are each eight octets long. The
	format of these fields, NTP or PTPv2, is
        indicated by the Z field of the Error Estimate field field, as described in
	<xref target="stamp-session-sender"/>. target="session-sender-packet-unauthenticated-section" format="default"/>.
        Receive Timestamp is the time the test packet was received by the
	Session-Reflector. Timestamp - is
        the time taken by the Session-Reflector at the start of transmitting
	the test packet.
        </t>
        <t>
        </li>
            <li>
        The Error Estimate field has the same size and interpretation as
	described in <xref target="stamp-session-sender"/>. target="session-sender-packet-unauthenticated-section" format="default"/>.
        It is applicable to both Timestamp and Receive Timestamp.
        </t>
        <t>
        </li>
            <li>
        The Session-Sender Sequence Number, Session-Sender Timestamp, and
	Session-Sender Error Estimate fields
        are copies of the corresponding fields in the STAMP test STAMP-Test packet sent
	by the Session-Sender.
        </t>
        <t>
        </li>
            <li>
        The Session-Sender TTL field is one octet long field, long, and its value is the copy of the
        TTL field in IPv4 (or Hop Limit in IPv6) from the received STAMP test packet.
        </t>
        <!--
        <t>
        Packet Padding (reflected) is an optional variable length field. The length of the Packet Padding (reflected) field MUST be equal to the value
        of the Server Octets field (<xref target="session-sender-unauthenticated-format"/>). If the value is non-zero,
        the Session-Reflector MUST copy number of octets equal to the value of Server Octets field starting with in IPv4 (or Hop Limit in IPv6) from the Server Octets field.
        </t>
        -->
        <t> received STAMP-Test packet.
        </li>

        <li>
        The MBZ is fields are used to achieve alignment of fields within the packet
	on a four octets four-octet boundary.
        The value of the field MUST be zeroed on transmission and MUST be ignored on receipt.
        </t>
        <t>
                Reserved each MBZ field in the Session-Reflector unauthenticated packet is three octets long.
        It MUST <bcp14>MUST</bcp14> be all zeroed on the transmission
	and MUST <bcp14>MUST</bcp14> be ignored on receipt.
        </t>
        </list>
            </t>
        </li>
          </ul>
        </section>
        <section anchor="session-reflector-packet-authenticated-section" title="Session-Reflector numbered="true" toc="default">
          <name>Session-Reflector Packet Format in Authenticated Mode">
            <t>
                     For the authenticated mode: Mode</name>

          <figure align="left" anchor="session-reflector-authenticated-format" title=" STAMP anchor="session-reflector-authenticated-format">
            <name>STAMP Session-Reflector test packet format Test Packet Format in authenticated mode">
          <artwork><![CDATA[ Authenticated Mode</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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        MBZ (12 octets)                        |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Timestamp                            |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Error Estimate        |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                        MBZ (6 octets)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Receive Timestamp                      |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        MBZ (8 octets)                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Session-Sender Sequence Number                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        MBZ (12 octets)                        |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Session-Sender Timestamp                      |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Session-Sender Error Estimate |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                        MBZ (6 octets)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ses-Sender TTL |                                               |
   +-+-+-+-+-+-+-+-+                                               +
   |                                                               |
   |                        MBZ (15 octets)                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        HMAC (16 octets)                       |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>

                     </t>
          <t>
  The field definitions are the same as the unauthenticated mode, listed in
  <xref target="session-reflector-packet-unauthenticated-section"/>. target="session-reflector-packet-unauthenticated-section" format="default"/>.
  Additionally, the MBZ field is used to to make the packet length a multiple of 16 octets.
  The value of the field MUST <bcp14>MUST</bcp14> be zeroed on transmission and MUST
  <bcp14>MUST</bcp14> be ignored on receipt.
  Note,
  Note that the MBZ field is used to calculate the HMAC hash value.
 Also, the STAMP Session-Reflector test packet format in authenticated mode
 includes the HMAC (<xref target="RFC2104"/>) <xref target="RFC2104" format="default"/> hash at the end of the PDU.
  The detailed use of the HMAC field is in <xref target="integrity-section"/>. target="integrity-section" format="default"/>.
          </t>
        </section>
      </section>
      <section anchor="integrity-section" title="Integrity numbered="true" toc="default">
        <name>Integrity Protection in STAMP"> STAMP</name>
        <t>
                Authenticated mode provides integrity protection to each STAMP
		message by adding
                Hashed Message Authentication Code (HMAC). STAMP
                uses HMAC-SHA-256 truncated to 128 bits (similarly to the use
		of it in IPSec IPsec defined in <xref target="RFC4868"/>); hence target="RFC4868" format="default"/>); hence,
                the length of the HMAC field is 16 octets. In the Authenticated authenticated mode,
                HMAC covers the first six blocks (96 octets). HMAC uses its
		own key that key, which may be unique for each STAMP test STAMP-Test session;
                key management and the mechanisms to distribute the HMAC key
		are outside the scope of this specification. One example is to
                use an orchestrator to configure the HMAC key based on the STAMP YANG
		data model <xref target="I-D.ietf-ippm-stamp-yang"/>. target="I-D.ietf-ippm-stamp-yang" format="default"/>.
                HMAC MUST <bcp14>MUST</bcp14> be verified as early as possible to
		avoid using or propagating corrupted data.
        </t>
        <t>
                Future specifications may define the use of other, more
		advanced cryptographic algorithms,
                possibly providing an update to the STAMP YANG data model
		<xref target="I-D.ietf-ippm-stamp-yang"/>. target="I-D.ietf-ippm-stamp-yang" format="default"/>.
        </t>
      </section>
      <section anchor="vonfidentiality-section" title="Confidentiality numbered="true" toc="default">
        <name>Confidentiality Protection in STAMP"> STAMP</name>
        <t>
                If confidentiality protection for STAMP is required, a STAMP
                test
		STAMP-Test session MUST <bcp14>MUST</bcp14> use a secured
		transport. For example,
                STAMP packets could be transmitted in the dedicated IPsec
		tunnel or share the IPsec tunnel with the
                monitored flow. Also, the Datagram Transport Layer Security protocol
                would provide the desired confidentiality protection.
        </t>
      </section>
      <section anchor="interoperation-twamp" title="Interoperability numbered="true" toc="default">
        <name>Interoperability with TWAMP Light"> Light</name>
        <t>
One of the essential requirements to STAMP is the ability to interwork with a
TWAMP Light device. Because STAMP and TWAMP use different algorithms in Authenticated
authenticated mode (HMAC-SHA-256 vs. versus HMAC-SHA-1), interoperability is only
considered for Unauthenticated unauthenticated mode. There are two possible combinations for
such a use case:
<list style="symbols">
<t>STAMP
</t>
        <ul spacing="normal">
          <li>STAMP Session-Sender with TWAMP Light Session-Reflector;</t>
<t>TWAMP Session-Reflector</li>
          <li>TWAMP Light Session-Sender with STAMP Session-Reflector.</t>
</list>
    </t> Session-Reflector</li>
        </ul>
        <t>
   In the former case, the Session-Sender might not be aware that its Session-Reflector
   does not support STAMP. For example, a TWAMP Light Session-Reflector may not
   support the use of UDP port 862 862, as specified in <xref target="RFC8545"/>.
    Thus target="RFC8545" format="default"/>.
    Thus, <xref target="stamp-section"/>. target="stamp-section" format="default"/> permits a STAMP
    Session-Sender to use alternative ports. If any of STAMP extensions are
    used, the TWAMP Light Session-Reflector will view them as the Packet
    Padding field.
   <!-- The Session-Sender
   SHOULD use the default format for its timestamps - NTP. And it MAY
   use PTPv2 timestamp format. -->
        </t>
        <t>
   In the latter scenario, if a TWAMP Light Session-Sender does not support
   the use of UDP port 862, the test management system MUST <bcp14>MUST</bcp14> set
   the STAMP Session-Reflector to use UDP port number, as permitted by <xref target="stamp-section"/>. target="stamp-section" format="default"/>. The Session-Reflector MUST
   <bcp14>MUST</bcp14> be set to use the default format for its timestamps,
   NTP.
        </t>
        <t>
A STAMP Session-Reflector that supports this specification will transmit the base packet
(<xref target="session-reflector-unauthenticated-format"/>) target="session-reflector-unauthenticated-format" format="default"/>)
if it receives a packet smaller than
the STAMP base packet. If the packet received from the TWAMP Session-Sender is
larger than the STAMP base packet,
the STAMP Session-Reflector that supports this specification will copy the
content of the remainder of the received packet to transmit a reflected packet
of symmetrical size.
</t>
      </section>
    </section>
    <section anchor="operation-sec" title="Operational Considerations"> numbered="true" toc="default">
      <name>Operational Considerations</name>
      <t>
STAMP is intended to be used on production networks to enable
the operator to assess service level agreements based on packet delay,
delay variation, and loss. When using STAMP over the Internet, especially
when  STAMP test  STAMP-Test packets are transmitted with the destination UDP port number from
     the User Ports range, the possible impact of the STAMP test STAMP-Test packets MUST
     <bcp14>MUST</bcp14> be thoroughly analyzed.
     The use of STAMP for each case MUST <bcp14>MUST</bcp14> be agreed by users of
     nodes hosting the Session-Sender and Session-Reflector before starting
     the STAMP test STAMP-Test session.
      </t>
      <t>
  Also, the use of the well-known port number as
  the destination UDP port number in STAMP test STAMP-Test packets transmitted
  by a Session-Sender would not impede
  the ability to measure performance in an Equal Cost Equal-Cost Multipath environment environment,
  and analysis in Section  5.3 <xref target="RFC8545"/> target="RFC8545" sectionFormat="of" section="5.3"/>
  fully applies to STAMP.
      </t>
    </section>
    <section anchor="iana-consider" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
This document doesn't have any has no IANA action. This section may be removed before the publication. actions.
      </t>
    </section>
    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
     <xref target="RFC5357"/> target="RFC5357" format="default"/> does not identify security
     considerations specific to TWAMP-Test but refers to
     security considerations identified for OWAMP in <xref target="RFC4656"/>. target="RFC4656" format="default"/>. Since both OWAMP and TWAMP include control plane control-plane and data plane
     data-plane components,
     only security considerations related to OWAMP-Test, OWAMP-Test discussed in Sections 6.2, 6.3
     <xref target="RFC4656" section="6.2" sectionFormat="bare"/> and
     <xref target="RFC4656" section="6.3" sectionFormat="bare"/> of <xref target="RFC4656"/> apply to STAMP.
      </t>
      <t>
     STAMP uses the well-known UDP port number allocated for the
     OWAMP-Test/TWAMP-Test Receiver port. Thus Port. Thus, the security considerations and
     measures to mitigate the risk of the attack using the registered port
     number documented in
     Section 6 <xref target="RFC8545"/> target="RFC8545" sectionFormat="of" section="6"/> equally apply to STAMP. Because of the control and
     management of a STAMP test STAMP-Test being outside the scope of this specification specification,
     only the more general requirement is set:
     <list>
     <t>
      </t>
      <ul empty="true" spacing="normal">
        <li>
     To mitigate the possible attack vector, the control, control and management of a STAMP test
     STAMP-Test session MUST <bcp14>MUST</bcp14> use the secured transport.
     </t>
     <t>
     </li>
        <li>
     The load of the STAMP test STAMP-Test packets offered to a network MUST
     <bcp14>MUST</bcp14> be carefully estimated,
     and the possible impact on the existing services MUST <bcp14>MUST</bcp14> be
     thoroughly analyzed before launching the test session.
     <xref target="RFC8085"/> section 3.1.5 target="RFC8085" sectionFormat="of" section="3.1.5"/> provides
     guidance on handling network load for UDP-based protocol. While the
     characteristic of test traffic depends on the test objective, it is
     highly recommended to stay in the limits limits, as provided in <xref target="RFC8085"/>.
     </t>
     </list>
     </t> target="RFC8085" format="default"/>.
     </li>
      </ul>
      <t>
Use of HMAC-SHA-256 in the authenticated mode protects the data integrity
of the STAMP test STAMP-Test packets.
      </t>
    </section>

      <section title="Acknowledgments">
         <t>
 Authors express their appreciation to Jose Ignacio Alvarez-Hamelin and
Brian Weis for their great insights into the security and identity protection,
and the most helpful and practical suggestions. Also, our sincere thanks to
David Ball and Rakesh Gandhi or their thorough reviews and helpful comments.
         </t>
      </section>
  </middle>
  <back>
    <references title="Normative References">

  <?rfc include="reference.RFC.2119"?>
  <?rfc include="reference.RFC.8174"?>
    <displayreference target="I-D.ietf-ippm-stamp-yang" to="STAMP-YANG"/>
    <displayreference target="I-D.ietf-ippm-stamp-option-tlv" to="STAMP-OPTION"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <!-- <?rfc include="reference.RFC.8126"?> -->
  <?rfc include="reference.RFC.5357"?>
  <?rfc include="reference.RFC.5905"?>
  <?rfc include="reference.RFC.4656"?>
  <?rfc include="reference.RFC.8186"?>
  <?rfc include="reference.RFC.6335"?>
  <?rfc include="reference.RFC.6038"?>

  <?rfc include="reference.RFC.8545"?>
  <?rfc include="reference.I-D.ietf-ippm-stamp-option-tlv"?>
 <?rfc include="reference.RFC.2104"?>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5357.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4656.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8186.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6335.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6038.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8545.xml"/>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/>
        <reference anchor="IEEE.1588.2008">
          <front>
<title>Standard
            <title>IEEE Standard for a Precision Clock Synchronization Protocol for
	    Networked Measurement and Control Systems</title>
            <author>
<organization/>
              <organization>IEEE</organization>
            </author>
            <date month="March" month="July" year="2008"/>
          </front>
            <seriesInfo name="IEEE" value="Standard 1588"/>
        </reference>
      </references>

  <references title="Informative References">

    <?rfc include="reference.RFC.4868"?>
    <?rfc include="reference.RFC.8085"?>
    <?rfc include="reference.RFC.7750"?>

   <?rfc include="reference.I-D.ietf-ippm-stamp-yang"?>
      <references>
        <name>Informative References</name>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4868.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7750.xml"/>
<!-- I-D.draft-ietf-ippm-stamp-yang: I-D Exists -->
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ippm-stamp-yang-05.xml"/>
<!--draft-ietf-ippm-stamp-option-tlv; I-D Exists -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ippm-stamp-option-tlv.xml"/>

        <reference anchor="BBF.TR-390">
          <front>
            <title>Performance Measurement from IP Edge to Customer Equipment
	    using TWAMP Light</title>
            <seriesInfo name="TR-390" value="Issue 1"/>
            <author>
<organization/>
              <organization>Broadband Forum</organization>
            </author>
            <date month="May" year="2017"/>
          </front>
<seriesInfo name="BBF" value="TR-390"/>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors express their appreciation to <contact fullname="Jose Ignacio Alvarez-Hamelin"/> and
<contact fullname="Brian Weis"/> for their great insights into the
security and identity protection as well as the most helpful and practical suggestions. Also, our sincere thanks to
<contact fullname="David Ball"/>, <contact fullname="Rakesh Gandhi"/>, and <contact fullname="Xiao Min"/> for
their thorough reviews and helpful comments.
      </t>
    </section>
  </back>
</rfc>