rfc9534xml2.original.xml   rfc9534.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="3"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
<?rfc compact="yes"?> category="std"
<?rfc subcompact="no"?> consensus="true"
<rfc category="std" consensus="true" docName="draft-ietf-ippm-stamp-on-lag-06" number="9534"
ipr="trust200902" sortRefs="true" submissionType="IETF" tocInclude="true"> docName="draft-ietf-ippm-stamp-on-lag-06"
ipr="trust200902"
sortRefs="true"
submissionType="IETF"
tocInclude="true"
obsoletes=""
updates=""
xml:lang="en"
tocDepth="3"
symRefs="true"
version="3">
<front> <front>
<title abbrev="STAMP PM on LAG">Simple Two-Way Active Measurement Protocol <title abbrev="STAMP PM on LAG">Simple Two-Way Active Measurement Protocol
Extensions for Performance Measurement on LAG</title> Extensions for Performance Measurement on a Link Aggregation Group</title>
<seriesInfo name="RFC" value="9534"/>
<author fullname="Zhenqiang Li" initials="Z." surname="Li"> <author fullname="Zhenqiang Li" initials="Z." surname="Li">
<organization>China Mobile</organization> <organization>China Mobile</organization>
<address> <address>
<postal> <postal>
<street>No. 29 Finance Avenue, Xicheng District</street> <street>No. 29 Finance Avenue</street>
<cityarea>Xicheng District</cityarea>
<city>Beijing</city> <city>Beijing</city>
<code/> <code/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>li_zhenqiang@hotmail.com</email> <email>li_zhenqiang@hotmail.com</email>
</address> </address>
</author> </author>
<author fullname="Tianran Zhou" initials="T." surname="Zhou"> <author fullname="Tianran Zhou" initials="T." surname="Zhou">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<street/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>zhoutianran@huawei.com</email> <email>zhoutianran@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Jun Guo" initials="J." surname="Guo"> <author fullname="Jun Guo" initials="J." surname="Guo">
<organization>ZTE Corp.</organization> <organization>ZTE Corp.</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<region/>
<code/>
<country>China</country> <country>China</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>guo.jun2@zte.com.cn</email> <email>guo.jun2@zte.com.cn</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<author fullname="Greg Mirsky" initials="G." surname="Mirsky"> <author fullname="Greg Mirsky" initials="G." surname="Mirsky">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street/>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>gregimirsky@gmail.com</email> <email>gregimirsky@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Rakesh Gandhi" initials="R." surname="Gandhi"> <author fullname="Rakesh Gandhi" initials="R." surname="Gandhi">
<organization>Cisco</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<region/>
<code/>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>rgandhi@cisco.com</email> <email>rgandhi@cisco.com</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<date day="11" month="December" year="2023"/> <date month="January" year="2024"/>
<area>Operation and Management Area</area>
<area>Transport Area</area>
<workgroup>IPPM</workgroup> <workgroup>IPPM</workgroup>
<keyword>STAMP</keyword>
<keyword>Performance Measurement</keyword>
<keyword>LAG</keyword>
<keyword>Micro Session</keyword>
<abstract> <abstract>
<t>This document extends Simple Two-Way Active Measurement Protocol <t>This document extends Simple Two-way Active Measurement Protocol
(STAMP) to implement performance measurement on every member link of a (STAMP) to implement performance measurement on every member link of a
Link Aggregation Group (LAG). Knowing the measured metrics of each Link Aggregation Group (LAG). Knowing the measured metrics of each
member link of a LAG enables operators to enforce a performance based member link of a LAG enables operators to enforce a performance-based
traffic steering policy across the member links.</t> traffic steering policy across the member links.</t>
</abstract> </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> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>Link Aggregation Group (LAG), as defined in <xref <name>Introduction</name>
target="IEEE802.1AX"/>, provides mechanisms to combine multiple physical <t>A Link Aggregation Group (LAG), as defined in <xref target="IEEE802.1AX
" format="default"/>, provides mechanisms to combine multiple physical
links into a single logical link. This logical link offers higher links into a single logical link. This logical link offers higher
bandwidth and better resiliency, because if one of the physical member bandwidth and better resiliency because, if one of the physical member
links fails, the aggregate logical link can continue to forward traffic links fails, the aggregate logical link can continue to forward traffic
over the remaining operational physical member links.</t> over the remaining operational physical member links.</t>
<t>Usually, when forwarding traffic over a LAG, a hash-based mechanism is
<t>Usually, when forwarding traffic over LAG, a hash-based mechanism is
used to load balance the traffic across the LAG member links. The link used to load balance the traffic across the LAG member links. The link
delay might vary between member links because of different transport delay might vary between member links because of different transport
paths, especially when LAG is used in wide area network. To provide low paths, especially when a LAG is used in a wide area network. To provide
latency service for time sensitive traffic, we need to explicitly steer low-latency service for time-sensitive traffic, we need to explicitly stee
the traffic across the LAG member links based on the link delay, loss r
the traffic across the LAG member links based on the link delay, loss,
and so on. That requires a solution to measure the performance metrics and so on. That requires a solution to measure the performance metrics
of each member link of a LAG. Hence, the measured performance metrics of each member link of a LAG. Hence, the measured performance metrics
can work together with <xref target="RFC8668">layer 2 bundle member link can work together with <xref target="RFC8668" format="default">Layer 2 bun dle member link
attributes advertisement</xref> for traffic steering.</t> attributes advertisement</xref> for traffic steering.</t>
<t>According to the classifications in <xref target="RFC7799" format="defa
<t>According to the classifications in <xref target="RFC7799"/>, <xref ult"/>, <xref target="RFC8762" format="default">Simple Two-way Active Measuremen
target="RFC8762">Simple Two-Way Active Measurement Protocol t Protocol
(STAMP)</xref> is an active measurement method, and it can complement (STAMP)</xref> is an active measurement method, and it can complement
passive and hybrid methods. It provides a mechanism to measure both passive and hybrid methods. It provides a mechanism to measure both
one-way and round-trip performance metrics, like delay, delay variation, one-way and round-trip performance metrics, like delay, delay variation,
and packet loss. One STAMP test session over the LAG can measure the and packet loss. A STAMP test session over the LAG can be used to measure
performance of a member link with fixed five tuples. Or it can measure the
an average of some/all member links of the LAG by varying the five performance of a member link using a specially constructed 5-tuple. The se
tuples. However, without the knowledge of each member link, a STAMP test ssion can be used to measure
an average of some or all member links of the LAG by varying one or more e
lements of that
5-tuple. However, without the knowledge of each member link, a STAMP test
session cannot measure the performance of every physical member session cannot measure the performance of every physical member
link.</t> link.</t>
<t>This document extends STAMP to implement performance measurement on <t>This document extends STAMP to implement performance measurement on
every member link of a LAG. It can provide the same metrics as <xref every member link of a LAG. It can provide the same metrics as <xref targe
target="RFC4656">OWAMP</xref> and <xref target="RFC5357">TWAMP</xref> t="RFC4656" format="default">One-Way Active Measurement Protocol (OWAMP)</xref>
and <xref target="RFC5357" format="default">Two-Way Active Measurement Protocol
(TWAMP)</xref>
can measure, such as delay, jitter, and packet loss.</t> can measure, such as delay, jitter, and packet loss.</t>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.</t>
</section> </section>
</section>
<section title="Micro Session on LAG"> <section numbered="true" toc="default">
<name>Micro Sessions on a LAG</name>
<t>This document addresses the scenario where a LAG directly connects <t>This document addresses the scenario where a LAG directly connects
two nodes. An example of this is in Figure 1, where the LAG consisting two nodes. An example of this is in <xref target="PMonLAG"/>, where the LA G consisting
of four links connects nodes A and B. The goal is to measure the of four links connects nodes A and B. The goal is to measure the
performance of each link of the LAG.</t> performance of each link of the LAG.</t>
<figure anchor="PMonLAG">
<figure align="center" anchor="PMonLAG" <name>Performance Measurement on a LAG</name>
title="Performance Measurement on LAG"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[+---+ +---+ +---+ +---+
| |-----------------------| | | |-----------------------| |
| A |-----------------------| B | | A |-----------------------| B |
| |-----------------------| | | |-----------------------| |
| |-----------------------| | | |-----------------------| |
+---+ +---+ +---+ +---+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>To measure the performance metrics of every member link of a LAG, <t>To measure the performance metrics of every member link of a LAG,
multiple sessions (one session for each member link) need to be multiple sessions (one session for each member link) need to be
established between the two end points that are connected by the LAG. established between the two endpoints that are connected by the LAG.
These sessions are called micro sessions in the remainder of this These sessions are called "micro sessions" in the remainder of this
document. Although micro sessions are in fact STAMP sessions established document. Although micro sessions are in fact STAMP sessions established
on member links of a LAG, test packets of micro sessions MUST carry on member links of a LAG, test packets of micro sessions <bcp14>MUST</bcp1 4> carry
member link information for validation.</t> member link information for validation.</t>
<t>All micro sessions of a LAG share the same Sender IP Address and <t>All micro sessions of a LAG share the same Sender IP Address and
Receiver IP Address of the LAG. As for the UDP Port, the micro sessions Receiver IP Address. As for the UDP port, the micro sessions
may share the same Sender Port and Receiver Port pair, or each micro may share the same Sender Port and Receiver Port pair or each micro
session is configured with a different Sender Port and Receiver Port session may be configured with a different Sender Port and Receiver Port
pair. But from the operational point of view, the former is simpler and pair. From the operational point of view, the former is simpler and
is RECOMMENDED.</t> is <bcp14>RECOMMENDED</bcp14>.</t>
<t>Test packets of a micro session <bcp14>MUST</bcp14> carry the member li
<t>Test packets of a micro session MUST carry the member link nk
information for validation check. For example, when a micro STAMP information for validation checks. For example, when a micro STAMP
Session-Sender receives a reflected test packet, it checks whether the Session-Sender receives a reflected test packet, it checks whether the
test packet is from the expected member link. The member link test packet is from the expected member link. The member link
information is encoded in the Micro-session ID TLV introduced in Section information is encoded in the Micro-session ID TLV introduced in <xref tar
3 of this document, and the detailed description about the member link get="validation"/>,
validation is also in this section.</t> which also provides a detailed description about member link
validation.</t>
<t>A micro STAMP Session-Sender MAY include the <xref <t>A micro STAMP Session-Sender <bcp14>MAY</bcp14> include the <xref targe
target="RFC8972">Follow-Up Telemetry TLV</xref> to request information t="RFC8972" format="default">Follow-Up Telemetry TLV</xref> to request informati
on
from the micro Session-Reflector. This timestamp might be important for from the micro Session-Reflector. This timestamp might be important for
the micro Session-Sender, as it improves the accuracy of network delay the micro Session-Sender, as it improves the accuracy of network delay
measurement by minimizing the impact of egress queuing delays on the measurement by minimizing the impact of egress queuing delays on the
measurement.</t> measurement.</t>
</section> </section>
<section numbered="true" toc="default" anchor="validation">
<section title="Member Link Validation"> <name>Member Link Validation</name>
<t>Test packets MUST carry member link information in Micro-session ID <t>Test packets <bcp14>MUST</bcp14> carry member link information in the M
TLV introduced in this section for validation check. The micro icro-session ID
TLV introduced in this section for validation checks. The micro
Session-Sender verifies whether the test packet is received from the Session-Sender verifies whether the test packet is received from the
expected member link. It also verifies whether the packet is sent from expected member link. It also verifies whether the packet is sent from
the expected member link at the Reflector side. The micro the expected member link at the Reflector side. The micro
Session-Reflector verifies whether the test packet is received from the Session-Reflector verifies whether the test packet is received from the
expected member link.</t> expected member link.</t>
<section numbered="true" toc="default">
<section title="Micro-session ID TLV"> <name>Micro-session ID TLV</name>
<t><xref target="RFC8972">STAMP TLV</xref> mechanism extends STAMP <t>The <xref target="RFC8972" format="default">STAMP TLV mechanism</xref
> extends STAMP
test packets with one or more optional TLVs. This document defines the test packets with one or more optional TLVs. This document defines the
TLV Type (value TBA1) for the Micro-session ID TLV that carries the TLV Type (value 11) for the Micro-session ID TLV that carries the
micro STAMP Session-Sender member link identifier and micro STAMP Session-Sender member link identifier and
Session-Reflector member link identifier in Sender Micro-session ID Session-Reflector member link identifier in the Sender Micro-session ID
field and Reflector Micro-session ID field respectively. The format of field and the Reflector Micro-session ID field, respectively. The format
of
the Micro-session ID TLV is shown as follows:</t> the Micro-session ID TLV is shown as follows:</t>
<figure anchor="STAMPSender">
<t> <name>Micro-session ID TLV</name>
<figure align="center" anchor="STAMPSender" <artwork name="" type="" align="left" alt=""><![CDATA[ 0
title="Micro-session ID TLV"> 1 2 3
<artwork><![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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type = TBA1 | Length | |STAMP TLV Flags| Type = 11 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Micro-session ID | Reflector Micro-session ID | | Sender Micro-session ID | Reflector Micro-session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl spacing="normal">
<list style="symbols"> <dt>Type (1 octet in length):</dt>
<t>Type (one-octet in length): It is defined to indicate this TLV <dd>This field is defined to indicate this TLV
is a Micro-session ID TLV. Value TBA1 is allocated by IANA is a Micro-session ID TLV. Value 11 has been allocated by IANA
(Section 5).</t> (<xref target="IANA"/>).</dd>
<dt>Length (2 octets in length):</dt>
<t>Length (2-octets in length): It is defined to carry the length <dd>This field is defined to carry the length
of the Value field in octets. The Length field value MUST be of the Value field in octets. The Length field value <bcp14>MUST</bc
4.</t> p14> be
4.</dd>
<t>Sender Micro-session ID (2-octets in length): It is now defined <dt>Sender Micro-session ID (2 octets in length):</dt>
<dd>This field is defined
to carry the LAG member link identifier of the Sender side. In the to carry the LAG member link identifier of the Sender side. In the
future, it may be used generically to cover use-cases beyond LAG. future, it may be used generically to cover use cases beyond LAGs.
The value of this field MUST be unique within a STAMP session at The value of this field <bcp14>MUST</bcp14> be unique within a STAMP
the Session-Sender.</t> session at
the Session-Sender.</dd>
<t>Reflector Micro-session ID (2-octets in length): It is now <dt>Reflector Micro-session ID (2 octets in length):</dt>
<dd>This field is
defined to carry the LAG member link identifier of the Reflector defined to carry the LAG member link identifier of the Reflector
side. In the future, it may be used generically to cover use-cases side. In the future, it may be used generically to cover use cases
beyond LAG. The value of this field MUST be unique within a STAMP beyond LAGs. The value of this field <bcp14>MUST</bcp14> be unique w
session at the Session-Reflector.</t> ithin a STAMP
</list> session at the Session-Reflector.</dd>
</t> </dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Micro STAMP-Test Procedures"> <name>Micro STAMP-Test Procedures</name>
<t>The micro STAMP-Test reuses the procedures as defined in Section 4 <t>The micro STAMP-Test reuses the procedures as defined in Section
of <xref target="RFC8762">STAMP</xref> with the following <xref target="RFC8762" sectionFormat="bare" section="4" format="default"
/> of
<xref target="RFC8762" format="default">STAMP</xref> with the following
additions.</t> additions.</t>
<t>The micro STAMP Session-Sender <bcp14>MUST</bcp14> send the micro STA
<t>The micro STAMP Session-Sender MUST send the micro STAMP-Test MP-Test
packets over the member link with which the session is associated. The packets over the member link with which the session is associated. The
mapping between a micro STAMP session and the Sender/Reflector member mapping between a micro STAMP session and the Sender/Reflector member
link identifiers can be configured by augmenting the <xref link identifiers can be configured by augmenting the <xref
target="I-D.ietf-ippm-stamp-yang">STAMP YANG</xref>. The detailed target="I-D.ietf-ippm-stamp-yang" format="default">STAMP
augmentation is not in the scope of this document.</t> YANG</xref>. The detailed augmentation is not in the scope of this
document.</t>
<t>When sending a test packet, the micro STAMP Session-Sender MUST set <t>When sending a test packet, the micro STAMP Session-Sender <bcp14>MUS
T</bcp14> set
the Sender Micro-session ID field with the member link identifier the Sender Micro-session ID field with the member link identifier
associated with the micro STAMP session. If the Session-Sender knows associated with the micro STAMP session. If the Session-Sender knows
the Reflector member link identifier, the Reflector Micro-session ID the Reflector member link identifier, the Reflector Micro-session ID
field MUST be set. Otherwise, the Reflector Micro-session ID field field <bcp14>MUST</bcp14> be set. Otherwise, the Reflector Micro-session
MUST be zero. The Reflector member link identifier can be obtained ID field
from pre-configuration or learned from data plane (e.g., the reflected <bcp14>MUST</bcp14> be zero. The Reflector member link identifier can be
obtained
from preconfiguration or learned from data plane (e.g., the reflected
test packet). This document does not specify the way to obtain the test packet). This document does not specify the way to obtain the
Reflector member link identifier.</t> Reflector member link identifier.</t>
<t>When the micro STAMP Session-Reflector receives a test packet, if <t>When the micro STAMP Session-Reflector receives a test packet, if
the Reflector Micro-session ID is not zero, the micro STAMP the Reflector Micro-session ID is not zero, the micro STAMP
Session-Reflector MUST use the Reflector member link identifier to Session-Reflector <bcp14>MUST</bcp14> use the Reflector member link iden tifier to
check whether it is associated with the micro STAMP session. If the check whether it is associated with the micro STAMP session. If the
validation fails, the test packet MUST be discarded. If the Reflector validation fails, the test packet <bcp14>MUST</bcp14> be discarded. If t he Reflector
Micro-session ID is zero, it will not be verified. If all validations Micro-session ID is zero, it will not be verified. If all validations
passed, the Session-Reflector sends a reflected test packet to the passed, the Session-Reflector sends a reflected test packet to the
Session-Sender. The micro STAMP Session-Reflector MUST put the Sender Session-Sender. The micro STAMP Session-Reflector <bcp14>MUST</bcp14> pu t the Sender
and Reflector member link identifiers that are associated with the and Reflector member link identifiers that are associated with the
micro STAMP session in the Sender Micro-session ID and Reflector micro STAMP session in the Sender Micro-session ID and Reflector
Micro-session ID fields respectively. The Sender member link Micro-session ID fields, respectively. The Sender member link
identifier is copied from the received test packet.</t> identifier is copied from the received test packet.</t>
<t>When receiving a reflected test packet, the micro Session-Sender <t>When receiving a reflected test packet, the micro Session-Sender
MUST use the Sender Micro-session ID to validate whether the reflected <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 test packet is correctly received from the expected member link. If
the validation fails, the test packet MUST be discarded. The micro the validation fails, the test packet <bcp14>MUST</bcp14> be discarded.
Session-Sender MUST use the Reflector Micro-session ID to validate the The micro
Reflector's behavior. If the validation fails, the test packet MUST be Session-Sender <bcp14>MUST</bcp14> use the Reflector Micro-session ID to
validate the
Reflector's behavior. If the validation fails, the test packet <bcp14>MU
ST</bcp14> be
discarded.</t> discarded.</t>
<t>Two modes of the STAMP Session-Reflector, stateless and stateful, <t>Two modes of the STAMP Session-Reflector, stateless and stateful,
characterize the expected behavior, as described in Section 4 of <xref characterize the expected behavior as described in Section <xref target=
target="RFC8762">STAMP</xref>. The micro STAMP-Test also supports both "RFC8762" sectionFormat="bare" section="4" format="default"/> of <xref target="R
FC8762" format="default">STAMP</xref>. The micro STAMP-Test also supports both
stateless and stateful modes. However, the micro STAMP-Test does not stateless and stateful modes. However, the micro STAMP-Test does not
introduce any additional state to STAMP, i.e, any procedure with introduce any additional state to STAMP, i.e., any procedure with
regard to the Micro-session ID is stateless.</t> regard to the Micro-session ID is stateless.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Applicability"> <name>Applicability</name>
<t>The micro STAMP Session-Sender sends micro Session-Sender packets <t>The micro STAMP Session-Sender sends micro Session-Sender packets
with the Micro-session ID TLV. The micro Session-Reflector checks with the Micro-session ID TLV. The micro Session-Reflector checks
whether a test packet is received from the member link associated with whether a test packet is received from the member link associated with
the correct micro STAMP session, if the Reflector Micro-session ID field the correct micro STAMP session if the Reflector Micro-session ID field
is set. When reflecting, the micro STAMP Session-Reflector copies the is set. When reflecting, the micro STAMP Session-Reflector copies the
Sender Micro-session ID from the received micro Session-Sender packet to Sender Micro-session ID from the received micro Session-Sender packet to
the micro Session-Reflector packet, and sets the Reflector Micro-session the micro Session-Reflector packet and sets the Reflector Micro-session
ID field with the member link identifier that is associated with the ID field with the member link identifier that is associated with the
micro STAMP session. When receiving the micro Session-Reflector packet, micro STAMP session. When receiving the micro Session-Reflector packet,
the micro Session-Sender uses the Sender Micro-session ID to check the micro Session-Sender uses the Sender Micro-session ID to check
whether the packet is received from the member link associated with the whether the packet is received from the member link associated with the
correct micro STAMP session. The micro Session-Sender also use the correct micro STAMP session. The micro Session-Sender also use the
Reflector Micro-session ID to validate the Reflector's behavior.</t> Reflector Micro-session ID to validate the Reflector's behavior.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>In the "STAMP TLV Types" registry created for [RFC8972], a new STAMP <t>IANA has allocated the following STAMP
TLV Type for Micro-session ID TLV is requested from IANA as TLV Type for the Micro-session ID TLV in the "STAMP TLV Types" registry <x
follows:<figure align="center" title="New STAMP TLV Type"> ref target="RFC8972" format="default"/>:</t>
<artwork><![CDATA[+----------------+-------------------+-------------- <table anchor="reg_table">
---+------------+ <name>New STAMP TLV Type</name>
| STAMP TLV Type | Description | Semantics | Reference | <thead>
| Value | | Definition | | <tr>
+----------------+-------------------+-----------------+------------+ <th>Value</th>
| TBA1 | Micro-session | Section 3 | This | <th>Description</th>
| | ID TLV | | Document | <th>Reference</th>
+----------------+-------------------+-----------------+------------+]]></artwor </tr>
k> </thead>
</figure></t> <tbody>
<tr>
<td>11</td>
<td>Micro-session ID</td>
<td>This Document</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>The STAMP extension defined in this document is intended for <t>The STAMP extension defined in this document is intended for
deployment in LAG scenario where Session-Sender and Session-Reflector deployment in the LAG scenario where Session-Sender and Session-Reflector
are directly connected. As such, it's assumed that a node involved in are directly connected. As such, it's assumed that a node involved in
STAMP protocol operation has previously verified the integrity of the a STAMP operation has previously verified the integrity of the
LAG connection and the identity of its one-hop-away peer node.</t> LAG connection and the identity of its one-hop-away peer node.</t>
<t>This document does not introduce any additional security issues, and
<t>This document does not introduce any additional security issues and the security mechanisms defined in <xref target="RFC8762" format="default"
the security mechanisms defined in <xref target="RFC8762"/> and <xref /> and <xref target="RFC8972" format="default"/> apply in this document.</t>
target="RFC8972"/> apply in this document.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Mach Chen, Min Xiao, Fang Xin, Marcus
Ihlar, Richard Foote for the valuable comments to this work.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.8174'?> <displayreference target="I-D.ietf-ippm-stamp-yang" to="STAMP-YANG"/>
<?rfc include='reference.RFC.8762'?>
<?rfc include='reference.RFC.8972'?> <references>
</references> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
762.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
972.xml"/>
</references>
<references>
<name>Informative References</name>
<references title="Informative References"> <reference anchor="IEEE802.1AX" target="https://ieeexplore.ieee.org/docu
<reference anchor="IEEE802.1AX"> ment/9105034">
<front> <front>
<title>IEEE Standard for Local and metropolitan area networks - Link <title>IEEE Standard for Local and Metropolitan Area Networks -- Lin
k
Aggregation</title> Aggregation</title>
<author>
<organization>IEEE</organization>
</author>
<date month="May" year="2020"/>
</front>
<seriesInfo name="IEEE Std" value="802.1AX-2020"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9105034"/>
</reference>
<author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<organization>IEEE Std. 802.1AX</organization> 799.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
668.xml"/>
<date month="November" year="2008"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</front> 656.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
357.xml"/>
<?rfc include='reference.RFC.7799'?>
<?rfc include='reference.RFC.8668'?>
<?rfc include='reference.RFC.4656'?>
<?rfc include='reference.RFC.5357'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. ietf-ippm-stamp-yang.xml"/>
<?rfc include='reference.I-D.ietf-ippm-stamp-yang'?> </references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Mach Chen"/>, <conta
ct fullname="Min Xiao"/>, <contact fullname="Fang Xin"/>, <contact fullname="Mar
cus Ihlar"/>, and <contact fullname="Richard Foote"/> for the valuable comments
to this work.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 93 change blocks. 
254 lines changed or deleted 262 lines changed or added

This html diff was produced by rfcdiff 1.48.