<?xmlversion="1.0" encoding="US-ASCII"?> <!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"?>version='1.0' encoding='utf-8'?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" 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" prepTime="2024-01-31T15:57:19" indexInclude="true" scripts="Common,Latin"> <link href="https://datatracker.ietf.org/doc/draft-ietf-ippm-otwamp-on-lag-08" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc9533" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <titleabbrev="O/TWAMPabbrev="OWAMP/TWAMP PM onLAG">One-way/Two-wayLAG">One-Way and Two-Way Active Measurement Protocol Extensions for Performance Measurement onLAG</title>a Link Aggregation Group</title> <seriesInfo name="RFC" value="9533" stream="IETF"/> <author fullname="Zhenqiang Li" initials="Z." surname="Li"><organization>China<organization showOnFrontPage="true">China Mobile</organization> <address> <postal> <street>No. 29 FinanceAvenue, 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><organization showOnFrontPage="true">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<organization showOnFrontPage="true">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><organization showOnFrontPage="true">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 showOnFrontPage="true">Cisco Systems, Inc.</organization> <address> <postal><street/> <city/> <region/> <code/><country>Canada</country> </postal> <phone/><facsimile/><email>rgandhi@cisco.com</email> <uri/> </address> </author> <dateday="11" month="December" year="2023"/> <area>Operation and Managementmonth="01" year="2024"/> <area>Transport Area</area> <workgroup>IPPM</workgroup><abstract> <t>This<abstract pn="section-abstract"> <t indent="0" pn="section-abstract-1">This document defines extensions toOne-waythe One-Way Active Measurement Protocol(OWAMP),(OWAMP) andTwo-waythe 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 theperformance basedperformance-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",<boilerplate> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1"> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name> <t indent="0" pn="section-boilerplate.1-1"> This is an Internet Standards Track document. </t> <t indent="0" pn="section-boilerplate.1-2"> This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and"OPTIONAL"has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. </t> <t indent="0" pn="section-boilerplate.1-3"> Information about the current status of thisdocument aredocument, any errata, and how to provide feedback on it may beinterpretedobtained at <eref target="https://www.rfc-editor.org/info/rfc9533" brackets="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2"> <name slugifiedName="name-copyright-notice">Copyright Notice</name> <t indent="0" pn="section-boilerplate.2-1"> Copyright (c) 2024 IETF Trust and the persons identified asdescribed inthe document authors. All rights reserved. </t> <t indent="0" pn="section-boilerplate.2-2"> This document is subject to BCP14 <xref target="RFC2119"/> <xref target="RFC8174"/> when,78 andonly when,the IETF Trust's Legal Provisions Relating to IETF Documents (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of publication of this document. Please review these documents carefully, as theyappeardescribe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described inall capitals,Section 4.e of the Trust Legal Provisions and are provided without warranty asshown here.</t> </note>described in the Revised BSD License. </t> </section> </boilerplate> <toc> <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2"> <li pn="section-toc.1-1.1.2.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.2"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-micro-sessions-on-a-lag">Micro Sessions on a LAG</xref></t> </li> <li pn="section-toc.1-1.3"> <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-micro-owamp-session">Micro OWAMP Session</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2"> <li pn="section-toc.1-1.3.2.1"> <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-micro-owamp-control">Micro OWAMP-Control</xref></t> </li> <li pn="section-toc.1-1.3.2.2"> <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-micro-owamp-test">Micro OWAMP-Test</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.4"> <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-micro-twamp-session">Micro TWAMP Session</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2"> <li pn="section-toc.1-1.4.2.1"> <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-micro-twamp-control">Micro TWAMP-Control</xref></t> </li> <li pn="section-toc.1-1.4.2.2"> <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-micro-twamp-test">Micro TWAMP-Test</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2"> <li pn="section-toc.1-1.4.2.2.2.1"> <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-sender-packet-format-and-co">Sender Packet Format and Content</xref></t> </li> <li pn="section-toc.1-1.4.2.2.2.2"> <t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-sender-behavior">Sender Behavior</xref></t> </li> <li pn="section-toc.1-1.4.2.2.2.3"> <t indent="0" pn="section-toc.1-1.4.2.2.2.3.1"><xref derivedContent="4.2.3" format="counter" sectionFormat="of" target="section-4.2.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-reflector-packet-format-and">Reflector Packet Format and Content</xref></t> </li> <li pn="section-toc.1-1.4.2.2.2.4"> <t indent="0" pn="section-toc.1-1.4.2.2.2.4.1"><xref derivedContent="4.2.4" format="counter" sectionFormat="of" target="section-4.2.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-reflector-behavior">Reflector Behavior</xref></t> </li> </ul> </li> </ul> </li> <li pn="section-toc.1-1.5"> <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-applicability">Applicability</xref></t> </li> <li pn="section-toc.1-1.6"> <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2"> <li pn="section-toc.1-1.6.2.1"> <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-micro-owamp-control-command">Micro OWAMP-Control Command</xref></t> </li> <li pn="section-toc.1-1.6.2.2"> <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-micro-twamp-control-command">Micro TWAMP-Control Command</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.7"> <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t> </li> <li pn="section-toc.1-1.8"> <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2"> <li pn="section-toc.1-1.8.2.1"> <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t> </li> <li pn="section-toc.1-1.8.2.2"> <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.9"> <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t> </li> <li pn="section-toc.1-1.10"> <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t> </li> </ul> </section> </toc> </front> <middle> <sectiontitle="Introduction"> <t>Linknumbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t indent="0" pn="section-1-1">A Link Aggregation Group (LAG), as defined in <xreftarget="IEEE802.1AX"/>,target="IEEE802.1AX" format="default" sectionFormat="of" derivedContent="IEEE802.1AX"/>, provides mechanisms to combine multiple physical links into a single logical link. This logical link offers higher bandwidth and betterresiliency, becauseresiliency 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,<t indent="0" pn="section-1-2">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 providelow latencylow-latency service fortime sensitivetime-sensitive traffic, we need to explicitly steer the traffic across the LAG member links based on the link delay,lossloss, 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">layerLayer 2 bundle member link attributesadvertisement</xref>advertisement <xref target="RFC8668" format="default" sectionFormat="of" derivedContent="RFC8668"/> for traffic steering.</t><t>According<t indent="0" pn="section-1-3">According to the classifications in <xreftarget="RFC7799"/>,target="RFC7799" format="default" sectionFormat="of" derivedContent="RFC7799"/>, OWAMP <xreftarget="RFC4656">OWAMP</xref>target="RFC4656" format="default" sectionFormat="of" derivedContent="RFC4656"/> and TWAMP <xreftarget="RFC5357">TWAMP</xref>target="RFC5357" format="default" sectionFormat="of" derivedContent="RFC5357"/> 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 linkwith fixed five tuples. Or itusing a specially constructed 5-tuple. The session can be used to measure an average ofsome/allsome or all member links of the LAG by varyingthe 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<t indent="0" pn="section-1-4">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,jitterjitter, and packet loss.</t> <section numbered="true" toc="include" removeInRFC="false" pn="section-1.1"> <name slugifiedName="name-requirements-language">Requirements Language</name> <t indent="0" pn="section-1.1-1"> 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 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> </section> <sectiontitle="Micro Sessionnumbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-micro-sessions-on-a-lag">Micro Sessions onLAG"> <t>Thisa LAG</name> <t indent="0" pn="section-2-1">This document addresses the scenario where a LAG directly connects two nodes. An example of this is inFigure 1,<xref target="PMonLAG" format="default" sectionFormat="of" derivedContent="Figure 1"/>, 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> <figurealign="center"anchor="PMonLAG"title="Performancealign="left" suppress-title="false" pn="figure-1"> <name slugifiedName="name-performance-measurement-on-">Performance Measurement onLAG"> <artwork><![CDATA[a LAG</name> <artwork name="" type="" align="left" alt="" pn="section-2-2.1"> +---+ +---+ | |-----------------------| | | A |-----------------------| B | | |-----------------------| | | |-----------------------| | +---+ +---+]]></artwork></artwork> </figure><t>To<t indent="0" pn="section-2-3">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 twoend pointsendpoints that are connected by the LAG. These sessions are calledmicro 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 sessionsMUST<bcp14>MUST</bcp14> carry member link information for validation.</t><t>All<t indent="0" pn="section-2-4">All micro sessions of a LAG share the same Sender IP Address and Receiver IPAddress of the LAG.Address. As for the UDPlayer,port, the micro sessions may share the same Sender Port and Receiver Portpair,pair or each micro sessionismay be configured with a different Sender Port and Receiver Port pair.But fromFrom the operational point of view, the former is simpler and isRECOMMENDED.</t> <t>Test<bcp14>RECOMMENDED</bcp14>.</t> <t indent="0" pn="section-2-5">Test packets of a micro sessionMUST<bcp14>MUST</bcp14> carry the member link information for validationcheck.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> <sectiontitle="Micronumbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-micro-owamp-session">Micro OWAMPSession">Session</name> <sectiontitle="Micro OWAMP-Control"> <t>Tonumbered="true" toc="include" anchor="micro" removeInRFC="false" pn="section-3.1"> <name slugifiedName="name-micro-owamp-control">Micro OWAMP-Control</name> <t indent="0" pn="section-3.1-1">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-Sessioncommand,command and uses the message format as described inSection 3.5 of<xreftarget="RFC4656">OWAMP</xref>.target="RFC4656" sectionFormat="of" section="3.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4656#section-3.5" derivedContent="RFC4656"/>. Test session creation of micro OWAMPsessionsessions follows the same procedure as defined inSection 3.5 of<xreftarget="RFC4656">OWAMP</xref>target="RFC4656" sectionFormat="of" section="3.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4656#section-3.5" derivedContent="RFC4656"/> with the following additions:</t><t>When<t indent="0" pn="section-3.1-2">When an OWAMP Server receives a Request-OW-Micro-Sessions command, if the request is accepted, the OWAMP ServerMUST<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> <sectiontitle="Micro OWAMP-Test"> <t>Micronumbered="true" toc="include" removeInRFC="false" pn="section-3.2"> <name slugifiedName="name-micro-owamp-test">Micro OWAMP-Test</name> <t indent="0" pn="section-3.2-1">Micro OWAMP-Test reuses the OWAMP-Test packet format and procedures as defined inSection 4 of<xreftarget="RFC4656">OWAMP</xref>target="RFC4656" sectionFormat="of" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4656#section-4" derivedContent="RFC4656"/> with the following additions:</t><t>The<t indent="0" pn="section-3.2-2">The micro OWAMP Session-SenderMUST<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-ReceiverMUST<bcp14>MUST</bcp14> use the member link from which the test packet is received to correlate the micro OWAMP session. If there is no suchasession, theTesttest packetMUST<bcp14>MUST</bcp14> be discarded.</t> </section> </section> <sectiontitle="Micronumbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-micro-twamp-session">Micro TWAMPSession">Session</name> <sectiontitle="Micro TWAMP-Control"> <t>Tonumbered="true" toc="include" anchor="micro2" removeInRFC="false" pn="section-4.1"> <name slugifiedName="name-micro-twamp-control">Micro TWAMP-Control</name> <t indent="0" pn="section-4.1-1">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-Sessioncommand,command and uses the message format as described inSection 3.5 of<xreftarget="RFC5357">TWAMP</xref>.target="RFC5357" sectionFormat="of" section="3.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5357#section-3.5" derivedContent="RFC5357"/>. Test session creation of micro TWAMPsessionsessions follows the same procedure as defined inSection 3.5 of<xreftarget="RFC5357">TWAMP</xref>target="RFC5357" sectionFormat="of" section="3.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5357#section-3.5" derivedContent="RFC5357"/> with the following additions:</t><t>When<t indent="0" pn="section-4.1-2">When a TWAMP Server receives a Request-TW-Micro-Sessions command, if the request is accepted, the TWAMP ServerMUST<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> <sectiontitle="Micro TWAMP-Test"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-4.2"> <name slugifiedName="name-micro-twamp-test">Micro TWAMP-Test</name> <t indent="0" pn="section-4.2-1">The micro TWAMP-Test protocol is based on the TWAMP-Test protocol <xreftarget="RFC5357"/>target="RFC5357" format="default" sectionFormat="of" derivedContent="RFC5357"/> with the extensions described in the followingextensions.</t>subsections.</t> <sectiontitle="Sendernumbered="true" toc="include" removeInRFC="false" pn="section-4.2.1"> <name slugifiedName="name-sender-packet-format-and-co">Sender Packet Format andContent"> <t>TheContent</name> <t indent="0" pn="section-4.2.1-1">The micro TWAMP Session-Sender packet format is based on the TWAMP Session-Sender packet format as defined inSection 4.1.2 of<xreftarget="RFC5357"/>.target="RFC5357" sectionFormat="of" section="4.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5357#section-4.1.2" derivedContent="RFC5357"/>. Two new fields (Sender Micro-session ID and Reflector Micro-session ID) are added to carry the LAG member link identifiers.</t><t>For<t indent="0" pn="section-4.2.1-2">For unauthenticated mode, the format is as below:</t><t><figurealign="center"anchor="TWAMPSender"title="Microalign="left" suppress-title="false" pn="figure-2"> <name slugifiedName="name-micro-session-sender-packet">Micro Session-Sender Packet Format in UnauthenticatedMode"> <artwork><![CDATA[Mode</name> <artwork name="" type="" align="left" alt="" pn="section-4.2.1-3.1"> 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></artwork> </figure></t> <t>For<t indent="0" pn="section-4.2.1-4">For authenticated and encrypted mode, the format is asbelow:<figure align="center"below:</t> <figure anchor="TWAMPSenderA"title="Microalign="left" suppress-title="false" pn="figure-3"> <name slugifiedName="name-micro-session-sender-packet-">Micro Session-Sender Packet Format in AuthenticatedMode"> <artwork><![CDATA[Mode</name> <artwork name="" type="" align="left" alt="" pn="section-4.2.1-5.1"> 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> <t>Except</artwork> </figure> <t indent="0" pn="section-4.2.1-6">Except for theSender/ReflectorSender Micro-session ID field and the Reflector Micro-session ID field, all the other fields are the same as defined inSection 4.1.2 of <xref target="RFC5357">TWAMP</xref>, which is defined in Section 4.1.2 of<xreftarget="RFC4656">OWAMP</xref>. Therefore, it followstarget="RFC5357" sectionFormat="of" section="4.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5357#section-4.1.2" derivedContent="RFC5357"/> and follow thesameprocedure and guidelinesasdefinedin Section 4.1.2 of <xref target="RFC5357">TWAMP</xref>.</t> <t> <list style="symbols"> <t>Sendertherein.</t> <dl spacing="normal" indent="3" newline="false" pn="section-4.2.1-7"> <dt pn="section-4.2.1-7.1">Sender Micro-session ID(2-octets(2 octets inlength): Itlength):</dt> <dd pn="section-4.2.1-7.2">This field isnowdefined to carry the LAG member link identifier of the Sender side. In the future, it may be used generically to coveruse-casesuse cases beyondLAG.LAGs. The value of this fieldMUST<bcp14>MUST</bcp14> be unique within a TWAMP session at theSession-Sender.</t> <t>ReflectorSession-Sender.</dd> <dt pn="section-4.2.1-7.3">Reflector Micro-session ID(2-octets(2 octets inlength): Itlength):</dt> <dd pn="section-4.2.1-7.4">This field isnowdefined to carry the LAG member link identifier of the Reflector side. In the future, it may be used generically to coveruse-casesuse cases beyondLAG.LAGs. The value of this fieldMUST<bcp14>MUST</bcp14> be unique within a TWAMP session at theSession-Reflector.</t> </list> </t> <t/>Session-Reflector.</dd> </dl> </section> <sectiontitle="Sender Behavior"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-4.2.2"> <name slugifiedName="name-sender-behavior">Sender Behavior</name> <t indent="0" pn="section-4.2.2-1">The micro TWAMP Session-Sender inherits the behaviors of the TWAMP Session-Sender as defined inSection 4.1 of<xreftarget="RFC5357"/>.target="RFC5357" sectionFormat="of" section="4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5357#section-4.1" derivedContent="RFC5357"/>. In addition, the micro TWAMP Session-SenderMUST<bcp14>MUST</bcp14> send the micro Session-Sender test packets over the member link with which the session is associated.</t><t>When<t indent="0" pn="section-4.2.2-2">When sending the test packet, the micro TWAMP Session-SenderMUST<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 <xreftarget="TWAMPSender"/>target="TWAMPSender" format="counter" sectionFormat="of" derivedContent="2"/> and <xreftarget="TWAMPSenderA"/>) MUSTtarget="TWAMPSenderA" format="counter" sectionFormat="of" derivedContent="3"/>) <bcp14>MUST</bcp14> be set. Otherwise, the Reflector Micro-session ID fieldMUST<bcp14>MUST</bcp14> be zero.</t><t>A<t indent="0" pn="section-4.2.2-3">A test packet with a Sender member link identifier is sent to theSession-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<t indent="0" pn="section-4.2.2-4">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, itMUST<bcp14>MUST</bcp14> put the identifier in the Reflector Micro-session ID field (see Figures <xreftarget="TWAMPSender"/>target="TWAMPSender" format="counter" sectionFormat="of" derivedContent="2"/> or <xreftarget="TWAMPSenderA"/>)target="TWAMPSenderA" format="counter" sectionFormat="of" derivedContent="3"/>) of the test packets that will be sent to the Session-Reflector. The Reflector member link identifier can be obtained frompre-configurationpreconfiguration 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<t indent="0" pn="section-4.2.2-5">When receiving a reflected test packet, the micro TWAMP Session-SenderMUST<bcp14>MUST</bcp14> use the receiving member link to correlate the reflected test packet to a micro TWAMP session. If there is no suchasession, the reflected test packetMUST<bcp14>MUST</bcp14> be discarded. If a matched session exists, the micro Session-SenderMUST<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 packetMUST<bcp14>MUST</bcp14> be discarded. The micro Session-SenderMUST<bcp14>MUST</bcp14> use the Reflector Micro-session ID to validate the Reflector's behavior. If the validation fails, the test packetMUST<bcp14>MUST</bcp14> be discarded.</t> </section> <sectiontitle="Reflectornumbered="true" toc="include" removeInRFC="false" pn="section-4.2.3"> <name slugifiedName="name-reflector-packet-format-and">Reflector Packet Format andContent"> <t>TheContent</name> <t indent="0" pn="section-4.2.3-1">The micro TWAMP Session-Reflector packet format is based on the TWAMP Session-Reflector packet format as defined inSection 4.2.1 of<xreftarget="RFC5357"/>.target="RFC5357" sectionFormat="of" section="4.2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5357#section-4.2.1" derivedContent="RFC5357"/>. Two new fields (Sender and Reflector Micro-session ID) are added to carry the LAG member link identifiers.</t><t>For<t indent="0" pn="section-4.2.3-2">For unauthenticated mode, the format is as below:</t><t><figurealign="center"anchor="TWAMPReflector"title="Microalign="left" suppress-title="false" pn="figure-4"> <name slugifiedName="name-micro-session-reflector-pac">Micro Session-Reflector Packet Format in UnauthenticatedMode"> <artwork><![CDATA[Mode</name> <artwork name="" type="" align="left" alt="" pn="section-4.2.3-3.1"> 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></artwork> </figure></t> <t>For<t indent="0" pn="section-4.2.3-4">For authenticated and encrypted mode, the format is as below:</t><t><figurealign="center"anchor="TWAMPReflectorA"title="Microalign="left" suppress-title="false" pn="figure-5"> <name slugifiedName="name-micro-session-reflector-pack">Micro Session-Reflector Packet Format in AuthenticatedMode"> <artwork><![CDATA[Mode</name> <artwork name="" type="" align="left" alt="" pn="section-4.2.3-5.1"> 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></artwork> </figure></t> <t>Except<t indent="0" pn="section-4.2.3-6">Except for theSender/ReflectorSender Micro-session ID field and the Reflector Micro-session ID field, all the other fields are the same as defined inSection 4.2.1 of TWAMP<xreftarget="RFC5357"/>. Therefore, it followstarget="RFC5357" sectionFormat="of" section="4.2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5357#section-4.2.1" derivedContent="RFC5357"/> and follow the same procedure and guidelinesasdefinedin Section 4.2.1 of TWAMP <xref target="RFC5357"/>.</t> <t> <list style="symbols"> <t>Sendertherein.</t> <dl spacing="normal" indent="3" newline="false" pn="section-4.2.3-7"> <dt pn="section-4.2.3-7.1">Sender Micro-session ID(2-octets(2 octets inlength): Itlength):</dt> <dd pn="section-4.2.3-7.2">This field isnowdefined to carry the LAG member link identifier of the Sender side. In the future, it may be used generically to coveruse-casesuse cases beyondLAG.LAGs. The value of this fieldMUST<bcp14>MUST</bcp14> be unique within a TWAMP session at theSession-Sender.</t> <t>ReflectorSession-Sender.</dd> <dt pn="section-4.2.3-7.3">Reflector Micro-session ID(2-octets(2 octets inlength): Itlength):</dt> <dd pn="section-4.2.3-7.4">This field isnowdefined to carry the LAG member link identifier of the Reflector side. In the future, it may be used generically to coveruse-casesuse cases beyondLAG.LAGs. The value of this fieldMUST<bcp14>MUST</bcp14> be unique within a TWAMP session at theSession-Reflector.</t> </list> </t>Session-Reflector.</dd> </dl> </section> <sectiontitle="Reflector Behavior"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-4.2.4"> <name slugifiedName="name-reflector-behavior">Reflector Behavior</name> <t indent="0" pn="section-4.2.4-1">The micro TWAMP Session-Reflector inherits the behaviors of a TWAMP Session-Reflector as defined inSection 4.2 of<xreftarget="RFC5357"/>.</t> <t>Intarget="RFC5357" sectionFormat="of" section="4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5357#section-4.2" derivedContent="RFC5357"/>.</t> <t indent="0" pn="section-4.2.4-2">In addition, when receiving a test packet, the micro TWAMP Session-ReflectorMUST<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 packetMUST<bcp14>MUST</bcp14> be discarded. If the Reflector Micro-session ID is not zero, the ReflectorMUST<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 packetMUST<bcp14>MUST</bcp14> be discarded.</t><t>When<t indent="0" pn="section-4.2.4-3">When sending a response to the received test packet, the micro TWAMP Session-ReflectorMUST<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 <xreftarget="TWAMPReflector"/>target="TWAMPReflector" format="counter" sectionFormat="of" derivedContent="4"/> and <xreftarget="TWAMPReflectorA"/>).target="TWAMPReflectorA" format="counter" sectionFormat="of" derivedContent="5"/>). In addition, the micro TWAMP Session-ReflectorMUST<bcp14>MUST</bcp14> fill the Reflector Micro-session ID field (see Figures <xreftarget="TWAMPReflector"/>target="TWAMPReflector" format="counter" sectionFormat="of" derivedContent="4"/> and <xreftarget="TWAMPReflectorA"/>)target="TWAMPReflectorA" format="counter" sectionFormat="of" derivedContent="5"/>) of the reflected test packet with the member link identifier that is associated with the micro TWAMP session.</t> </section> </section> </section> <sectiontitle="Applicability"> <t>Tonumbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-applicability">Applicability</name> <t indent="0" pn="section-5-1">To set up the micro OWAMP sessions, the Control-Clientfirstlysends the Request-OW-Micro-Sessions command to the OWAMP Server. The OWAMP Server accepts therequest,request and builds a set of micro sessions for all the member links of the LAG.</t><t>For<t indent="0" pn="section-5-2">For micro TWAMP sessions,thea similar set up procedureas micro OWAMP sessionsis used.ThenThen, the micro TWAMP Session-Sender sends micro Session-Sender packets with the Sender Micro-session ID and the Reflector Micro-session ID.TheIf 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 TWAMPsession, 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-Reflectorpacket, andpacket; 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="include" removeInRFC="false" pn="section-6"> <name slugifiedName="name-iana-considerations">IANA Considerations</name> <sectiontitle="Micronumbered="true" toc="include" removeInRFC="false" pn="section-6.1"> <name slugifiedName="name-micro-owamp-control-command">Micro OWAMP-ControlCommand"> <t>This document requires the IANA to allocateCommand</name> <t indent="0" pn="section-6.1-1">IANA has allocated the following command type fromOWAMP-Controlthe "OWAMP-Control CommandNumber 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" pn="table-1"> <name slugifiedName="name-request-ow-micro-sessions-c">Request-OW-Micro-Sessions Command Number</name> <thead> <tr> <th align="left" colspan="1" rowspan="1">Value</th> <th align="left" colspan="1" rowspan="1">Description</th> <th align="left" colspan="1" rowspan="1">Reference</th> </tr> </thead> <tbody> <tr> <td align="left" colspan="1" rowspan="1">5</td> <td align="left" colspan="1" rowspan="1">Request-OW-Micro-Sessions</td> <td align="left" colspan="1" rowspan="1">This document</td> </tr> </tbody> </table> </section> <sectiontitle="Micronumbered="true" toc="include" removeInRFC="false" pn="section-6.2"> <name slugifiedName="name-micro-twamp-control-command">Micro TWAMP-ControlCommand"> <t>This document requires the IANA to allocateCommand</name> <t indent="0" pn="section-6.2-1">IANA has allocated the following command type fromTWAMP-Controlthe "TWAMP-Control CommandNumber 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" pn="table-2"> <name slugifiedName="name-request-tw-micro-sessions-c">Request-TW-Micro-Sessions Command Number</name> <thead> <tr> <th align="left" colspan="1" rowspan="1">Value</th> <th align="left" colspan="1" rowspan="1">Description</th> <th align="left" colspan="1" rowspan="1">Reference</th> </tr> </thead> <tbody> <tr> <td align="left" colspan="1" rowspan="1">11</td> <td align="left" colspan="1" rowspan="1">Request-TW-Micro-Sessions</td> <td align="left" colspan="1" rowspan="1">This document</td> </tr> </tbody> </table> </section> </section> <section anchor="Security"title="Security Considerations"> <t>Thisnumbered="true" toc="include" removeInRFC="false" pn="section-7"> <name slugifiedName="name-security-considerations">Security Considerations</name> <t indent="0" pn="section-7-1">This document does not introduce additional security requirements and mechanisms other than those described in <xreftarget="RFC4656"/>,target="RFC4656" format="default" sectionFormat="of" derivedContent="RFC4656"/> and <xreftarget="RFC5357"/>.</t>target="RFC5357" format="default" sectionFormat="of" derivedContent="RFC5357"/>.</t> </section><section anchor="Acknowledgements" title="Acknowledgements"> <t>The authors would like</middle> <back> <references pn="section-8"> <name slugifiedName="name-references">References</name> <references pn="section-8.1"> <name slugifiedName="name-normative-references">Normative References</name> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119"> <front> <title>Key words for use in RFCs tothank Fang Xin, Henrik Nydell, Mach Chen, Min Xiao, Jeff Tantsura, Marcus Ihlar, Richard FooteIndicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for thevaluable commentsInternet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC4656" target="https://www.rfc-editor.org/info/rfc4656" quoteTitle="true" derivedAnchor="RFC4656"> <front> <title>A One-way Active Measurement Protocol (OWAMP)</title> <author fullname="S. Shalunov" initials="S." surname="Shalunov"/> <author fullname="B. Teitelbaum" initials="B." surname="Teitelbaum"/> <author fullname="A. Karp" initials="A." surname="Karp"/> <author fullname="J. Boote" initials="J." surname="Boote"/> <author fullname="M. Zekauskas" initials="M." surname="Zekauskas"/> <date month="September" year="2006"/> <abstract> <t indent="0">The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources (such as GPS and CDMA). OWAMP enables the interoperability of these measurements. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4656"/> <seriesInfo name="DOI" value="10.17487/RFC4656"/> </reference> <reference anchor="RFC5357" target="https://www.rfc-editor.org/info/rfc5357" quoteTitle="true" derivedAnchor="RFC5357"> <front> <title>A Two-Way Active Measurement Protocol (TWAMP)</title> <author fullname="K. Hedayat" initials="K." surname="Hedayat"/> <author fullname="R. Krzanowski" initials="R." surname="Krzanowski"/> <author fullname="A. Morton" initials="A." surname="Morton"/> <author fullname="K. Yum" initials="K." surname="Yum"/> <author fullname="J. Babiarz" initials="J." surname="Babiarz"/> <date month="October" year="2008"/> <abstract> <t indent="0">The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and thiswork.</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'?>allows for some protocol simplifications, making it an attractive alternative in some circumstances. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5357"/> <seriesInfo name="DOI" value="10.17487/RFC5357"/> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC8668" target="https://www.rfc-editor.org/info/rfc8668" quoteTitle="true" derivedAnchor="RFC8668"> <front> <title>Advertising Layer 2 Bundle Member Link Attributes in IS-IS</title> <author fullname="L. Ginsberg" initials="L." role="editor" surname="Ginsberg"/> <author fullname="A. Bashandy" initials="A." surname="Bashandy"/> <author fullname="C. Filsfils" initials="C." surname="Filsfils"/> <author fullname="M. Nanduri" initials="M." surname="Nanduri"/> <author fullname="E. Aries" initials="E." surname="Aries"/> <date month="December" year="2019"/> <abstract> <t indent="0">There are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer 3 interface. If entities external to IS-IS wish to control traffic flows on the individual physical links that comprise the Layer 2 interface bundle, link attribute information about the bundle members is required.</t> <t indent="0">This document introduces the ability for IS-IS to advertise the link attributes of Layer 2 (L2) Bundle Members.</t> </abstract> </front> <seriesInfo name="RFC" value="8668"/> <seriesInfo name="DOI" value="10.17487/RFC8668"/> </reference> </references> <referencestitle="Informative References">pn="section-8.2"> <name slugifiedName="name-informative-references">Informative References</name> <referenceanchor="IEEE802.1AX">anchor="IEEE802.1AX" target="https://ieeexplore.ieee.org/document/9105034" quoteTitle="true" derivedAnchor="IEEE802.1AX"> <front> <title>IEEE Standard for Local andmetropolitan area networks -Metropolitan Area Networks -- Link Aggregation</title> <author><organization>IEEE Std. 802.1AX</organization><organization showOnFrontPage="true">IEEE</organization> </author> <datemonth="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> <reference anchor="RFC7799" target="https://www.rfc-editor.org/info/rfc7799" quoteTitle="true" derivedAnchor="RFC7799"> <front> <title>Active and Passive Metrics and Methods (with Hybrid Types In-Between)</title> <author fullname="A. Morton" initials="A." surname="Morton"/> <date month="May" year="2016"/> <abstract> <t indent="0">This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge.</t> </abstract> </front> <seriesInfo name="RFC" value="7799"/> <seriesInfo name="DOI" value="10.17487/RFC7799"/> </reference><?rfc include='reference.RFC.7799'?> <?rfc include='reference.RFC.9256'?></references> </references> <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a"> <name slugifiedName="name-acknowledgements">Acknowledgements</name> <t indent="0" pn="section-appendix.a-1">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> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b"> <name slugifiedName="name-authors-addresses">Authors' Addresses</name> <author fullname="Zhenqiang Li" initials="Z." surname="Li"> <organization showOnFrontPage="true">China Mobile</organization> <address> <postal> <street>No. 29 Finance 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 showOnFrontPage="true">Huawei</organization> <address> <postal> <country>China</country> </postal> <email>zhoutianran@huawei.com</email> </address> </author> <author fullname="Jun Guo" initials="J." surname="Guo"> <organization showOnFrontPage="true">ZTE Corp.</organization> <address> <postal> <country>China</country> </postal> <phone/> <email>guo.jun2@zte.com.cn</email> <uri/> </address> </author> <author fullname="Greg Mirsky" initials="G." surname="Mirsky"> <organization showOnFrontPage="true">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 showOnFrontPage="true">Cisco Systems, Inc.</organization> <address> <postal> <country>Canada</country> </postal> <phone/> <email>rgandhi@cisco.com</email> <uri/> </address> </author> </section> </back> </rfc>