<?xml version="1.0" encoding="US-ASCII"?> version='1.0' 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"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
category="std"
consensus="true"
number="9534"
docName="draft-ietf-ippm-stamp-on-lag-06"
ipr="trust200902"
sortRefs="true"
submissionType="IETF" tocInclude="true">
tocInclude="true"
obsoletes=""
updates=""
xml:lang="en"
tocDepth="3"
symRefs="true"
version="3">

  <front>
    <title abbrev="STAMP PM on LAG">Simple Two-Way Active Measurement Protocol
    Extensions for Performance Measurement on LAG</title> a Link Aggregation Group</title>
    <seriesInfo name="RFC" value="9534"/>
    <author fullname="Zhenqiang Li" initials="Z." surname="Li">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <street>No. 29 Finance Avenue, Xicheng District</street> Avenue</street>
          <cityarea>Xicheng District</cityarea>
          <city>Beijing</city>
          <code/>
          <country>China</country>
        </postal>
        <email>li_zhenqiang@hotmail.com</email>
      </address>
    </author>
    <author fullname="Tianran Zhou" initials="T." surname="Zhou">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street/>
          <country>China</country>
        </postal>
        <email>zhoutianran@huawei.com</email>
      </address>
    </author>
    <author fullname="Jun Guo" initials="J." surname="Guo">
      <organization>ZTE Corp.</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>
          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>
        <email>guo.jun2@zte.com.cn</email>
        <uri/>
      </address>
    </author>
    <author fullname="Greg Mirsky" initials="G." surname="Mirsky">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street/>
          <country>United States of America</country>
        </postal>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    <author fullname="Rakesh Gandhi" initials="R." surname="Gandhi">
      <organization>Cisco</organization>
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>
          <country>Canada</country>
        </postal>

        <phone/>

        <facsimile/>
        <email>rgandhi@cisco.com</email>
        <uri/>
      </address>
    </author>

    <date day="11" month="December" year="2023"/>

    <area>Operation and Management month="January" year="2024"/>

    <area>Transport Area</area>
    <workgroup>IPPM</workgroup>

<keyword>STAMP</keyword>
<keyword>Performance Measurement</keyword>
<keyword>LAG</keyword>
<keyword>Micro Session</keyword>

    <abstract>
      <t>This document extends Simple Two-Way Two-way Active Measurement Protocol
      (STAMP) to implement performance measurement on every member link of a
      Link Aggregation Group (LAG). Knowing the measured metrics of each
      member link of a LAG enables operators to enforce a performance based performance-based
      traffic steering policy across the member links.</t>
    </abstract>

    <note title="Requirements Language">
      <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"/> <xref target="RFC8174"/> when, and only when,
      they appear in all capitals, as shown here.</t>
    </note>

  </front>
  <middle>
    <section title="Introduction">
      <t>Link numbered="true" toc="default">
      <name>Introduction</name>
      <t>A Link Aggregation Group (LAG), as defined in <xref
      target="IEEE802.1AX"/>, target="IEEE802.1AX" format="default"/>, provides mechanisms to combine multiple physical
      links into a single logical link. This logical link offers higher
      bandwidth and better resiliency, because resiliency because, if one of the physical member
      links fails, the aggregate logical link can continue to forward traffic
      over the remaining operational physical member links.</t>
      <t>Usually, when forwarding traffic over a LAG, a hash-based mechanism is
      used to load balance the traffic across the LAG member links. The link
      delay might vary between member links because of different transport
      paths, especially when a LAG is used in a wide area network. To provide low
      latency
      low-latency service for time sensitive time-sensitive traffic, we need to explicitly steer
      the traffic across the LAG member links based on the link delay, loss loss,
      and so on. That requires a solution to measure the performance metrics
      of each member link of a LAG. Hence, the measured performance metrics
      can work together with <xref target="RFC8668">layer target="RFC8668" format="default">Layer 2 bundle member link
      attributes advertisement</xref> for traffic steering.</t>
      <t>According to the classifications in <xref target="RFC7799"/>, target="RFC7799" format="default"/>, <xref
      target="RFC8762">Simple Two-Way target="RFC8762" format="default">Simple Two-way Active Measurement Protocol
      (STAMP)</xref> is an active measurement method, and it can complement
      passive and hybrid methods. It provides a mechanism to measure both
      one-way and round-trip performance metrics, like delay, delay variation,
      and packet loss. One A STAMP test session over the LAG can be used to measure the
      performance of a member link with fixed five tuples. Or it using a specially constructed 5-tuple. The session can be used to measure
      an average of some/all some or all member links of the LAG by varying the five
      tuples. one or more elements of that
      5-tuple. However, without the knowledge of each member link, a STAMP test
      session cannot measure the performance of every physical member
      link.</t>
      <t>This document extends STAMP to implement performance measurement on
      every member link of a LAG. It can provide the same metrics as <xref
      target="RFC4656">OWAMP</xref> target="RFC4656" format="default">One-Way Active Measurement Protocol (OWAMP)</xref> and <xref target="RFC5357">TWAMP</xref> target="RFC5357" format="default">Two-Way Active Measurement Protocol (TWAMP)</xref>
      can measure, such as delay, jitter, and packet loss.</t>
    <section numbered="true" toc="default">
      <name>Requirements Language</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t>
    </section>
    </section>
    <section title="Micro Session numbered="true" toc="default">
      <name>Micro Sessions on LAG"> a LAG</name>
      <t>This document addresses the scenario where a LAG directly connects
      two nodes. An example of this is in Figure 1, <xref target="PMonLAG"/>, where the LAG consisting
      of four links connects nodes A and B. The goal is to measure the
      performance of each link of the LAG.</t>
      <figure align="center" anchor="PMonLAG"
              title="Performance anchor="PMonLAG">
        <name>Performance Measurement on LAG">
        <artwork><![CDATA[+---+ a LAG</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[                  +---+                       +---+
                  |   |-----------------------|   |
                  | A |-----------------------| B |
                  |   |-----------------------|   |
                  |   |-----------------------|   |
                  +---+                       +---+
]]></artwork>
      </figure>
      <t>To measure the performance metrics of every member link of a LAG,
      multiple sessions (one session for each member link) need to be
      established between the two end points endpoints that are connected by the LAG.
      These sessions are called micro sessions "micro sessions" in the remainder of this
      document. Although micro sessions are in fact STAMP sessions established
      on member links of a LAG, test packets of micro sessions MUST <bcp14>MUST</bcp14> carry
      member link information for validation.</t>
      <t>All micro sessions of a LAG share the same Sender IP Address and
      Receiver IP Address of the LAG. Address. As for the UDP Port, port, the micro sessions
      may share the same Sender Port and Receiver Port pair, pair or each micro
      session is may be configured with a different Sender Port and Receiver Port
      pair. But from From the operational point of view, the former is simpler and
      is RECOMMENDED.</t> <bcp14>RECOMMENDED</bcp14>.</t>
      <t>Test packets of a micro session MUST <bcp14>MUST</bcp14> carry the member link
      information for validation check. checks. For example, when a micro STAMP
      Session-Sender receives a reflected test packet, it checks whether the
      test packet is from the expected member link. The member link
      information is encoded in the Micro-session ID TLV introduced in Section
      3 of this document, and the <xref target="validation"/>,
      which also provides a detailed description about the  member link
      validation is also in this section.</t>
      validation.</t>
      <t>A micro STAMP Session-Sender MAY <bcp14>MAY</bcp14> include the <xref
      target="RFC8972">Follow-Up target="RFC8972" format="default">Follow-Up Telemetry TLV</xref> to request information
      from the micro Session-Reflector. This timestamp might be important for
      the micro Session-Sender, as it improves the accuracy of network delay
      measurement by minimizing the impact of egress queuing delays on the
      measurement.</t>
    </section>
    <section title="Member numbered="true" toc="default" anchor="validation">
      <name>Member Link Validation"> Validation</name>
      <t>Test packets MUST <bcp14>MUST</bcp14> carry member link information in the Micro-session ID
      TLV introduced in this section for validation check. checks. The micro
      Session-Sender verifies whether the test packet is received from the
      expected member link. It also verifies whether the packet is sent from
      the expected member link at the Reflector side. The micro
      Session-Reflector verifies whether the test packet is received from the
      expected member link.</t>
      <section title="Micro-session numbered="true" toc="default">
        <name>Micro-session ID TLV">
        <t><xref target="RFC8972">STAMP TLV</xref> mechanism TLV</name>
        <t>The <xref target="RFC8972" format="default">STAMP TLV mechanism</xref> extends STAMP
        test packets with one or more optional TLVs. This document defines the
        TLV Type (value TBA1) 11) for the Micro-session ID TLV that carries the
        micro STAMP Session-Sender member link identifier and
        Session-Reflector member link identifier in the Sender Micro-session ID
        field and the Reflector Micro-session ID field field, respectively. The format of
        the Micro-session ID TLV is shown as follows:</t>

        <t>
        <figure align="center" anchor="STAMPSender"
                  title="Micro-session anchor="STAMPSender">
          <name>Micro-session ID TLV">
            <artwork><![CDATA[ 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|  Type = TBA1 11    |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Sender Micro-session ID   |   Reflector Micro-session ID  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

          <list style="symbols">
            <t>Type (one-octet
        <dl spacing="normal">
          <dt>Type (1 octet in length): It length):</dt>
          <dd>This field is defined to indicate this TLV
            is a Micro-session ID TLV. Value TBA1 is 11 has been allocated by IANA
            (Section 5).</t>

            <t>Length (2-octets
            (<xref target="IANA"/>).</dd>
          <dt>Length (2 octets in length): It length):</dt>
          <dd>This field is defined to carry the length
            of the Value field in octets. The Length field value MUST <bcp14>MUST</bcp14> be
            4.</t>

            <t>Sender
            4.</dd>
            <dt>Sender Micro-session ID (2-octets (2 octets in length): It length):</dt>
            <dd>This field is now defined
            to carry the LAG member link identifier of the Sender side. In the
            future, it may be used generically to cover use-cases use cases beyond LAG. LAGs.
            The value of this field MUST <bcp14>MUST</bcp14> be unique within a STAMP session at
            the Session-Sender.</t>

            <t>Reflector Session-Sender.</dd>
            <dt>Reflector Micro-session ID (2-octets (2 octets in length): It length):</dt>
            <dd>This field is now
            defined to carry the LAG member link identifier of the Reflector
            side. In the future, it may be used generically to cover use-cases use cases
            beyond LAG. LAGs. The value of this field MUST <bcp14>MUST</bcp14> be unique within a STAMP
            session at the Session-Reflector.</t>
          </list>
        </t> Session-Reflector.</dd>
        </dl>
      </section>
      <section title="Micro numbered="true" toc="default">
        <name>Micro STAMP-Test Procedures"> Procedures</name>
        <t>The micro STAMP-Test reuses the procedures as defined in Section 4
        <xref target="RFC8762" sectionFormat="bare" section="4" format="default"/> of
        <xref target="RFC8762">STAMP</xref> target="RFC8762" format="default">STAMP</xref> with the following
        additions.</t>
        <t>The micro STAMP Session-Sender MUST <bcp14>MUST</bcp14> send the micro STAMP-Test
        packets over the member link with which the session is associated. The
        mapping between a micro STAMP session and the Sender/Reflector member
        link identifiers can be configured by augmenting the <xref
        target="I-D.ietf-ippm-stamp-yang">STAMP
        target="I-D.ietf-ippm-stamp-yang" format="default">STAMP
        YANG</xref>. The detailed augmentation is not in the scope of this
        document.</t>
        <t>When sending a test packet, the micro STAMP Session-Sender MUST <bcp14>MUST</bcp14> set
        the Sender Micro-session ID field with the member link identifier
        associated with the micro STAMP session. If the Session-Sender knows
        the Reflector member link identifier, the Reflector Micro-session ID
        field MUST <bcp14>MUST</bcp14> be set. Otherwise, the Reflector Micro-session ID field
        MUST
        <bcp14>MUST</bcp14> be zero. The Reflector member link identifier can be obtained
        from pre-configuration preconfiguration or learned from data plane (e.g., the reflected
        test packet). This document does not specify the way to obtain the
        Reflector member link identifier.</t>
        <t>When the micro STAMP Session-Reflector receives a test packet, if
        the Reflector Micro-session ID is not zero, the micro STAMP
        Session-Reflector MUST <bcp14>MUST</bcp14> use the Reflector member link identifier to
        check whether it is associated with the micro STAMP session. If the
        validation fails, the test packet MUST <bcp14>MUST</bcp14> be discarded. If the Reflector
        Micro-session ID is zero, it will not be verified. If all validations
        passed, the Session-Reflector sends a reflected test packet to the
        Session-Sender. The micro STAMP Session-Reflector MUST <bcp14>MUST</bcp14> put the Sender
        and Reflector member link identifiers that are associated with the
        micro STAMP session in the Sender Micro-session ID and Reflector
        Micro-session ID fields fields, respectively. The Sender member link
        identifier is copied from the received test packet.</t>
        <t>When receiving a reflected test packet, the micro Session-Sender
        MUST
        <bcp14>MUST</bcp14> use the Sender Micro-session ID to validate whether the reflected
        test packet is correctly received from the expected member link. If
        the validation fails, the test packet MUST <bcp14>MUST</bcp14> be discarded. The micro
        Session-Sender MUST <bcp14>MUST</bcp14> use the Reflector Micro-session ID to validate the
        Reflector's behavior. If the validation fails, the test packet MUST <bcp14>MUST</bcp14> be
        discarded.</t>
        <t>Two modes of the STAMP Session-Reflector, stateless and stateful,
        characterize the expected behavior, behavior as described in Section 4 <xref target="RFC8762" sectionFormat="bare" section="4" format="default"/> of <xref
        target="RFC8762">STAMP</xref>. target="RFC8762" format="default">STAMP</xref>. The micro STAMP-Test also supports both
        stateless and stateful modes. However, the micro STAMP-Test does not
        introduce any additional state to STAMP, i.e, i.e., any procedure with
        regard to the Micro-session ID is stateless.</t>
      </section>
    </section>
    <section title="Applicability"> numbered="true" toc="default">
      <name>Applicability</name>
      <t>The micro STAMP Session-Sender sends micro Session-Sender packets
      with the Micro-session ID TLV. The micro Session-Reflector checks
      whether a test packet is received from the member link associated with
      the correct micro STAMP session, session if the Reflector Micro-session ID field
      is set. When reflecting, the micro STAMP Session-Reflector copies the
      Sender Micro-session ID from the received micro Session-Sender packet to
      the micro Session-Reflector packet, packet and sets the Reflector Micro-session
      ID field with the member link identifier that is associated with the
      micro STAMP session. When receiving the micro Session-Reflector packet,
      the micro Session-Sender uses the Sender Micro-session ID to check
      whether the packet is received from the member link associated with the
      correct micro STAMP session. The micro Session-Sender also use the
      Reflector Micro-session ID to validate the Reflector's behavior.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>In numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has allocated the "STAMP TLV Types" registry created for [RFC8972], a new following STAMP
      TLV Type for the Micro-session ID TLV is requested from IANA as
      follows:<figure align="center" title="New STAMP in the "STAMP TLV Type">
          <artwork><![CDATA[+----------------+-------------------+-----------------+------------+
| Types" registry <xref target="RFC8972" format="default"/>:</t>
      <table anchor="reg_table">
        <name>New STAMP TLV Type | Description       | Semantics       | Reference  |
| Value          |                   | Definition      |            |
+----------------+-------------------+-----------------+------------+
| TBA1           | Micro-session     | Section 3       | This       |
|                | ID TLV            |                 | Document   |
+----------------+-------------------+-----------------+------------+]]></artwork>
        </figure></t> Type</name>
        <thead>
	  <tr>
            <th>Value</th>
            <th>Description</th>
            <th>Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>11</td>
            <td>Micro-session ID</td>
            <td>This Document</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The STAMP extension defined in this document is intended for
      deployment in the LAG scenario where Session-Sender and Session-Reflector
      are directly connected. As such, it's assumed that a node involved in
      a STAMP protocol operation has previously verified the integrity of the
      LAG connection and the identity of its one-hop-away peer node.</t>
      <t>This document does not introduce any additional security issues issues, and
      the security mechanisms defined in <xref target="RFC8762"/> target="RFC8762" format="default"/> and <xref
      target="RFC8972"/> target="RFC8972" format="default"/> apply in this document.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Mach Chen, Min Xiao, Fang Xin, Marcus
      Ihlar, Richard Foote for the valuable comments to this work.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.8762'?>

      <?rfc include='reference.RFC.8972'?>

    <displayreference target="I-D.ietf-ippm-stamp-yang" to="STAMP-YANG"/>

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

    <references title="Informative References">
      <references>
        <name>Informative References</name>

        <reference anchor="IEEE802.1AX"> anchor="IEEE802.1AX" target="https://ieeexplore.ieee.org/document/9105034">
          <front>
            <title>IEEE Standard for Local and metropolitan area networks - Metropolitan Area Networks -- Link
          Aggregation</title>
            <author>
            <organization>IEEE Std. 802.1AX</organization>
              <organization>IEEE</organization>
            </author>
            <date month="November" year="2008"/> month="May" year="2020"/>
          </front>
          <seriesInfo name="IEEE Std" value="802.1AX-2020"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9105034"/>
        </reference>

      <?rfc include='reference.RFC.7799'?>

      <?rfc include='reference.RFC.8668'?>

      <?rfc include='reference.RFC.4656'?>

      <?rfc include='reference.RFC.5357'?>

      <?rfc include='reference.I-D.ietf-ippm-stamp-yang'?>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8668.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4656.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5357.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ippm-stamp-yang.xml"/>

      </references>
    </references>

    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank <contact fullname="Mach Chen"/>, <contact fullname="Min Xiao"/>, <contact fullname="Fang Xin"/>, <contact fullname="Marcus Ihlar"/>, and <contact fullname="Richard Foote"/> for the valuable comments to this work.</t>
    </section>
  </back>
</rfc>