<?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"
docName="draft-ietf-ippm-otwamp-on-lag-08"
number="9533"
ipr="trust200902"
sortRefs="true"
submissionType="IETF" tocInclude="true">
tocInclude="true"
obsoletes=""
updates=""
xml:lang="en"
tocDepth="3"
symRefs="true"
version="3">

  <front>
    <title abbrev="O/TWAMP abbrev="OWAMP/TWAMP PM on LAG">One-way/Two-way LAG">One-Way and Two-Way Active Measurement
    Protocol Extensions for Performance Measurement on LAG</title> a Link Aggregation Group</title>
    <seriesInfo name="RFC" value="9533"/>
    <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>

    <abstract>
      <t>This document defines extensions to One-way the One-Way Active Measurement
      Protocol (OWAMP), (OWAMP) and Two-way the Two-Way Active Measurement Protocol (TWAMP) 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 the 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 every member link of a LAG. Hence, the measured performance metrics
      can work together with <xref target="RFC8668">layer Layer 2 bundle member link
      attributes advertisement</xref> advertisement <xref target="RFC8668" format="default"></xref> for traffic steering.</t>

      <t>According to the classifications in <xref target="RFC7799"/>, target="RFC7799" format="default"/>, OWAMP <xref
      target="RFC4656">OWAMP</xref> target="RFC4656" format="default"></xref> and TWAMP <xref target="RFC5357">TWAMP</xref> target="RFC5357" format="default"></xref>
      are active measurement methods, and they can complement passive and
      hybrid methods.  With either method, one 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
      test session cannot measure the performance of every physical member
      link.</t>
      <t>This document extends OWAMP and TWAMP to implement performance
      measurement on every member link of a LAG. It can provide the same
      metrics as OWAMP and TWAMP can measure, such as delay, jitter 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" format="default"/>, 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 OWAMP or TWAMP sessions
      established on member links of a LAG, test packets of micro TWAMP
      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 layer, 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 TWAMP
      Session-Sender receives a reflected test packet, it checks whether the
      test packet is from the expected member link.</t>
    </section>
    <section title="Micro numbered="true" toc="default">
      <name>Micro OWAMP Session"> Session</name>
      <section title="Micro OWAMP-Control"> numbered="true" toc="default" anchor="micro">
        <name>Micro OWAMP-Control</name>

        <t>To support the micro OWAMP session, a new command,
        Request-OW-Micro-Sessions (TBD1), (5), is defined in this document. The
        Request-OW-Micro-Sessions command is based on the OWAMP
        Request-Session command, command and uses the message format as described in
        Section 3.5 of
        <xref target="RFC4656">OWAMP</xref>. target="RFC4656" sectionFormat="of" section="3.5"></xref>. Test session
        creation of micro OWAMP session sessions follows the same procedure as defined
        in Section 3.5 of <xref target="RFC4656">OWAMP</xref> target="RFC4656" sectionFormat="of" section="3.5"></xref> with the
        following additions:</t>
        <t>When an OWAMP Server receives a Request-OW-Micro-Sessions command,
        if the request is accepted, the OWAMP Server MUST <bcp14>MUST</bcp14> build a set of micro
        sessions for all the member links of the LAG from which the
        Request-OW-Micro-Sessions message is received.</t>
      </section>
      <section title="Micro OWAMP-Test"> numbered="true" toc="default">
        <name>Micro OWAMP-Test</name>
        <t>Micro OWAMP-Test reuses the OWAMP-Test packet format and procedures
        as defined in Section 4 of <xref target="RFC4656">OWAMP</xref> target="RFC4656" sectionFormat="of" section="4"></xref> with
        the following additions:</t>
        <t>The micro OWAMP Session-Sender MUST <bcp14>MUST</bcp14> send the micro OWAMP-Test
        packets over the member link with which the session is associated.
        When it receives a test packet, the micro OWAMP Session-Receiver MUST <bcp14>MUST</bcp14>
        use the member link from which the test packet is received to
        correlate the micro OWAMP session. If there is no such a session, the
        Test
        test packet MUST <bcp14>MUST</bcp14> be discarded.</t>
      </section>
    </section>
    <section title="Micro numbered="true" toc="default">
      <name>Micro TWAMP Session"> Session</name>
      <section title="Micro TWAMP-Control"> numbered="true" toc="default" anchor="micro2">
        <name>Micro TWAMP-Control</name>
        <t>To support the micro TWAMP session, a new command,
        Request-TW-Micro-Sessions (TBD2), (11), is defined in this document. The
        Request-TW-Micro-Sessions command is based on the TWAMP
        Request-Session command, command and uses the message format as described in
        Section 3.5 of
        <xref target="RFC5357">TWAMP</xref>. target="RFC5357" sectionFormat="of" section="3.5"></xref>. Test session
        creation of micro TWAMP session sessions follows the same procedure as defined
        in Section 3.5 of <xref target="RFC5357">TWAMP</xref> target="RFC5357" sectionFormat="of" section="3.5"></xref> with the
        following additions:</t>
        <t>When a TWAMP Server receives a Request-TW-Micro-Sessions command,
        if the request is accepted, the TWAMP Server MUST <bcp14>MUST</bcp14> build a set of micro
        sessions for all the member links of the LAG from which the
        Request-TW-Micro-Sessions message is received.</t>
      </section>
      <section title="Micro TWAMP-Test"> numbered="true" toc="default">
        <name>Micro TWAMP-Test</name>
        <t>The micro TWAMP-Test protocol is based on the TWAMP-Test protocol
        <xref target="RFC5357"/> target="RFC5357" format="default"/> with the extensions described in the following extensions.</t> subsections.</t>
        <section title="Sender numbered="true" toc="default">
          <name>Sender Packet Format and Content"> Content</name>
          <t>The micro TWAMP Session-Sender packet format is based on the
          TWAMP Session-Sender packet format as defined in Section 4.1.2 of
          <xref target="RFC5357"/>. target="RFC5357" sectionFormat="of" section="4.1.2"/>. Two new fields (Sender Micro-session ID
          and Reflector Micro-session ID) are added to carry the LAG member
          link identifiers.</t>
          <t>For unauthenticated mode, the format is as below:</t>

          <t>
          <figure align="center" anchor="TWAMPSender"
                    title="Micro anchor="TWAMPSender">
            <name>Micro Session-Sender Packet Format in Unauthenticated Mode">
              <artwork><![CDATA[ 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               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Sender Micro-session ID    |   Reflector Micro-session ID  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                         Packet Padding                        .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          </t>
          <t>For authenticated and encrypted mode, the format is as below:<figure
              align="center" anchor="TWAMPSenderA"
              title="Micro below:</t>
          <figure anchor="TWAMPSenderA">
            <name>Micro Session-Sender Packet Format in Authenticated Mode">
              <artwork><![CDATA[ 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              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Sender Micro-session ID    |   Reflector Micro-session ID  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       HMAC (16 octets)                        |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                        Packet Padding                         .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure></t>
          </figure>

          <t>Except for the Sender/Reflector Sender Micro-session ID field and the Reflector Micro-session ID field, all the
          other fields are the same as defined in Section 4.1.2 of <xref
          target="RFC5357">TWAMP</xref>, which is defined in Section 4.1.2 of
          <xref target="RFC4656">OWAMP</xref>. Therefore, it follows target="RFC5357" sectionFormat="of" section="4.1.2"></xref> and follow the same procedure and guidelines as defined in Section 4.1.2 of <xref
          target="RFC5357">TWAMP</xref>.</t>

          <t>
            <list style="symbols">
              <t>Sender therein.</t>
          <dl spacing="normal">

              <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 TWAMP 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 TWAMP session at the Session-Reflector.</t>
            </list>
          </t>

          <t/> Session-Reflector.</dd>

          </dl>

        </section>
        <section title="Sender Behavior"> numbered="true" toc="default">
          <name>Sender Behavior</name>
          <t>The micro TWAMP Session-Sender inherits the behaviors of the
          TWAMP Session-Sender as defined in Section 4.1 of <xref
          target="RFC5357"/>. target="RFC5357" sectionFormat="of" section="4.1"/>. In addition, the micro TWAMP Session-Sender MUST <bcp14>MUST</bcp14>
          send the micro Session-Sender test packets over the member link with
          which the session is associated.</t>
          <t>When sending the test packet, the micro TWAMP Session-Sender MUST <bcp14>MUST</bcp14>
          put the Sender member link identifier that is associated with the
          micro TWAMP session in the Sender Micro-session ID. If the
          Session-Sender knows the Reflector member link identifier, the
          Reflector Micro-session ID field (see Figures <xref target="TWAMPSender"/> target="TWAMPSender" format="counter"/>
          and <xref target="TWAMPSenderA"/>) MUST target="TWAMPSenderA" format="counter"/>) <bcp14>MUST</bcp14> be set. Otherwise, the
          Reflector Micro-session ID field MUST <bcp14>MUST</bcp14> be zero.</t>
          <t>A test packet with a Sender member link identifier is sent to the
          Session-Reflector,
          Session-Reflector and then is reflected with the same Sender member
          link identifier. So the Session-Sender can use the Sender member
          link identifier to check whether a reflected test packet is received
          from the member link associated with the correct micro TWAMP
          session.</t>
          <t>The Reflector member link identifier carried in the Reflector
          Micro-session ID field is used by the Session-Reflector to check
          whether a test packet is received from the member link associated
          with the correct micro TWAMP session. It means that the
          Session-Sender has to learn the Reflector member link identifier.
          Once the Session-Sender knows the Reflector member link identifier,
          it MUST <bcp14>MUST</bcp14> put the identifier in the Reflector Micro-session ID field
          (see Figures <xref target="TWAMPSender"/> target="TWAMPSender" format="counter"/> or <xref target="TWAMPSenderA"/>) target="TWAMPSenderA" format="counter"/>)
          of the test packets that will be sent to the Session-Reflector. The
          Reflector member link identifier can be obtained from
          pre-configuration
          preconfiguration or learned from the 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 receiving a reflected test packet, the micro TWAMP
          Session-Sender MUST <bcp14>MUST</bcp14> use the receiving member link to correlate the
          reflected test packet to a micro TWAMP session. If there is no such
          a
          session, the reflected test packet MUST <bcp14>MUST</bcp14> be discarded. If a matched
          session exists, 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>
        </section>
        <section title="Reflector numbered="true" toc="default">
          <name>Reflector Packet Format and Content"> Content</name>
          <t>The micro TWAMP Session-Reflector packet format is based on the
          TWAMP Session-Reflector packet format as defined in Section 4.2.1 of
          <xref target="RFC5357"/>. target="RFC5357" sectionFormat="of" section="4.2.1"/>. Two new fields (Sender and Reflector
          Micro-session ID) are added to carry the LAG member link
          identifiers.</t>
          <t>For unauthenticated mode, the format is as below:</t>

          <t>

          <figure align="center" anchor="TWAMPReflector"
                    title="Micro anchor="TWAMPReflector">
            <name>Micro Session-Reflector Packet Format in Unauthenticated Mode">
              <artwork><![CDATA[ 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                       |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sender Sequence Number                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sender Timestamp                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Sender Error Estimate    |    Sender Micro-session ID    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sender TTL   |      MBZ      |   Reflector Micro-session ID  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                         Packet Padding                        .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          </t>
          <t>For authenticated and encrypted mode, the format is as below:</t>

          <t>

          <figure align="center" anchor="TWAMPReflectorA"
                    title="Micro anchor="TWAMPReflectorA">
            <name>Micro Session-Reflector Packet Format in Authenticated Mode">
              <artwork><![CDATA[ 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Sender Micro-session ID    |   Reflector Micro-session ID  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Receive Timestamp                      |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        MBZ (8 octets)                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sender Sequence Number                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        MBZ (12 octets)                        |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sender Timestamp                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Sender Error Estimate    |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                        MBZ (6 octets)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sender TTL   |                                               |
   +-+-+-+-+-+-+-+-+                                               +
   |                                                               |
   |                                                               |
   |                        MBZ (15 octets)                        |
   +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
   |                        HMAC (16 octets)                       |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                         Packet Padding                        .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          </t>
          <t>Except for the Sender/Reflector Sender Micro-session ID field and the Reflector Micro-session ID field, all the
          other fields are the same as defined in Section 4.2.1 of TWAMP <xref
          target="RFC5357"/>. Therefore, it follows target="RFC5357" sectionFormat="of" section="4.2.1"/> and follow the same procedure and guidelines as defined in Section 4.2.1 of TWAMP <xref
          target="RFC5357"/>.</t>

          <t>
            <list style="symbols">
              <t>Sender therein.</t>
          <dl spacing="normal">

              <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 TWAMP 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 TWAMP session at the Session-Reflector.</t>
            </list>
          </t> Session-Reflector.</dd>

          </dl>
        </section>
        <section title="Reflector Behavior"> numbered="true" toc="default">
          <name>Reflector Behavior</name>
          <t>The micro TWAMP Session-Reflector inherits the behaviors of a
          TWAMP Session-Reflector as defined in Section 4.2 of <xref
          target="RFC5357"/>.</t> target="RFC5357" sectionFormat="of" section="4.2"/>.</t>
          <t>In addition, when receiving a test packet, the micro TWAMP
          Session-Reflector MUST <bcp14>MUST</bcp14> use the receiving member link to correlate
          the test packet to a micro TWAMP session. If there is no such a
          session, the test packet MUST <bcp14>MUST</bcp14> be discarded. If the Reflector
          Micro-session ID is not zero, the Reflector MUST <bcp14>MUST</bcp14> use the Reflector
          Micro-session ID to validate whether it associates with the
          receiving member link. If the Reflector Micro-session ID is zero, it
          will not be verified. If the validation fails, the test packet MUST <bcp14>MUST</bcp14>
          be discarded.</t>
          <t>When sending a response to the received test packet, the micro
          TWAMP Session-Reflector MUST <bcp14>MUST</bcp14> copy the Sender member link identifier
          from the received test packet and put it in the Sender Micro-session
          ID field of the reflected test packet (see Figures <xref
          target="TWAMPReflector"/> target="TWAMPReflector" format="counter"/> and <xref target="TWAMPReflectorA"/>). target="TWAMPReflectorA" format="counter"/>). In
          addition, the micro TWAMP Session-Reflector MUST <bcp14>MUST</bcp14> fill the Reflector
          Micro-session ID field (see Figures <xref target="TWAMPReflector"/> target="TWAMPReflector" format="counter"/> and
          <xref target="TWAMPReflectorA"/>) target="TWAMPReflectorA" format="counter"/>) of the reflected test packet with
          the member link identifier that is associated with the micro TWAMP
          session.</t>
        </section>
      </section>
    </section>
    <section title="Applicability"> numbered="true" toc="default">
      <name>Applicability</name>
      <t>To set up the micro OWAMP sessions, the Control-Client firstly sends
      the Request-OW-Micro-Sessions command to the OWAMP Server. The OWAMP
      Server accepts the request, request and builds a set of micro sessions for all
      the member links of the LAG.</t>
      <t>For micro TWAMP sessions, the a similar set up procedure as micro OWAMP
      sessions is used. Then Then, the micro TWAMP Session-Sender sends micro
      Session-Sender packets with the Sender Micro-session ID and the
      Reflector Micro-session ID. The If the Reflector Micro-session ID field is set, the micro Session-Reflector checks whether a
      test packet is received from the member link associated with the correct
      micro TWAMP session, if the Reflector Micro-session ID field is set. session.
      When reflecting, the micro TWAMP Session-Reflector copies the Sender
      Micro-session ID from the received micro Session-Sender packet to the
      micro Session-Reflector packet, and packet; then, it sets the Reflector Micro-session ID
      field with the member link identifier that is associated with the micro
      TWAMP session. When receiving the micro TWAMP 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 TWAMP session. The micro Session-Sender also uses the
      Reflector Micro-session ID to validate the Reflector's behavior.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section title="Micro numbered="true" toc="default">
        <name>Micro OWAMP-Control Command">
        <t>This document requires the IANA to allocate Command</name>
        <t>IANA has allocated the following command
        type from OWAMP-Control the "OWAMP-Control Command Number Registry.</t>

        <t>
          <figure>
            <artwork><![CDATA[Value  Description                   Semantics Definition
TBD1   Request-OW-Micro-Sessions     This document, Section 3.1
]]></artwork>
          </figure>
        </t> Numbers" registry.</t>

	<table anchor="micro_OWAMP" align="left">
	  <name>Request-OW-Micro-Sessions Command Number</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">5</td>
	      <td align="left">Request-OW-Micro-Sessions</td>
	      <td align="left">This document</td>
	    </tr>
	  </tbody>
	</table>

      </section>
      <section title="Micro numbered="true" toc="default">
        <name>Micro TWAMP-Control Command">
        <t>This document requires the IANA to allocate Command</name>
        <t>IANA has allocated the following command
        type from TWAMP-Control the "TWAMP-Control Command Number Registry.</t>

        <t>
          <figure>
            <artwork><![CDATA[Value  Description                   Semantics Definition
TBD2   Request-TW-Micro-Sessions     This document, Section 4.1
]]></artwork>
          </figure>
        </t> Numbers" registry.</t>

	<table anchor="micro_TWAMP" align="left">
	  <name>Request-TW-Micro-Sessions Command Number</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">11</td>
	      <td align="left">Request-TW-Micro-Sessions</td>
	      <td align="left">This document</td>
	    </tr>
	  </tbody>
	</table>
      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document does not introduce additional security requirements and
      mechanisms other than those described in <xref target="RFC4656"/>, target="RFC4656" format="default"/> and
      <xref target="RFC5357"/>.</t>
    </section>

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

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

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

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

      <?rfc include='reference.RFC.5357'?>
    <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.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"/>
      </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
<title>
IEEE Standard for Local and metropolitan area networks - Metropolitan Area Networks -- Link
          Aggregation</title> 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.9256'?>

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

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