rfc8972xml2.original.xml   rfc8972.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml 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"?>
<rfc category="std" docName="draft-ietf-ippm-stamp-option-tlv-10" ipr="trust2009
02" updates="8762">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<title abbrev="STAMP Extensions">Simple Two-way Active Measurement Protoc <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
ol Optional Extensions</title> docName="draft-ietf-ippm-stamp-option-tlv-10"
number="8972"
ipr="trust200902"
updates="8762"
obsoletes=""
submissionType="IETF"
category="std"
consensus="true"
xml:lang="en"
tocInclude="true"
tocDepth="3"
symRefs="true"
sortRefs="true"
version="3">
<front>
<title abbrev="STAMP Extensions">Simple Two-Way Active Measurement Protocol
Optional Extensions</title>
<seriesInfo name="RFC" value="8972"/>
<author fullname="Greg Mirsky" initials="G." surname="Mirsky"> <author fullname="Greg Mirsky" initials="G." surname="Mirsky">
<organization>ZTE Corp.</organization> <organization>ZTE Corp.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country/> <country/>
</postal> </postal>
<email>gregimirsky@gmail.com</email> <email>gregimirsky@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Xiao Min" initials="X." surname="Min">
<author fullname="Xiao Min" initials="X." surname="Min">
<organization>ZTE Corp.</organization> <organization>ZTE Corp.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country/> <country/>
</postal> </postal>
<email>xiao.min2@zte.com.cn</email> <email>xiao.min2@zte.com.cn</email>
</address> </address>
</author> </author>
<!--
<author fullname="Guo Jun" initials="G." surname="Jun">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>68# Zijinghua Road</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>P.R.China</country>
</postal>
<phone>+86 18105183663</phone>
<email>guo.jun2@zte.com.cn</email>
</address>
</author>
-->
<author fullname="Henrik Nydell" initials="H." surname="Nydell"> <author fullname="Henrik Nydell" initials="H." surname="Nydell">
<organization>Accedian Networks</organization> <organization>Accedian Networks</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country/> <country/>
</postal> </postal>
<email>hnydell@accedian.com</email> <email>hnydell@accedian.com</email>
</address> </address>
</author> </author>
<author initials="R." surname="Foote" fullname="Richard Foote">
<author initials="R." surname="Foote" fullname="Richard Foote"> <organization>Nokia</organization>
<organization>Nokia</organization> <address>
<address> <email>footer.foote@nokia.com </email>
<email>footer.foote@nokia.com </email> </address>
</address> </author>
</author> <author initials="A." surname="Masputra" fullname="Adi Masputra">
<organization>Apple Inc.</organization>
<author initials="A." surname="Masputra" fullname="Adi Masputra"> <address>
<organization>Apple Inc.</organization> <postal>
<address> <street>One Apple Park Way</street>
<postal> <city>Cupertino</city>
<street>One Apple Park Way</street> <region>CA</region>
<city>Cupertino</city> <code>95014</code>
<region>CA</region> <country>United States of America</country>
<code>95014</code> </postal>
<country>USA</country> <email>adi@apple.com</email>
</postal> </address>
<email>adi@apple.com</email> </author>
</address> <author fullname="Ernesto Ruffini" initials="E." surname="Ruffini">
</author>
<author fullname="Ernesto Ruffini" initials="E." surname="Ruffini">
<organization>OutSys</organization> <organization>OutSys</organization>
<address> <address>
<postal> <postal>
<street>via Caracciolo, 65</street> <street>via Caracciolo, 65</street>
<city>Milano</city> <city>Milan</city>
<code>20155</code> <code>20155</code>
<country>Italy</country> <country>Italy</country>
</postal> </postal>
<email>eruffini@outsys.org</email> <email>eruffini@outsys.org</email>
</address> </address>
</author> </author>
<date year="2021" month="January" />
<date year="2020"/>
<area>Transport</area> <area>Transport</area>
<workgroup>Network Working Group</workgroup> <workgroup>Network Working Group</workgroup>
<keyword>IPPM</keyword>
<keyword>Internet-Draft</keyword> <keyword>Performance Measurement </keyword>
<abstract>
<keyword>IPPM</keyword> <t>
<keyword>Performance Measurement </keyword>
<abstract>
<t>
This document describes optional extensions to Simple This document describes optional extensions to Simple
Two-way Active Measurement Protocol (STAMP) that enable Two-way Active Measurement Protocol (STAMP) that enable
measurement of performance metrics. The document also defines measurement of performance metrics. The document also defines
a STAMP Test Session Identifier and thus updates RFC 8762. a STAMP Test Session Identifier and thus updates RFC 8762.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section anchor="intro" numbered="true" toc="default">
<section anchor="intro" title="Introduction"> <name>Introduction</name>
<t> <t>
Simple Two-way Active Measurement Protocol (STAMP) <xref target="RFC8762"/> defi The Simple Two-way Active Measurement Protocol (STAMP) <xref target="RFC8762" fo
ned the STAMP base functionalities. rmat="default"/> defines the STAMP base functionalities.
This document specifies the use of This document specifies the use of
optional extensions that use Type-Length-Value (TLV) encoding. optional extensions that use Type-Length-Value (TLV) encoding.
Such extensions enhance the STAMP base functions, Such extensions enhance the STAMP base functions,
such as measurement of one-way and round-trip delay, such as measurement of one-way and round-trip delay,
latency, packet loss, packet duplication, and latency, packet loss, packet duplication, and
out-of-order delivery of test packets. This specification defines out-of-order delivery of test packets. This specification defines
optional STAMP extensions, their formats, and the theory of operation. optional STAMP extensions, their formats, and the theory of operation.
Also, a STAMP Test Session Identifier is defined Also, a STAMP Test Session Identifier is defined
as an update of the base STAMP specification <xref target="RFC8762"/>. as an update of the base STAMP specification <xref target="RFC8762" format="defa
</t> ult"/>.
</section> </t>
</section>
<section title="Conventions Used in This Document"> <section numbered="true" toc="default">
<section title="Acronyms"> <name>Conventions Used in This Document</name>
<t>BDS BeiDou Navigation Satellite System</t> <section numbered="true" toc="default">
<t>BITS Building Integrated Timing Supply </t> <name>Acronyms</name>
<t>CoS Class of Service</t>
<t>DSCP Differentiated Services Code Point</t>
<t>ECN Explicit Congestion Notification</t>
<t>GLONASS Global Orbiting Navigation Satellite System</t>
<t>GPS Global Positioning System <xref target="GPS"/></t>
<t>HMAC Hashed Message Authentication Code</t>
<t>LORAN-C Long Range Navigation System Version C</t>
<t>MBZ Must Be Zero</t>
<t>NTP Network Time Protocol <xref target="RFC5905"/></t>
<t>PMF Performance Measurement Function</t>
<t>PTP Precision Time Protocol <xref target="IEEE.1588.2008"/></t>
<t>TLV Type-Length-Value</t>
<t>SSID STAMP Session Identifier</t>
<t>SSU Synchronization Supply Unit</t>
<t>STAMP Simple Two-way Active Measurement Protocol</t>
</section>
<section 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>
</section>
<dl newline="false" indent="12">
<dt>BDS</dt><dd>BeiDou Navigation Satellite System</dd>
<dt>BITS</dt><dd>Building Integrated Timing Supply</dd>
<dt>CoS</dt><dd>Class of Service</dd>
<dt>DSCP</dt><dd>Differentiated Services Code Point</dd>
<dt>ECN</dt><dd>Explicit Congestion Notification</dd>
<dt>GLONASS</dt><dd>Global Orbiting Navigation Satellite System</dd>
<dt>GPS</dt><dd>Global Positioning System <xref target="GPS" format="default"/><
/dd>
<dt>HMAC</dt><dd>Hashed Message Authentication Code</dd>
<dt>LORAN-C</dt><dd>Long Range Navigation System Version C</dd>
<dt>MBZ</dt><dd>Must Be Zero</dd>
<dt>NTP</dt><dd>Network Time Protocol <xref target="RFC5905" format="default"/><
/dd>
<dt>PMF</dt><dd>Performance Measurement Function</dd>
<dt>PTP</dt><dd>Precision Time Protocol <xref target="IEEE.1588.2008" format="de
fault"/></dd>
<dt>RP</dt><dd>Reverse Path</dd>
<dt>SMI</dt><dd>Structure of Management Information</dd>
<dt>SSID</dt><dd>STAMP Session Identifier</dd>
<dt>SSU</dt><dd>Synchronization Supply Unit</dd>
<dt>STAMP</dt><dd>Simple Two-way Active Measurement Protocol</dd>
<dt>TLV</dt><dd>Type-Length-Value</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section anchor="test-identifier-sec" title="STAMP Test Session Identifier"> <name>Requirements Language</name>
<t> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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 anchor="test-identifier-sec" numbered="true" toc="default">
<name>STAMP Test Session Identifier</name>
<t>
The STAMP Session-Sender transmits test packets to the STAMP Session-Reflector. The STAMP Session-Reflector The STAMP Session-Sender transmits test packets to the STAMP Session-Reflector. The STAMP Session-Reflector
receives the Session-Sender's packet and acts according to the configuration and optional control information receives the Session-Sender's packet and acts according to the configuration and optional control information
communicated in the Session-Sender's test packet. STAMP defines two different te st packet formats, one for communicated in the Session-Sender's test packet. STAMP defines two different te st packet formats: one for
packets transmitted by the STAMP Session-Sender and one for packets packets transmitted by the STAMP Session-Sender and one for packets
transmitted by the STAMP Session-Reflector. STAMP supports two modes: transmitted by the STAMP Session-Reflector. STAMP supports two modes:
unauthenticated and authenticated. Unauthenticated STAMP test packets unauthenticated and authenticated. Unauthenticated STAMP test packets
are compatible on the wire with unauthenticated TWAMP-Test <xref target="RFC5 357"/> are compatible on the wire with unauthenticated TWAMP-Test <xref target="RFC5 357" format="default"/>
packets. packets.
</t> </t>
<t> <t>
By default, STAMP uses symmetrical packets, i.e., the size of the packet By default, STAMP uses symmetrical packets, i.e., the size of the packet
transmitted by the Session-Reflector equals the size of transmitted by the Session-Reflector equals the size of
the packet received by the Session-Reflector. the packet received by the Session-Reflector.
</t> </t>
<t> <t>
A STAMP Session is identified by the 4-tuple (source and destination IP addres ses, A STAMP Session is identified by the 4-tuple (source and destination IP addres ses,
source and destination UDP port numbers). A STAMP Session-Sender source and destination UDP port numbers). A STAMP Session-Sender
MAY generate a locally unique STAMP Session Identifier (SSID). <bcp14>MAY</bcp14> generate a locally unique STAMP Session Identifier (SSID).
The SSID is a two-octet-long non-zero unsigned integer. SSID generation The SSID is a two-octet-long, non-zero unsigned integer. The SSID generation
policy is implementation-specific. <xref target="I-D.gont-numeric-ids-generat policy is implementation specific. <xref target="I-D.irtf-pearg-numeric-ids-g
ion"/> eneration" format="default"/> thoroughly analyzes common algorithms for identifi
thoroughly analyzes common algorithms for identifier generation and their vul er generation and their vulnerabilities.
nerabilities. For example, an implementation can use the algorithms described in <xref targ
For example, an implementation can use algorithms described in Section 7.1 of et="I-D.irtf-pearg-numeric-ids-generation" sectionFormat="of" section="7.1"/>.
<xref target="I-D.gont-numeric-ids-generation"/>. An implementation <bcp14>MUST NOT</bcp14> assign the same identifier to diffe
An implementation MUST NOT assign the same identifier to different STAMP test rent STAMP test sessions.
sessions. A Session-Sender <bcp14>MAY</bcp14> use the SSID to identify
A Session-Sender MAY use the SSID to identify a STAMP test session. If the SSID is used, it <bcp14>MUST</bcp14> be present i
a STAMP test session. If the SSID is used, it MUST be present in each test pac n each test packet of the given test session.
ket of the given test session. In the unauthenticated mode, the SSID is located as displayed in <xref target=
In the unauthenticated mode, the SSID is located as displayed in <xref target= "session-sender-unauthenticated-format" format="default"/>.
"session-sender-unauthenticated-format"/>. </t>
<figure align="left" anchor="session-sender-unauthenticated-format" t <figure anchor="session-sender-unauthenticated-format">
itle="The format of an extended STAMP Session-Sender test packet in unauthentica <name>The Format of an Extended STAMP Session-Sender Test Packet in Unau
ted mode"> thenticated Mode</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | SSID | | Error Estimate | SSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 248 skipping to change at line 212
| | | |
| MBZ (28 octets) | | MBZ (28 octets) |
| | | |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~ ~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
An implementation of the STAMP Session-Reflector that supports this specificat <t>
ion MUST An implementation of the STAMP Session-Reflector that supports this specificat
ion <bcp14>MUST</bcp14>
identify a STAMP Session using the SSID in combination with elements of the u sual 4-tuple identify a STAMP Session using the SSID in combination with elements of the u sual 4-tuple
for the session. Before a test session commences, a Session-Reflector MUST be for the session. Before a test session commences, a Session-Reflector <bcp14>
provisioned MUST</bcp14> be provisioned
with all the elements that identify the STAMP Session. A STAMP Session-Reflec with all the elements that identify the STAMP Session. A STAMP Session-Reflec
tor MUST discard tor <bcp14>MUST</bcp14> discard
non-matching STAMP test packet(s). The means of provisioning the STAMP Sessio non-matching STAMP test packets. The means of provisioning the STAMP Session
n identification identification
is outside the scope of this specification. is outside the scope of this specification.
<!-- If the Session-Reflector finds that
the SSID and 4-tuple combination changes during a test session, then A conforming implementation of a STAMP Session-Reflector <bcp14>MUST</bcp14>
the Session-Reflector MUST discard the non-matching packet(s) and take copy
no further action on them.
A conforming implementation of STAMP Session-Reflector MUST copy
the SSID value from the received test packet and put it into the reflected pac ket, the SSID value from the received test packet and put it into the reflected pac ket,
as displayed in <xref target="session-reflector-unauthenticated-format"/>. as displayed in <xref target="session-reflector-unauthenticated-format" format
<figure align="left" anchor="session-reflector-unauthenticated-format" t ="default"/>.
itle="The format of an extended STAMP Session-Reflector test packet in unauthent </t>
icated mode"> <figure anchor="session-reflector-unauthenticated-format">
<artwork><![CDATA[ <name>The Format of an Extended STAMP Session-Reflector Test Packet in U
nauthenticated Mode</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | SSID | | Error Estimate | SSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 290 skipping to change at line 253
| Session-Sender Timestamp | | Session-Sender Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Error Estimate | MBZ | | Session-Sender Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ses-Sender TTL | MBZ | |Ses-Sender TTL | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~ ~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</t> <t>
<t>
A STAMP Session-Reflector that does not support this specification A STAMP Session-Reflector that does not support this specification
will return the zeroed SSID field in the reflected STAMP test packet. will return the zeroed SSID field in the reflected STAMP test packet.
The Session-Sender MAY stop the session if it receives a zeroed SSID field. An The Session-Sender <bcp14>MAY</bcp14> stop the session if it receives a zeroed
implementation SSID field. An implementation
of a Session-Sender MUST support control of its behavior in such a scenario. of a Session-Sender <bcp14>MUST</bcp14> support control of its behavior in such
If the test session is not stopped, the Session-Sender, can, for example, a scenario.
send a base STAMP packet <xref target="RFC8762"/> or continue transmitting STAM If the test session is not stopped, the Session-Sender can, for example,
P test packets with the SSID. send a base STAMP packet <xref target="RFC8762" format="default"/> or continue
transmitting STAMP test packets with the SSID.
</t> </t>
<t> <t>
Location of the SSID field in the authenticated mode The location of the SSID field in the authenticated mode
is shown in <xref target="session-sender-authenticated-format"/> and <xref tar is shown in Figures <xref target="session-sender-authenticated-format" format=
get="session-reflector-authenticated-format"/>. "counter"/> and <xref target="session-reflector-authenticated-format" format="co
<figure align="left" anchor="session-sender-authenticated-format" title unter"/>.
="Base STAMP Session-Sender test packet format in authenticated mode"> </t>
<artwork><![CDATA[ <figure anchor="session-sender-authenticated-format">
<name>The Format of an Extended STAMP Session-Sender Test Packet in Auth
enticated Mode</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| MBZ (12 octets) | | MBZ (12 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
skipping to change at line 330 skipping to change at line 294
| MBZ (68 octets) | | MBZ (68 octets) |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~ ~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork></figure>
</figure> <figure anchor="session-reflector-authenticated-format">
<name>The Format of an Extended STAMP Session-Reflector Test Packet in A
<figure align="left" anchor="session-reflector-authenticated-format" tit uthenticated Mode</name>
le="Base STAMP Session-Reflector test packet format in authenticated mode"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
0 1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) | | MBZ (12 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
skipping to change at line 383 skipping to change at line 346
| MBZ (15 octets) | | MBZ (15 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~ ~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</t> </section>
</section> <section anchor="stamp-extension-section" numbered="true" toc="default">
<name>TLV Extensions to STAMP</name>
<section anchor="stamp-extension-section" title="TLV Extensions to STAMP">
<t> <t>
The Type-Length-Value (TLV) encoding scheme provides a flexible The Type-Length-Value (TLV) encoding scheme provides a flexible
extension mechanism for optional informational elements. extension mechanism for optional informational elements.
TLV is an optional field in the STAMP test packet. Multiple TLVs TLV is an optional field in the STAMP test packet. Multiple TLVs
MAY be placed in a STAMP test packet. Additional TLVs <bcp14>MAY</bcp14> be placed in a STAMP test packet. Additional TLVs
may be enclosed within a given TLV, subject to the semantics of the may be enclosed within a given TLV, subject to the semantics of the
(outer) TLV in question. (outer) TLV in question.
TLVs have a one-octet-long STAMP TLV Flags field, a one-octet-long Type field, and TLVs have a one-octet-long STAMP TLV Flags field, a one-octet-long Type field, and
a two-octet-long Length field that is equal to the length of the Value field i n octets. a two-octet-long Length field that is equal to the length of the Value field i n octets.
If a Type value for TLV or sub-TLV is in the range for Vendor If a Type value for a TLV or sub-TLV is in the range for
Private Use, the Length MUST be at least 4, and the first four octets Private Use <xref target="RFC8126"/>, the length <bcp14>MUST</bcp14> be at le
MUST be that vendor's Structure of ast 4, and the first four octets
<bcp14>MUST</bcp14> be that vendor's Structure of
Management Information (SMI) Private Enterprise Code, as recorded in Management Information (SMI) Private Enterprise Code, as recorded in
IANA's SMI Private Enterprise Codes sub-registry, in network octet IANA's "SMI Network Management Private Enterprise Codes" subregistry, in netw ork octet
order. The rest of the Value field is private to the vendor. order. The rest of the Value field is private to the vendor.
The following sections describe the use of TLVs for STAMP The following sections describe the use of TLVs for STAMP
that extend the STAMP capability beyond its base specification. that extend the STAMP capability beyond its base specification.
<figure align="left" anchor="tlv-format" title="TLV Format in a STAMP </t>
Extended Packet"> <figure anchor="tlv-format">
<artwork><![CDATA[ <name>TLV Format in a STAMP Extended Packet</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 | Length | |STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~ ~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
where fields are defined as the following: <t>
<list style="symbols"> The fields are defined as follows:
<t>STAMP TLV Flags - eight-bit-long field. Detailed format and interpret </t>
ation of flags defined in this specification is below.</t> <dl spacing="normal" newline="false">
<t>Type - one-octet-long field that characterizes the interpretation of <dt>STAMP TLV Flags:</dt><dd>An eight-bit-long field. The detailed forma
the Value field. It is allocated by IANA, as specified in <xref target=" t and interpretation of flags defined in this specification are below.</dd>
iana-stamp-tlv-registry"/>.</t> <dt>Type:</dt><dd>A one-octet-long field that characterizes the interpre
<t>Length - two-octet-long field equal to the length of the Value field i tation of
n octets.</t> the Value field. It is allocated by IANA, as specified in <xref target="
<t>Value - a variable-length field. Its interpretation and encoding is de iana-stamp-tlv-registry" format="default"/>.</dd>
termined by the value of the Type field.</t> <dt>Length:</dt><dd>A two-octet-long field equal to the length of the Va
</list> lue field in octets.</dd>
All multibyte fields in TLVs defined in this specification are in network <dt>Value:</dt><dd>A variable-length field. Its interpretation and encod
byte order. ing are determined by the value of the Type field.</dd>
</t> </dl>
<t> <t>
The format of the STAMP TLV Flags displayed in <xref target="tlv-flags-format"/> All multi-byte fields in TLVs defined in this specification are in networ
and the location of flags is according to <xref target="iana-tlv-flags-reg"/>. k byte order.
<figure align="left" anchor="tlv-flags-format" title="STAMP TLV Flags </t>
Format">
<artwork><![CDATA[ <t>
The format of the STAMP TLV Flags is displayed in <xref target="tlv-flags-format
" format="default"/>, and the location of flags is defined in <xref target="iana
-tlv-flags-reg" format="default"/>.
</t>
<figure anchor="tlv-flags-format">
<name>STAMP TLV Flags Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|U|M|I|R|R|R|R|R| |U|M|I|R|R|R|R|R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
where fields are defined as the following: The fields are defined as follows:
<list style="symbols"> </t>
<t>U (Unrecognized) is a one-bit flag. <dl newline="false" spacing="normal">
A Session-Sender MUST set the U flag to 1 before transmitting an extende <dt>U (Unrecognized):</dt><dd>A one-bit flag.
d STAMP test packet. A Session-Sender <bcp14>MUST</bcp14> set the U flag to 1 before transmit
A Session-Reflector MUST set the U flag to 1 if the Session-Reflector ha ting an extended STAMP test packet.
s not understood the TLV. A Session-Reflector <bcp14>MUST</bcp14> set the U flag to 1 if the Sessi
Otherwise, the Session-Reflector MUST set the U flag in the reflected pa on-Reflector has not understood the TLV.
cket to 0.</t> Otherwise, the Session-Reflector <bcp14>MUST</bcp14> set the U flag in t
<t>M (Malformed) is a one-bit flag. he reflected packet to 0.</dd>
A Session-Sender MUST set the M flag to 0 before transmitting an extende <dt>M (Malformed):</dt><dd>A one-bit flag.
d STAMP test packet. A Session-Sender <bcp14>MUST</bcp14> set the M flag to 0 before transmit
A Session-Reflector MUST set the M flag to 1 if the Session-Reflector de ting an extended STAMP test packet.
termined the TLV is malformed, A Session-Reflector <bcp14>MUST</bcp14> set the M flag to 1 if the Sessi
on-Reflector determined the TLV is malformed,
i.e., the Length field value is not valid for the particular type, or i.e., the Length field value is not valid for the particular type, or
the remaining length of the extended STAMP packet is less than the size of the TLV. the remaining length of the extended STAMP packet is less than the size of the TLV.
Otherwise, the Session-Reflector MUST set the M flag in the reflected pa Otherwise, the Session-Reflector <bcp14>MUST</bcp14> set the M flag in t
cket to 0. he reflected packet to 0.
</t> </dd>
<t>I (Integrity) is a one-bit flag. <dt>I (Integrity):</dt><dd>A one-bit flag.
A Session-Sender MUST set the I flag to 0 before transmitting an extende A Session-Sender <bcp14>MUST</bcp14> set the I flag to 0 before transmit
d STAMP test packet. ting an extended STAMP test packet.
A Session-Reflector MUST set the I flag to 1 if the STAMP extensions hav A Session-Reflector <bcp14>MUST</bcp14> set the I flag to 1 if the STAMP
e failed HMAC verification (<xref target="hmac-sec"/>). extensions have failed HMAC verification (<xref target="hmac-sec" format="defau
Otherwise, the Session-Reflector MUST set the I flag in the reflected pa lt"/>).
cket to 0.</t> Otherwise, the Session-Reflector <bcp14>MUST</bcp14> set the I flag in t
<t>R - reserved flags for future use. These flags MUST be zeroed on trans he reflected packet to 0.</dd>
mit and ignored on receipt.</t> <dt>R:</dt><dd>Reserved flags for future use. These flags <bcp14>MUST</b
</list> cp14> be zeroed on transmit and ignored on receipt.</dd>
</t> </dl>
<t> <t>
A STAMP node, whether Session-Sender or Session-Reflector, receiving a test pack A STAMP node, whether Session-Sender or Session-Reflector, receiving a test pack
et MUST et <bcp14>MUST</bcp14>
determine whether the packet is a base STAMP packet or includes one or more TLVs determine whether the packet is a base STAMP packet or whether it includes one o
. r more TLVs.
The node MUST compare the value in the Length field of the UDP header and The node <bcp14>MUST</bcp14> compare the value in the Length field of the UDP he
the length of the base STAMP test packet in the mode, unauthenticated or authent ader and
icated based the length of the base STAMP test packet in the mode, unauthenticated or authent
icated, based
on the configuration of the particular STAMP test session. If the difference bet ween the two values is on the configuration of the particular STAMP test session. If the difference bet ween the two values is
larger than the length of the UDP header, then the test packet includes one or m ore STAMP TLVs greater than the length of the UDP header, then the test packet includes one or more STAMP TLVs
that immediately follow the base STAMP test packet. that immediately follow the base STAMP test packet.
A Session-Reflector that does not support STAMP extensions will not process but A Session-Reflector that does not support STAMP extensions will not process but
copy them into the reflected packet, as defined in Section 4.3 <xref target="RFC copy them into the reflected packet, as defined in <xref
8762"/>. target="RFC8762" sectionFormat="of" section="4.3"/>.
A Session-Reflector that supports TLVs will indicate specific TLVs that A Session-Reflector that supports TLVs will indicate specific TLVs that
it did not process by setting the U flag to 1 in those TLVs. it did not process by setting the U flag to 1 in those TLVs.
</t> </t>
<t> <t>
A STAMP Session-Sender that has received a reflected STAMP test packet with exte A STAMP Session-Sender that has received a reflected STAMP test packet with exte
nsion TLVs MUST validate each TLV: nsion TLVs <bcp14>MUST</bcp14> validate each TLV:
<list style="symbol">
<t>
If the U flag is set, the STAMP system MUST skip the processing of the TLV.
</t>
<t>
If the M flag is set, the STAMP system MUST stop processing the remainder of the
extended STAMP packet.
</t>
<t>
If the I flag is set, the STAMP system MUST discard all TLVs and
MUST stop processing the remainder of the extended STAMP packet.
</t> </t>
<t> <ul spacing="normal">
<li>
If the U flag is set, the STAMP system <bcp14>MUST</bcp14> skip the processing o
f the TLV.
</li>
<li>
If the M flag is set, the STAMP system <bcp14>MUST</bcp14> stop processing the r
emainder of the extended STAMP packet.
</li>
<li>
If the I flag is set, the STAMP system <bcp14>MUST</bcp14> discard all TLVs and
<bcp14>MUST</bcp14> stop processing the remainder of the extended STAMP packet.
</li>
<li>
If an implementation of a Session-Reflector does not recognize the Type field va lue, If an implementation of a Session-Reflector does not recognize the Type field va lue,
it MUST include a copy of the TLV into the reflected STAMP packet. it <bcp14>MUST</bcp14> include a copy of the TLV in the reflected STAMP packet.
The Session-Reflector MUST set the U flag to 1. The Session-Reflector <bcp14>MUST</bcp14> set the U flag to 1.
The Session-Reflector MUST skip the processing of the unrecognized TLV. The Session-Reflector <bcp14>MUST</bcp14> skip the processing of the unrecognize
</t> d TLV.
<t> </li>
If a TLV is malformed, the processing of extension TLVs MUST be <li>
stopped. The Session-Reflector MUST copy the remainder of the received extended If a TLV is malformed, the processing of extension TLVs <bcp14>MUST</bcp14> be
STAMP packet into the reflected STAMP packet. stopped. The Session-Reflector <bcp14>MUST</bcp14> copy the remainder of the rec
The Session-Reflector MUST set the M flag to 1. eived extended STAMP packet into the reflected STAMP packet.
</t> The Session-Reflector <bcp14>MUST</bcp14> set the M flag to 1.
</list> </li>
<!-- </ul>
An operator MUST be notified of the error. Detected error events MAY be logged. <t>
Note that the rate of logging MUST be controlled.
</t> </t>
<section anchor="padding-tlv-section" numbered="true" toc="default">
<name>Extra Padding TLV</name>
<section anchor="padding-tlv-section" title="Extra Padding TLV"> <figure anchor="padding-tlv-figuret">
<t> <name>Extra Padding TLV</name>
<figure align="left" anchor="padding-tlv-figuret" title="Extra Padding T <artwork name="" type="" align="left" alt=""><![CDATA[
LV">
<artwork><![CDATA[
0 1 2 3 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|Extra Pad Type | Length | |STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Extra Padding ~ ~ Extra Padding ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
where fields are defined as the following: <t>
<list style="symbols"> The fields are defined as follows:
<t>STAMP TLV Flags - is an eight-bit-long field. Its format is presented </t>
in <xref target="tlv-flags-format"/>.</t> <dl spacing="normal" newline="false">
<t>Extra Padding Type - is a one-octet-long field, value TBA1 allocated <dt>STAMP TLV Flags:</dt><dd>An eight-bit-long field. Its format is pr
by IANA <xref target="iana-stamp-tlv-registry"/>.</t> esented in <xref target="tlv-flags-format" format="default"/>.</dd>
<t>Length - two-octet-long field equal to the length of the Extra Padding <dt>Type:</dt><dd>A one-octet-long field. Value 1 has been allocated b
field in octets.</t> y IANA (<xref target="iana-stamp-tlv-registry" format="default"/>).</dd>
<t>Extra Padding - SHOULD be filled by a sequence of a pseudo-random numb <dt>Length:</dt><dd>A two-octet-long field equal to the length of the
ers. The field MAY be filled with all zeros. Extra Padding field in octets.</dd>
An implementation MUST control the type of filling of the Extra Padding f <dt>Extra Padding:</dt><dd>This field <bcp14>SHOULD</bcp14> be filled
ield.</t> by a sequence of pseudorandom numbers. The field <bcp14>MAY</bcp14> be filled wi
</list> th all zeros.
</t> An implementation <bcp14>MUST</bcp14> control the content of the Extra Pa
<t> dding field.</dd>
The Extra Padding TLV is similar to the Packet Padding field in a TWAMP-Test p </dl>
acket <xref target="RFC5357"/>. <t>
The use of the Extra Padding TLV is RECOMMENDED to perform a STAMP test using The Extra Padding TLV is similar to the Packet Padding field in a TWAMP-Test p
test packets of larger size than the base STAMP packet acket <xref target="RFC5357" format="default"/>.
<xref target="RFC8762"/>. The length of the base STAMP packet is 44 octets The use of the Extra Padding TLV is <bcp14>RECOMMENDED</bcp14> to perform a ST
AMP test using
test packets that are larger than the base STAMP packet
<xref target="RFC8762" format="default"/>. The length of the base STAMP packet
is 44 octets
in the unauthenticated mode or 112 octets in the authenticated mode. in the unauthenticated mode or 112 octets in the authenticated mode.
The Extra Padding TLV MAY be present more than one time in an extended STAMP t The Extra Padding TLV <bcp14>MAY</bcp14> be present more than one time in an e
est packet. xtended STAMP test packet.
</t> </t>
</section> </section>
<section anchor="location-info-section" numbered="true" toc="default">
<name>Location TLV</name>
<section anchor="location-info-section" title="Location TLV"> <t>
<t> STAMP Session-Senders <bcp14>MAY</bcp14> include the variable-size Location TL
STAMP Session-Senders MAY include the variable-size Location TLV to query loca V to query location information from the Session-Reflector.
tion information from the Session-Reflector. The Session-Sender <bcp14>MUST NOT</bcp14> fill any information fields except
The Session-Sender MUST NOT fill any information fields except for STAMP TLV F for the STAMP TLV Flags, Type, and Length fields.
lags, Type, and Length. The Session-Reflector <bcp14>MUST</bcp14> verify that the TLV is well formed.
The Session-Reflector MUST verify that the TLV is well-formed. If it is not, t If it is not, the Session-Reflector follows the procedure defined in <xref targe
he Session-Reflector follows the procedure defined in <xref target="stamp-extens t="stamp-extension-section" format="default"/>
ion-section"/>
for a malformed TLV. for a malformed TLV.
<figure align="left" anchor="location-tlv-figuret" title="Location TLV"> </t>
<artwork><![CDATA[ <figure anchor="location-tlv-figuret">
<name>Location TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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| Location Type | Length | |STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port | Source Port | | Destination Port | Source Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs ~ ~ Sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
where fields are defined as the following: <t>
<list style="symbols"> The fields are defined as follows:
<t>STAMP TLV Flags - is an eight-bit-long field. Its format is present </t>
ed in <xref target="tlv-flags-format"/>.</t> <dl spacing="normal" newline="false">
<t>Location Type - is a one-octet-long field, value TBA2 allocated by IA <dt>STAMP TLV Flags:</dt><dd>An eight-bit-long field. Its format is pr
NA <xref target="iana-stamp-tlv-registry"/>.</t> esented in <xref target="tlv-flags-format" format="default"/>.</dd>
<t>Length - two-octet-long field equal to the length of the Value field i <dt>Type:</dt><dd>A one-octet-long field. Value 2 has been allocated b
n octets.</t> y IANA (<xref target="iana-stamp-tlv-registry" format="default"/>).</dd>
<t>Destination Port - two-octet-long UDP destination port number of the <dt>Length:</dt><dd>A two-octet-long field equal to the length of the
received STAMP packet.</t> Value field in octets.</dd>
<t>Source Port - two-octet-long UDP source port number of the received S <dt>Destination Port:</dt><dd>A two-octet-long UDP destination port nu
TAMP packet.</t> mber of the received STAMP packet.</dd>
<t>Sub-TLVs - a sequence of sub-TLVs, as defined further in this section <dt>Source Port:</dt><dd>A two-octet-long UDP source port number of th
. The sub-TLVs are used by the e received STAMP packet.</dd>
<dt>Sub-TLVs:</dt><dd>A sequence of sub-TLVs, as defined further in th
is section. The sub-TLVs are used by the
Session-Sender to request location information with generic sub-TLV type s, and the Session-Sender to request location information with generic sub-TLV type s, and the
Session-Reflector responds with the corresponding more-specific sub-TLVs Session-Reflector responds with the corresponding more-specific sub-TLVs
for the type of address (e.g., IPv4 or IPv6) used at the Session-Reflect for the type of address (e.g., IPv4 or IPv6) used at the Session-Reflect
or.</t> or.</dd>
</list> </dl>
</t> <t>Note that all fields not filled by either a Session-Sender or Session
<t>Note that all fields not filled by either a Session-Sender or Session-Refle -Reflector are transmitted with all bits set to zero.</t>
ctor are transmitted with all bits set to zero.</t> <section anchor="location-sub-tlv-sec" numbered="true" toc="default">
<name>Location Sub-TLVs</name>
<t>
A sub-TLV in the Location TLV uses the format displayed in <xref target="tlv-f
ormat" format="default"/>.
Handling of the U and M flags in the sub-TLV is as defined in <xref target="st
amp-extension-section" format="default"/>.
The I flag <bcp14>MUST</bcp14> be set by a Session-Sender and Session-Reflecto
r to 0 before transmission and its value ignored on receipt.
The following types of sub-TLVs for the Location TLV are defined in this speci
fication
(<xref target="sub-tlv-type-tbl" format="default"/> lists the Type values):
</t>
<dl newline="false" spacing="normal">
<dt>Source MAC Address sub-TLV:</dt><dd>A 12-octet-long sub-TLV.
The Type value is 1.
The value of the Length field <bcp14>MUST</bcp14> be equal to 8.
The Value field is an 8-octet-long MBZ field that <bcp14>MUST</bcp14> be zeroe
d on transmission and ignored on receipt.
</dd>
<dt>
Source EUI-48 Address sub-TLV:</dt><dd><t>A 12-octet-long sub-TLV that inclu
des the EUI-48 source MAC address.
The Type value is 2.
The value of the Length field <bcp14>MUST</bcp14> be equal to 8.</t>
<section anchor="location-sub-tlv-sec" title="Location Sub-TLVs"> <figure anchor="eui-48-tlv-figure">
<t> <name>The Value Field of the Source EUI-48 Address Sub-TLV</name
A sub-TLV in the Location TLV uses the format displayed in <xref target="tlv-f >
ormat"/>. <artwork name="" type="" align="left" alt=""><![CDATA[
<!-- 0 1 2 3
A Session-Sender MUST set the U flag in a sub-TLV to 1 before transmitting the 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
extended STAMP test packet. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Session-Reflector MUST set the sub-TLV's U flag in the reflected test pack | EUI-48 Address |
et to 0 if it supports that type of sub-TLV. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the Session-Reflector doesn't recognize the sub-TLV, it must copy it from t | | MBZ |
he received packet into the reflected packet. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Session-Sender MUST set the M flag in a sub-TLV to 0 before transmitting the
extended STAMP test packet.
The Session-Reflector MUST set the M flag in the sub-TLV in the reflected pack
et to 1 if the sub-TLV is malformed. The Session-Reflector MUST
stop processing the Location TLV and MUST copy the remaining part of the Locat
ion TLV into the reflected test packet.
-->
Handling of the U and M flags in the sub-TLV is as defined in <xref target="st
amp-extension-section"/>.
The I flag MUST be set by a Session-Sender and Session-Reflector to 0 before t
ransmission and its value ignored on receipt.
The following types of sub-TLV for the Location TLV are defined in this specif
ication
(type values are assigned according to <xref target="sub-tlv-type-tbl"/>):
<list style="symbols">
<t>
Source MAC Address sub-TLV - is a 12-octet-long sub-TLV.
The Type value is TBA9.
The value of the Length field MUST equal to 8.
The Value field is an 8-octet-long MBZ field that MUST be zeroed on transmissi
on and ignored on receipt.
</t>
<t>
Source EUI-48 Address sub-TLV - is a 12-octet-long sub-TLV that includes th
e EUI-48 source MAC address.
The Type value is TBA10.
The value of the Length field MUST equal to 8.
<figure align="left" anchor="eui-48-tlv-figure" title="The Value Field
of the Source EUI-48 Address sub-TLV">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EUI-48 Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure>
<t>
The Value field consists of the following fields (<xref target="eui-48-tlv-fig
ure" format="default"/>):
</t>
<dl spacing="normal">
<dt>EUI-48 Address:</dt><dd>A six-octet-long field.</dd>
<dt>MBZ:</dt><dd>A two-octet-long field. It <bcp14>MUST</bcp14>
be zeroed on transmission and ignored on receipt.</dd>
</dl>
</dd>
The Value field consists of the following fields (<xref target="eui-48-tlv-fig <dt>Source EUI-64 Address sub-TLV:</dt><dd>A 12-octet-long sub-TLV t
ure"/>): hat includes the EUI-64 source MAC address.
<list> The Type value is 3.
<t>The EUI-48 is a six-octet-long field.</t> The value of the Length field <bcp14>MUST</bcp14> be equal to 8.
<t>Two-octet-ling MBZ field MUST be zeroed on transmission and ignored on rece
ipt.</t>
</list>
</t>
<t>
Source EUI-64 Address sub-TLV - is a 12-octet-long sub-TLV that includes the
EUI-64 source MAC address.
The Type value is TBA11.
The value of the Length field MUST equal to 8.
The Value field consists of an eight-octet-long EUI-64 field. The Value field consists of an eight-octet-long EUI-64 field.
</t> </dd>
<t> <dt>
Destination IP Address sub-TLV - is a 20-octet-long sub-TLV. Destination IP Address sub-TLV:</dt><dd>A 20-octet-long sub-TLV.
The Type value is TBA12. The Type value is 4.
The value of the Length field MUST equal to 16. The value of the Length field <bcp14>MUST</bcp14> be equal to 16.
The Value field consists of a 16-octet-long MBZ field that MUST be zero The Value field consists of a 16-octet-long MBZ field that <bcp14>MUST<
ed on transmit and ignored on receipt /bcp14> be zeroed on transmit and ignored on receipt.
</t> </dd>
<t> <dt>
Destination IPv4 Address sub-TLV - is a 20-octet-long sub-TLV that incl Destination IPv4 Address sub-TLV:</dt><dd><t>A 20-octet-long sub-TLV tha
udes IPv4 destination address. t includes the IPv4 destination address.
The Type value is TBA13. The Type value is 5.
The value of the Length field MUST equal to 16. The value of the Length field <bcp14>MUST</bcp14> be equal to 16.</t>
<figure align="left" anchor="ipv4-value-figure" title="IPv4 Addr
ess in a Sub-TLV's Value Field"> <figure anchor="ipv4-value-figure">
<artwork><![CDATA[ <name>IPv4 Address in a Sub-TLV's Value Field</name>
0 1 2 3 <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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
| IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address |
~ MBZ (12 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ~ MBZ (12 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Value field consists of the following fields (<xref target="ipv4-val </figure>
ue-figure"/>): <t>
<list> The Value field consists of the following fields (<xref target="ipv4-val
<t>The IPv4 Address is a four-octet-long field.</t> ue-figure" format="default"/>):
<t>12-octet-long MBZ field MUST be zeroed on transmit and ignored on rec </t>
eipt.</t> <dl spacing="normal">
</list> <dt>IPv4 Address:</dt><dd>A four-octet-long field.</dd>
</t> <dt>MBZ:</dt><dd>A 12-octet-long field. It <bcp14>MUST</bcp14> b
<t> e zeroed on transmit and ignored on receipt.</dd>
Destination IPv6 Address sub-TLV - is a 20-octet-long sub-TLV that incl </dl>
udes IPv6 destination address. </dd>
The Type value is TBA14.
The value of the Length field MUST equal to 16. <dt>
The Value field is a 16-octet-long IP v6 Address field. Destination IPv6 Address sub-TLV:</dt><dd>A 20-octet-long sub-TLV that i
</t> ncludes the IPv6 destination address.
<t> The Type value is 6.
Source IP Address sub-TLV - is a 20-octet-long sub-TLV. The value of the Length field <bcp14>MUST</bcp14> be equal to 16.
The Type value is TBA15.
The value of the Length field MUST equal to 16.
The Value field is a 16-octet-long MBZ field that MUST be zeroed on tran
smit and ignored on receipt
</t>
<t>
Source IPv4 Address sub-TLV - is a 20-octet-long sub-TLV that includes I
Pv4 source address.
The Type value is TBA16.
The value of the Length field MUST equal to 16.
The Value field consists of the following fields (<xref target="ipv4-val
ue-figure"/>):
<list>
<t>The IPv4 Address is a four-octet-long field.</t>
<t>12-octet-long MBZ field that MUST be zeroed on transmit and ignored o
n receipt.</t>
</list>
</t>
<t>
Source IPv6 Address sub-TLV - is a 20-octet-long sub-TLV that includes I
Pv6 source address.
The Type value is TBA17.
The value of the Length field MUST equal to 16.
The Value field is a 16-octet-long IPv6 Address field. The Value field is a 16-octet-long IPv6 Address field.
</t> </dd>
</list> <dt>
</t> Source IP Address sub-TLV:</dt><dd>A 20-octet-long sub-TLV.
</section> The Type value is 7.
The value of the Length field <bcp14>MUST</bcp14> be equal to 16.
The Value field is a 16-octet-long MBZ field that <bcp14>MUST</bcp14> be
zeroed on transmit and ignored on receipt.
</dd>
<dt>
Source IPv4 Address sub-TLV:</dt><dd><t>A 20-octet-long sub-TLV that inc
ludes the IPv4 source address.
The Type value is 8.
The value of the Length field <bcp14>MUST</bcp14> be equal to 16.
The Value field consists of the following fields (<xref target="ipv4-val
ue-figure" format="default"/>):</t>
<dl spacing="normal">
<dt>IPv4 Address:</dt><dd>A four-octet-long field.</dd>
<dt>MBZ:</dt><dd>A 12-octet-long field. It <bcp14>MUST</bcp14> b
e zeroed on transmit and ignored on receipt.</dd>
</dl>
</dd>
<dt>
Source IPv6 Address sub-TLV:</dt><dd>A 20-octet-long sub-TLV that includ
es the IPv6 source address.
The Type value is 9.
The value of the Length field <bcp14>MUST</bcp14> be equal to 16.
The Value field is a 16-octet-long IPv6 Address field.
</dd>
</dl>
</section>
<section anchor="location-operation-sec" numbered="true" toc="default">
<name>Theory of Operation of Location TLV</name>
<t>
<section anchor="location-operation-sec" title="Theory of Operation of Locatio
n TLV">
<t>
The Session-Reflector that received an extended STAMP packet with The Session-Reflector that received an extended STAMP packet with
the Location TLV MUST include the Location TLV of the size equal the Location TLV <bcp14>MUST</bcp14> include in the reflected packet the Locat
to the size of Location TLV in the received packet in the reflected packet. ion TLV with a length equal
Based on the local policy, the Session-Reflector MAY leave some fields unrepor to the Location TLV length in the received packet.
ted by filling them with zeroes. Based on the local policy, the Session-Reflector <bcp14>MAY</bcp14> leave some
An implementation of the stateful Session-Reflector MUST provide control for m fields unreported by filling them with zeroes.
anaging such policies. An implementation of the stateful Session-Reflector <bcp14>MUST</bcp14> provid
</t> e control for managing such policies.
<t> </t>
A Session-Sender MAY include the Source MAC Address sub-TLV in the Location TL <t>
V. A Session-Sender <bcp14>MAY</bcp14> include the Source MAC Address sub-TLV in
the Location TLV.
If the Session-Reflector receives the Location TLV that includes the Source MA C Address sub-TLV, it If the Session-Reflector receives the Location TLV that includes the Source MA C Address sub-TLV, it
MUST include the Source EUI-48 Address sub-TLV if the source MAC address of th <bcp14>MUST</bcp14> include the Source EUI-48 Address sub-TLV if the source MA
e C address of the
received extended test packet is in EUI-48 format. And the Session-Reflector M received extended test packet is in EUI-48 format. And the Session-Reflector <
UST bcp14>MUST</bcp14>
copy the value of the source MAC address in the EUI-48 field. copy the value of the source MAC address in the EUI-48 field.
Otherwise, the Session-Reflector MUST use the Source EUI-64 Address sub-TLV an Otherwise, the Session-Reflector <bcp14>MUST</bcp14> use the Source EUI-64 Add
d MUST copy the value ress sub-TLV and <bcp14>MUST</bcp14> copy the value
of the Source MAC address from the received packet into the EUI-64 field. of the Source MAC Address from the received packet into the EUI-64 field.
If the received extended STAMP test packet does not have the Source MAC addres If the received extended STAMP test packet does not have the Source MAC Addres
s, s,
the Session-Reflector MUST zero the EUI-64 field before transmitting the refle the Session-Reflector <bcp14>MUST</bcp14> zero the EUI-64 field before transmi
cted packet. tting the reflected packet.
</t> </t>
<t> <t>
A Session-Sender MAY include the Destination IP Address sub-TLV in the Locatio A Session-Sender <bcp14>MAY</bcp14> include the Destination IP Address sub-TLV
n TLV. in the Location TLV.
If the Session-Reflector receives the Location TLV that includes the Destinati on IP Address sub-TLV, it If the Session-Reflector receives the Location TLV that includes the Destinati on IP Address sub-TLV, it
MUST include the Destination IPv4 Address sub-TLV if the source IP address of <bcp14>MUST</bcp14> include the Destination IPv4 Address sub-TLV if the source
the IP address of the
received extended test packet is of IPv4 address family. And the Session-Refle received extended test packet is of the IPv4 address family. And the Session-R
ctor MUST eflector <bcp14>MUST</bcp14>
copy the value of the destination IP address in the IPv4 Address field. copy the value of the destination IP address in the IPv4 Address field.
Otherwise, the Session-Reflector MUST use the Destination IPv6 Address sub-TLV and MUST copy the value Otherwise, the Session-Reflector <bcp14>MUST</bcp14> use the Destination IPv6 Address sub-TLV and <bcp14>MUST</bcp14> copy the value
of the destination IP address from the received packet into the IPv6 Address f ield. of the destination IP address from the received packet into the IPv6 Address f ield.
</t> </t>
<t>
A Session-Sender MAY include the Source IP Address sub-TLV in the Location TLV <t>
. A Session-Sender <bcp14>MAY</bcp14> include the Source IP Address sub-TLV in t
he Location TLV.
If the Session-Reflector receives the Location TLV that includes the Source IP Address sub-TLV, it If the Session-Reflector receives the Location TLV that includes the Source IP Address sub-TLV, it
MUST include the Source IPv4 Address sub-TLV if the source IP address of the <bcp14>MUST</bcp14> include the Source IPv4 Address sub-TLV if the source IP a
received extended test packet is of IPv4 address family. And the Session-Refle ddress of the
ctor MUST received extended test packet is of the IPv4 address family. And the Session-R
eflector <bcp14>MUST</bcp14>
copy the value of the source IP address in the IPv4 Address field. copy the value of the source IP address in the IPv4 Address field.
Otherwise, the Session-Reflector MUST use the Source IPv6 Address sub-TLV and MUST copy the value Otherwise, the Session-Reflector <bcp14>MUST</bcp14> use the Source IPv6 Addre ss sub-TLV and <bcp14>MUST</bcp14> copy the value
of the source IP address from the received packet into the IPv6 Address field. of the source IP address from the received packet into the IPv6 Address field.
</t> </t>
<t> <t>
The Location TLV MAY be used to determine the last-hop IP addresses, ports, and The Location TLV <bcp14>MAY</bcp14> be used to determine the last-hop IP address
last-hop MAC address for&#160; STAMP packets. The MAC address can indicate a p es, ports, and
ath switch last-hop MAC address for STAMP packets. The MAC address can indicate a path sw
itch
on the last hop. The IP addresses and UDP ports will indicate on the last hop. The IP addresses and UDP ports will indicate
if there is a NAT router on the path. It allows the Session-Sender to identify the IP address if there is a NAT router on the path. It allows the Session-Sender to identify the IP address
of the Session-Reflector behind the NAT, and detect changes in the NAT mapping of the Session-Reflector behind the NAT and detect changes in the NAT mapping
that could that could result in sending the STAMP packets to the wrong Session-Reflector.
cause sending the STAMP packets to the wrong Session-Reflector. </t>
</t> </section>
</section> </section>
</section> <section anchor="timestamp-info-section" numbered="true" toc="default">
<name>Timestamp Information TLV</name>
<section anchor="timestamp-info-section" title="Timestamp Information TLV"> <t>
<t> The STAMP Session-Sender <bcp14>MAY</bcp14> include the Timestamp Information
The STAMP Session-Sender MAY include the Timestamp Information TLV to request TLV to request information from the Session-Reflector.
information from the Session-Reflector. The Session-Sender <bcp14>MUST NOT</bcp14> fill any information fields except
The Session-Sender MUST NOT fill any information fields except for STAMP TLV F for STAMP TLV Flags, Type, and Length.
lags, Type, and Length. All other fields <bcp14>MUST</bcp14> be filled with zeroes.
All other fields MUST be filled with zeroes. The Session-Reflector <bcp14>MUST</bcp14> validate the Length value of the TLV
The Session-Reflector MUST validate the Length value of the TLV. .
If the value of the Length field is invalid, the Session-Reflector follows the If the value of the Length field is invalid, the Session-Reflector follows the
procedure defined in <xref target="stamp-extension-section"/> for a malformed T procedure defined in <xref target="stamp-extension-section" format="default"/>
LV. for a malformed TLV.
<figure align="left" anchor="timestamp-tlv-figuret" title="Timestamp Inf </t>
ormation TLV"> <figure anchor="timestamp-tlv-figuret">
<artwork><![CDATA[ <name>Timestamp Information TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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|Times Info Type| Length | |STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sync. Src In | Timestamp In | Sync. Src Out | Timestamp Out | | Sync Src In | Timestamp In | Sync Src Out | Timestamp Out |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional sub-TLVs ~ ~ Optional sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
where fields are defined as the following: <t>
<list style="symbols"> The fields are defined as follows:
<t>STAMP TLV Flags - is an eight-bit-long field. Its format is present </t>
ed in <xref target="tlv-flags-format"/>.</t> <dl spacing="normal">
<t>Timestamp Information Type - is a one-octet-long field, value TBA3 al <dt>STAMP TLV Flags:</dt><dd>An eight-bit-long field. Its format is pr
located by IANA <xref target="iana-stamp-tlv-registry"/>.</t> esented in <xref target="tlv-flags-format" format="default"/>.</dd>
<t>Length - two-octet-long field, set equal to the length of the Value fi <dt>Type:</dt><dd>A one-octet-long field. Value 3 has been allocated b
eld in octets (<xref target="tlv-format"/>).</t> y IANA (<xref target="iana-stamp-tlv-registry" format="default"/>).</dd>
<t>Sync Src In - one-octet-long field that characterizes the source of cl <dt>Length:</dt><dd>A two-octet-long field, set equal to the length of
ock synchronization at the ingress of a Session-Reflector. the Value field in octets (<xref target="tlv-format" format="default"/>).</dd>
There are several methods to synchronize the clock, e.g., Network Time Pr <dt>Sync Src In:</dt><dd>A one-octet-long field that characterizes the
otocol (NTP) <xref target="RFC5905"/>. source of clock synchronization at the ingress of a Session-Reflector.
The value is one of those listed in <xref target="ssync-source-new-tbl"/> There are several methods for synchronizing the clock, e.g., the Network
.</t> Time Protocol (NTP) <xref target="RFC5905" format="default"/>.
<t>Timestamp In - one-octet-long field that characterizes the
<xref target="ssync-source-new-tbl" format="default"/> lists the possible
values.</dd>
<dt>Timestamp In:</dt><dd>A one-octet-long field that characterizes th
e
method by which the ingress of the Session-Reflector obtained the timesta mp T2. method by which the ingress of the Session-Reflector obtained the timesta mp T2.
A timestamp may be obtained with hardware assistance, A timestamp may be obtained with hardware assistance via a software API f
via software API from a local wall clock, or from a remote clock (the lat rom a local wall clock or from a remote clock (the latter is referred to as a "c
ter is referred to as "control plane"). ontrol plane").
The value is one of those listed in <xref target="timestamp-method-new-tb <xref target="timestamp-method-new-tbl" format="default"/> lists the possible va
l"/>.</t> lues.</dd>
<t>Sync Src Out - one-octet-long field that characterizes the source of c <dt>Sync Src Out:</dt><dd>A one-octet-long field that characterizes th
lock synchronization at the egress of the Session-Reflector. e source of clock synchronization at the egress of the Session-Reflector.
The value is one of those listed in <xref target="ssync-source-new-tbl"/> <xref target="ssync-source-new-tbl" format="default"/> lists the possible values
.</t> .</dd>
<t>Timestamp Out - one-octet-long field that characterizes the <dt>Timestamp Out:</dt><dd>A one-octet-long field that characterizes t
he
method by which the egress of the Session-Reflector obtained the timestam p T3. method by which the egress of the Session-Reflector obtained the timestam p T3.
The value is one of those listed in <xref target="timestamp-method-new-tb <xref target="timestamp-method-new-tbl" format="default"/> lists the possible va
l"/>.</t> lues.</dd>
<t>Optional sub-TLVs - optional variable-length field.</t> <dt>Optional sub-TLVs:</dt><dd>An optional variable-length field.</dd>
</list> </dl>
</t> </section>
</section>
<section anchor="cos-info-section" title="Class of Service TLV"> <section anchor="cos-info-section" numbered="true" toc="default">
<t> <name>Class of Service TLV</name>
The STAMP Session-Sender MAY include a Class of Service (CoS) TLV in the STAM <t>
P test packet. The STAMP Session-Sender <bcp14>MAY</bcp14> include a Class of Service (CoS)
The format of the CoS TLV is presented in <xref target="cos-tlv-figure"/>. TLV in the STAMP test packet.
The format of the CoS TLV is presented in <xref target="cos-tlv-figure" format
="default"/>.
<figure align="left" anchor="cos-tlv-figure" title="Class of Service TLV </t>
"> <figure anchor="cos-tlv-figure">
<artwork><![CDATA[ <name>Class of Service TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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| CoS Type | Length | |STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP1 | DSCP2 |ECN| RP| Reserved | | DSCP1 | DSCP2 |ECN| RP| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
where fields are defined as the following: <t>
<list style="symbols"> The fields are defined as follows:
<t>STAMP TLV Flags - is an eight-bit-long field. Its format is present </t>
ed in <xref target="tlv-flags-format"/>.</t> <dl spacing="normal">
<t>CoS (Class of Service) Type - is a one-octet-long field, value TBA4 a <dt>STAMP TLV Flags:</dt><dd>An eight-bit-long field. Its format is pr
llocated by IANA <xref target="iana-stamp-tlv-registry"/>.</t> esented in <xref target="tlv-flags-format" format="default"/>.</dd>
<t>Length - two-octet-long field, set equal to the value 4.</t> <dt>Type:</dt><dd>A one-octet-long field. Value 4 has been allocated b
<t>DSCP1 - The Differentiated Services Code Point (DSCP) intended by the y IANA (<xref target="iana-stamp-tlv-registry" format="default"/>).</dd>
Session-Sender <dt>Length:</dt><dd>A two-octet-long field, set equal to the value 4.<
to be used as the DSCP value of the reflected test packet.</t> /dd>
<t>DSCP2 - The received value in the DSCP field at the ingress of the Se <dt>DSCP1:</dt><dd>The Differentiated Services Code Point (DSCP) inten
ssion-Reflector.</t> ded by the Session-Sender
<t>ECN - The received value in the ECN field at the ingress of the Sessi to be used as the DSCP value of the reflected test packet.</dd>
on-Reflector.</t> <dt>DSCP2:</dt><dd>The received value in the DSCP field at the ingress
<t>RP (Reverse Path) - is a two-bit-long field. A Session-Sender MUST se of the Session-Reflector.</dd>
t the value of the RP field to 0 on transmission.</t> <dt>ECN:</dt><dd>The received value in the ECN field at the ingress of
<t>Reserved - 16-bit-long field, MUST be zeroed on transmission and igno the Session-Reflector.</dd>
red on receipt.</t> <dt>RP (Reverse Path):</dt><dd>A two-bit-long field. A Session-Sender
</list> <bcp14>MUST</bcp14> set the value of the RP field to 0 on transmission.</dd>
</t> <dt>Reserved:</dt><dd>A 16-bit-long field that <bcp14>MUST</bcp14> be
<t> zeroed on transmission and ignored on receipt.</dd>
A STAMP Session-Reflector that receives a test packet with the CoS TLV MUST in </dl>
clude <t>
the CoS TLV in the reflected test packet. Also, the Session-Reflector MUST cop A STAMP Session-Reflector that receives a test packet with the CoS TLV <bcp14>
y MUST</bcp14> include
the CoS TLV in the reflected test packet. Also, the Session-Reflector <bcp14>M
UST</bcp14> copy
the value of the DSCP and ECN fields of the IP header of the received STAMP te st packet into the DSCP2 field in the value of the DSCP and ECN fields of the IP header of the received STAMP te st packet into the DSCP2 field in
the reflected test packet. Finally, the Session-Reflector MUST use the local p the reflected test packet. Finally, the Session-Reflector <bcp14>MUST</bcp14>
olicy to verify whether use the local policy to verify whether
the CoS corresponding to the value of the DSCP1 field is permitted in the doma the CoS corresponding to the value of the DSCP1 field is permitted in the doma
in. If it is, the Session-Reflectorset in. If it is, the Session-Reflector
MUST set the DSCP field's value in the IP header <bcp14>MUST</bcp14> set the DSCP field's value in the IP header
of the reflected test packet equal to the value of the DSCP1 field of the rece of the reflected test packet equal to the value of the DSCP1 field of the rece
ived test packet. Otherwise, the Session-Reflector MUST use ived test packet. Otherwise, the Session-Reflector <bcp14>MUST</bcp14> use
the DSCP value of the received STAMP packet and set the value of the RP field to 1. the DSCP value of the received STAMP packet and set the value of the RP field to 1.
Upon receiving the reflected packet, if the value of the RP field is 0, Upon receiving the reflected packet, if the value of the RP field is 0,
the Session-Sender will save the DSCP and ECN values for analysis of the CoS i n the reverse direction. the Session-Sender will save the DSCP and ECN values for analysis of the CoS i n the reverse direction.
If the value of the RP field in the received reflected packet is 1, only CoS i n the forward direction can be analyzed. If the value of the RP field in the received reflected packet is 1, only CoS i n the forward direction can be analyzed.
</t> </t>
<t> <t>
Re-mapping of CoS can be used to provide multiple services (e,g., 2G, 3G, LTE in Re-mapping of CoS can be used to provide multiple services (e.g., 2G, 3G, LTE in
mobile backhaul networks) mobile backhaul networks)
over the same network.&#160; But if it is misconfigured, then it is often diffic over the same network.&nbsp; But if it is misconfigured, then it is often diffic
ult to diagnose the root cause of ult to diagnose the root cause of
excessive packet drops of higher-level service while packet drops excessive packet drops of higher-level service while packet drops
for lower service packets are at a normal level.&#160; Using a CoS TLV in for lower service packets are at a normal level.&nbsp; Using a CoS TLV in
STAMP testing helps to troubleshoot the existing problem and also verify STAMP testing helps to troubleshoot the existing problem and also verify
whether DiffServ policies are processing CoS as required by the configuration. whether DiffServ policies are processing CoS as required by the configuration.
</t> </t>
</section>
</section> <section anchor="direct-measurement-section" numbered="true" toc="default"
>
<section anchor="direct-measurement-section" title="Direct Measurement TLV"> <name>Direct Measurement TLV</name>
<t> <t>
The Direct Measurement TLV enables collection of the number of in-profile pack ets, The Direct Measurement TLV enables collection of the number of in-profile pack ets,
i.e., packets that form a specific data flow, that had been transmitted and r eceived i.e., packets that form a specific data flow, that had been transmitted and re ceived
by the Session-Sender and Session-Reflector, respectively. The definition of " in-profile packet" is outside the by the Session-Sender and Session-Reflector, respectively. The definition of " in-profile packet" is outside the
scope of this document and is left to the test operators to determine. scope of this document and is left to the test operators to determine.
<figure align="left" anchor="direct-tlv-figuret" title=" Direct Measurem </t>
ent TLV"> <figure anchor="direct-tlv-figuret">
<artwork><![CDATA[ <name>Direct Measurement TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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| Direct Type | Length | |STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Tx counter (S_TxC) | | Session-Sender Tx counter (S_TxC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Reflector Rx counter (R_RxC) | | Session-Reflector Rx counter (R_RxC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Reflector Tx counter (R_TxC) | | Session-Reflector Tx counter (R_TxC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
where fields are defined as the following: <t>
<list style="symbols"> The fields are defined as follows:
<t>STAMP TLV Flags - is an eight-bit-long field. Its format is present </t>
ed in <xref target="tlv-flags-format"/>.</t> <dl spacing="normal" newline="false">
<t>Direct (Measurement) Type - is a one-octet-long field, value TBA5 all <dt>STAMP TLV Flags:</dt><dd>An eight-bit-long field. Its format is pr
ocated by IANA <xref target="iana-stamp-tlv-registry"/>.</t> esented in <xref target="tlv-flags-format" format="default"/>.</dd>
<t>Length - two-octet-long field equals the length of the Value field in <dt>Type:</dt><dd>A one-octet-long field. Value 5 has been allocated b
octets. The Length field value MUST equal 12 octets.</t> y IANA (<xref target="iana-stamp-tlv-registry" format="default"/>).</dd>
<t>Session-Sender Tx counter (S_TxC) is a four-octet-long field. The Ses <dt>Length:</dt><dd>A two-octet-long field equal to the length of the
sion-Sender MUST set its value equal to the number of the transmitted in-profile Value field in octets. The Length field value <bcp14>MUST</bcp14> equal 12 octet
packets.</t> s.</dd>
<t>Session-Reflector Rx counter (R_RxC) is a four-octet-long field. MUST <dt>Session-Sender Tx counter (S_TxC):</dt><dd>A four-octet-long field
be zeroed by the Session-Sender on transmit and . The Session-Sender <bcp14>MUST</bcp14> set its value equal to the number of th
ignored by the Session-Reflector on receipt. The Session-Reflector MUST f e transmitted in-profile packets.</dd>
ill it with the value of in-profile packets received.</t> <dt>Session-Reflector Rx counter (R_RxC):</dt><dd>A four-octet-long fi
<t>Session-Reflector Tx counter (R_TxC) is a four-octet-long field. MUST eld. It <bcp14>MUST</bcp14> be zeroed by the Session-Sender on transmit and
be zeroed by the Session-Sender and ignored by the Session-Reflector on receip ignored by the Session-Reflector on receipt. The Session-Reflector <bcp14
t. >MUST</bcp14> fill it with the value of in-profile packets received.</dd>
The Session-Reflector MUST fill it with the value of the transmitted in-p <dt>Session-Reflector Tx counter (R_TxC):</dt><dd>A four-octet-long fi
rofile packets.</t> eld. It <bcp14>MUST</bcp14> be zeroed by the Session-Sender and ignored by the S
</list> ession-Reflector on receipt.
</t> The Session-Reflector <bcp14>MUST</bcp14> fill it with the value of the t
<t> ransmitted in-profile packets.</dd>
A Session-Sender MAY include the Direct Measurement TLV in a STAMP test pack </dl>
et. <t>
If the received STAMP test packet includes the Direct Measurement TLV, the S A Session-Sender <bcp14>MAY</bcp14> include the Direct Measurement TLV in a
ession-Reflector MUST include it in the reflected test packet. STAMP test packet.
The Session-Reflector MUST copy the value from the S_TxC field of the receiv If the received STAMP test packet includes the Direct Measurement TLV, the S
ed test packet into the same field of the reflected packet before its transmissi ession-Reflector <bcp14>MUST</bcp14> include it in the reflected test packet.
on. The Session-Reflector <bcp14>MUST</bcp14> copy the value from the S_TxC fiel
</t> d of the received test packet into the same field of the reflected packet before
</section> its transmission.
</t>
<section anchor="access-avail-sec" title="Access Report TLV"> </section>
<t> <section anchor="access-avail-sec" numbered="true" toc="default">
A STAMP Session-Sender MAY include an Access Report TLV (<xref target="acces <name>Access Report TLV</name>
s-tlv-fig"/>) to indicate <t>
A STAMP Session-Sender <bcp14>MAY</bcp14> include an Access Report TLV (<xre
f target="access-tlv-fig" format="default"/>) to indicate
changes to the access network status to the Session-Reflector. The changes to the access network status to the Session-Reflector. The
definition of an access network is outside the scope of this document. definition of an access network is outside the scope of this document.
</t> </t>
<t> <figure anchor="access-tlv-fig">
<figure align="left" anchor="access-tlv-fig" title="Access Report TL <name>Access Report TLV</name>
V"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ 0 1 2 3
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 | Length |
|STAMP TLV Flags|Acc Report Type| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | Resv | Return Code | Reserved |
| ID | Resv | Return Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
where fields are defined as follows: <t>
<list style="symbols"> The fields are defined as follows:
<t>STAMP TLV Flags - is an eight-bit-long field. Its format presented
in <xref target="tlv-flags-format"/>.</t>
<t>Access Report Type - is a one-octet-long field, value TBA6 allocated
by IANA <xref target="iana-stamp-tlv-registry"/>.</t>
<t>Length - two-octet-long field, set equal to the value 4.</t>
<t>ID (Access ID) - four-bit-long field that identifies the access netwo
rk,
e.g., 3GPP (Radio Access Technologies specified by 3GPP) or Non-3GPP
(accesses that are not specified by 3GPP) <xref target="TS23501"/>.
The value is one of those listed below:
<list>
<t>1 - 3GPP Network</t>
<t>2 - Non-3GPP Network</t>
</list>
All other values are invalid and the TLV that contains it MUST be discarded
.</t>
<t>Resv - four-bit-long field, MUST be zeroed on transmission
and ignored on receipt.</t>
<t>Return Code - one-octet-long field that identifies the report signal,
e.g., available or unavailable. The value is supplied to the STAMP
end-point through some mechanism that is outside the scope of this document
.
The value is one of those listed in <xref target="iana-return-code-reg"/>.<
/t>
<t>Reserved - two-octet-long field, MUST be zeroed on transmission
and ignored on receipt.</t>
</list>
</t> </t>
<dl spacing="normal" newline="false">
<dt>STAMP TLV Flags:</dt><dd>An eight-bit-long field. Its format is pr
esented in <xref target="tlv-flags-format" format="default"/>.</dd>
<dt>Type:</dt><dd>A one-octet-long field. Value 6 has been allocated b
y IANA (<xref target="iana-stamp-tlv-registry" format="default"/>).</dd>
<dt>Length:</dt><dd>A two-octet-long field, set equal to the value 4.<
/dd>
<dt>ID (Access ID):</dt><dd><t>A four-bit-long field that identifies
the access network,
e.g., 3GPP (Radio Access Technologies specified by 3GPP) or non-3GPP
(accesses that are not specified by 3GPP) <xref target="TS23501" format="de
fault"/>.
The value is one of the following:</t>
<dl spacing="normal" newline="false">
<dt>1:</dt><dd>3GPP Network</dd>
<dt>2:</dt><dd>Non-3GPP Network</dd>
</dl>
<t>
All other values are invalid; a TLV that contains values other than '1' or
'2' <bcp14>MUST</bcp14> be discarded.</t>
</dd>
<dt>Resv:</dt><dd>A four-bit-long field that <bcp14>MUST</bcp14> be ze
roed on transmission
and ignored on receipt.</dd>
<dt>Return Code:</dt><dd>A one-octet-long field that identifies the re
port signal,
e.g., available or unavailable. The value is supplied to the STAMP
endpoint through some mechanism that is outside the scope of this document.
<xref target="iana-return-code-reg" format="default"/> lists the possible values
.</dd>
<dt>Reserved:</dt><dd>A two-octet-long field that <bcp14>MUST</bcp14>
be zeroed on transmission
and ignored on receipt.</dd>
</dl>
<t> <t>
The STAMP Session-Sender that includes the Access Report TLV sets The STAMP Session-Sender that includes the Access Report TLV sets
the value of the Access ID field according to the type of access network it r eports on. the value of the Access ID field according to the type of access network it r eports on.
Also, the Session-Sender sets the value of the Return Code field to reflect t he operational state of the Also, the Session-Sender sets the value of the Return Code field to reflect t he operational state of the
access network. The mechanism to determine the state of the access network is outside the scope access network. The mechanism to determine the state of the access network is outside the scope
of this specification. A STAMP Session-Reflector of this specification. A STAMP Session-Reflector
that received the test packet with the Access Report TLV MUST include that received the test packet with the Access Report TLV <bcp14>MUST</bcp14>
the Access Report TLV in the reflected test packet. The Session- include
Reflector MUST set the value of the Access ID and Return Code fields the Access Report TLV in the reflected test packet. The Session-Reflector <b
cp14>MUST</bcp14> set the value of the Access ID and Return Code fields
equal to the values of the corresponding fields from the test packet equal to the values of the corresponding fields from the test packet
it has received. it has received.
</t> </t>
<t> <t>
The Session-Sender MUST also arm a retransmission timer after sending The Session-Sender <bcp14>MUST</bcp14> also arm a retransmission timer after
a test packet that includes the Access Report TLV. This timer MUST sending
a test packet that includes the Access Report TLV. This timer <bcp14>MUST</b
cp14>
be disarmed upon reception of the reflected be disarmed upon reception of the reflected
STAMP test packet that includes the Access Report TLV. STAMP test packet that includes the Access Report TLV.
In the event the timer expires before such a packet In the event the timer expires before such a packet
is received, the Session-Sender MUST retransmit the STAMP test packet is received, the Session-Sender <bcp14>MUST</bcp14> retransmit the STAMP test
that contains the Access Report TLV. This retransmission SHOULD be packet
that contains the Access Report TLV. This retransmission <bcp14>SHOULD</bcp14
> be
repeated up to four times before the procedure is aborted. Setting the value repeated up to four times before the procedure is aborted. Setting the value
for the retransmission timer is based on local policies and network environme nt. for the retransmission timer is based on local policies and the network envir onment.
The default value of the retransmission timer for the Access Report TLV The default value of the retransmission timer for the Access Report TLV
SHOULD be three seconds. An implementation MUST provide control <bcp14>SHOULD</bcp14> be three seconds. An implementation <bcp14>MUST</bcp14> provide control
of the retransmission timer value and the number of retransmissions. of the retransmission timer value and the number of retransmissions.
</t> </t>
<t> <t>
The Access Report TLV is used by the Performance Measurement The Access Report TLV is used by the Performance Measurement
Function (PMF) components of the Access Steering, Switching and Function (PMF) components of the Access Steering, Switching, and
Splitting feature for 5G networks <xref target="TS23501"/>. The PMF Splitting feature for 5G networks <xref target="TS23501" format="default"/>.
The PMF
component in the User Equipment acts as the STAMP Session-Sender, component in the User Equipment acts as the STAMP Session-Sender,
and the PMF component in the User Plane Function and the PMF component in the User Plane Function
acts as the STAMP Session-Reflector. acts as the STAMP Session-Reflector.
</t> </t>
</section> </section>
<section anchor="follow-up-tlv" numbered="true" toc="default">
<section anchor="follow-up-tlv" title="Follow-up Telemetry TLV"> <name>Follow-Up Telemetry TLV</name>
<t> <t>
A Session-Reflector might be able to put in the Timestamp field only an "SW A Session-Reflector might be able to put only an "SW Local"
Local" (see <xref target="timestamp-method-new-tbl" format="default"/>) timestamp i
(see <xref target="timestamp-method-new-tbl"/>) timestamp. But the hosting n the Follow-Up Timestamp field. But the hosting
system might provide a timestamp closer to the start of the actual packet tr ansmission system might provide a timestamp closer to the start of the actual packet tr ansmission
even though it is not possible to deliver the information to the Session-Sen der in time for the packet itself. even though it is not possible to deliver the information to the Session-Sen der in time for the packet itself.
This timestamp might nevertheless be important for the Session-Sender, as it This timestamp might nevertheless be important for the Session-Sender, as it
improves the accuracy of measuring network delay by minimizing the impact of egress queuing delays improves the accuracy of network delay measurement by minimizing the impact of egress queuing delays
on the measurement. on the measurement.
</t> </t>
<t>
A STAMP Session-Sender MAY include the Follow-up Telemetry TLV to <t>
A STAMP Session-Sender <bcp14>MAY</bcp14> include the Follow-Up Telemetry TLV
to
request information from the Session-Reflector. The Session-Sender request information from the Session-Reflector. The Session-Sender
MUST set the Follow-up Telemetry Type and Length fields to their appropriate <bcp14>MUST</bcp14> set the Follow-Up Telemetry Type and Length fields to the
values. ir appropriate values.
The Sequence Number and Timestamp fields MUST be zeroed on transmission by th The Sequence Number and Follow-Up Timestamp fields <bcp14>MUST</bcp14> be zer
e Session-Sender oed on transmission by the Session-Sender
and ignored by the Session-Reflector upon receipt of the STAMP test packet th and ignored by the Session-Reflector upon receipt of the STAMP test packet th
at includes the Follow-up Telemetry TLV. at includes the Follow-Up Telemetry TLV.
The Session-Reflector MUST validate the Length value of the STAMP The Session-Reflector <bcp14>MUST</bcp14> validate the Length value of the ST
AMP
test packet. If the value of the Length field is invalid, the test packet. If the value of the Length field is invalid, the
Session-Reflector MUST zero the Sequence Number and Timestamp fields and set Session-Reflector <bcp14>MUST</bcp14> zero the Sequence Number and Follow-Up
the M flag in the STAMP TLV Flags field Timestamp fields and set the M flag in the STAMP TLV Flags field
in the reflected packet. If the Session-Reflector is in in the reflected packet. If the Session-Reflector is in the
stateless mode (defined in Section 4.2 <xref target="RFC8762"/>), stateless mode (defined in <xref target="RFC8762" sectionFormat="of" section=
it MUST zero the Sequence Number and Timestamp fields. "4.2"/>),
</t> it <bcp14>MUST</bcp14> zero the Sequence Number and Follow-Up Timestamp field
<t> s.
<figure align="left" anchor="follow-up-tlv-fig" title="Follow-up </t>
Telemetry TLV"> <figure anchor="follow-up-tlv-fig">
<artwork><![CDATA[ <name>Follow-Up Telemetry TLV</name>
0 1 2 3 <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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| Follow-up Type| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| Type | Length |
| Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |
| Follow-up Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Follow-Up Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| Timestamp M | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp M | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
where fields are defined as follows:
<list style="symbols">
<t>STAMP TLV Flags - is an eight-bit-long field. Its format presented
in <xref target="tlv-flags-format"/>.</t>
<t>Follow-up (Telemetry) Type - is a one-octet-long field, value TBA7 al
located by IANA <xref target="iana-stamp-tlv-registry"/>.</t>
<t>Length - two-octet-long field, set equal to the value 16 octets.</t>
<t> <t>
Sequence Number - four-octet-long field indicating the sequence The fields are defined as follows:
number of the last packet reflected in the same STAMP-test session. </t>
<dl spacing="normal">
<dt>STAMP TLV Flags:</dt><dd>An eight-bit-long field. Its format is pr
esented in <xref target="tlv-flags-format" format="default"/>.</dd>
<dt>Type:</dt><dd>A one-octet-long field. Value 7 has been allocated b
y IANA (<xref target="iana-stamp-tlv-registry" format="default"/>).</dd>
<dt>Length:</dt><dd>A two-octet-long field, set equal to the value 16
octets.</dd>
<dt>
Sequence Number:</dt><dd>A four-octet-long field indicating the sequence
number of the last packet reflected in the same STAMP test session.
Since the Session-Reflector runs in the stateful mode Since the Session-Reflector runs in the stateful mode
(defined in Section 4.2 <xref target="RFC8762"/>), (defined in <xref target="RFC8762" sectionFormat="of" section="4.2"/>),
it is the Session-Reflector&#8217;s Sequence Number of the previous reflected pa it is the Session-Reflector's Sequence Number of the previous reflected packet.
cket. </dd>
</t> <dt>
<t> Follow-Up Timestamp:</dt><dd>An eight-octet-long field, with the format ind
Follow-up Timestamp - eight-octet-long field, with the format indicated by icated by
the Z flag of the Error Estimate field of the STAMP base packet, which is contained the Z flag of the Error Estimate field of the STAMP base packet, which is contained
in this reflected test packet transmitted by a Session-Reflector, in this reflected test packet transmitted by a Session-Reflector,
as described in Section 4.2.1 <xref target="RFC8762"/>. as described in <xref target="RFC8762" sectionFormat="of" section="4.2.1"/ >.
It carries the timestamp when the reflected packet with the It carries the timestamp when the reflected packet with the
specified sequence number was sent. specified sequence number was sent.
</t> </dd>
<t> <dt>
Timestamp M(ode) - one-octet-long field that characterizes the Timestamp M(ode):</dt><dd>A one-octet-long field that characterizes the
method by which the entity that transmits a reflected STAMP packet obtained the method by which the entity that transmits a reflected STAMP packet obtained the
Follow-up Timestamp. Follow-Up Timestamp.
The value is one of those listed in <xref target="timestamp-method-new-tbl"/>. <xref target="timestamp-method-new-tbl" format="default"/> lists the possible va
</t> lues.
<t> Reserved - three-octet-long field. Its value MUST be zeroed on transmission </dd>
and ignored on receipt.</t> <dt>Reserved:</dt><dd>A three-octet-long field. Its value <bcp14>MUST<
</list> /bcp14> be zeroed on transmission and ignored on receipt.</dd>
</t> </dl>
</section>
</section> <section anchor="hmac-sec" numbered="true" toc="default">
<name>HMAC TLV</name>
<section anchor="hmac-sec" title="HMAC TLV"> <t>
<t>
The STAMP authenticated mode protects the integrity of data collected in the STA MP base packet. The STAMP authenticated mode protects the integrity of data collected in the STA MP base packet.
STAMP extensions are designed to provide valuable information about the conditio n of a network, STAMP extensions are designed to provide valuable information about the conditio n of a network,
and protecting the integrity of that data is also essential. and protecting the integrity of that data is also essential.
All authenticated STAMP base packets (per Section 4.2.2 and Section 4.3.2 <xref All authenticated STAMP base packets (per Sections <xref target="RFC8762"
target="RFC8762"/>) sectionFormat="bare" section="4.2.2"/> and <xref target="RFC8762"
compatible with this specification MUST additionally authenticate the sectionFormat="bare" section="4.3.2"/> of <xref target="RFC8762" format="default
option TLVs by including the keyed Hashed Message Authentication Code (HMAC) TLV "/>)
, with the sole exception of when compatible with this specification <bcp14>MUST</bcp14> additionally authenticate
there is only one TLV present, and it is the Extended Padding TLV. the
The HMAC TLV MUST follow all TLVs included in a STAMP test packet, except for th optional TLVs by including the keyed Hashed Message Authentication Code (HMAC) T
e Extra Padding TLV. LV, with the sole exception of when
there is only one TLV present and it is the Extended Padding TLV.
The HMAC TLV <bcp14>MUST</bcp14> follow all TLVs included in a STAMP test packet
except for the Extra Padding TLV.
If the HMAC TLV appears in any other position in a STAMP extended test packet, t hen the situation If the HMAC TLV appears in any other position in a STAMP extended test packet, t hen the situation
MUST be processed as HMAC verification failure, as defined in this section, furt <bcp14>MUST</bcp14> be processed as HMAC verification failure, as defined below
her below. in this section.
The HMAC TLV MAY be used to protect the integrity of STAMP extensions in STAMP u The HMAC TLV <bcp14>MAY</bcp14> be used to protect the integrity of STAMP extens
nauthenticated mode. ions in the STAMP unauthenticated mode.
An implementation of STAMP extensions MUST provide controls to enable An implementation of STAMP extensions <bcp14>MUST</bcp14> provide controls to en
the integrity protection of STAMP extensions in STAMP unauthenticated mode. able
the integrity protection of STAMP extensions in the STAMP unauthenticated mode.
</t> </t>
<t> <t>
<!-- </t>
<figure align="left" anchor="hmac-tlv-fig" title="HMAC TLV"> <figure anchor="hmac-tlv-fig">
<artwork><![CDATA[ <name>HMAC TLV</name>
0 1 2 3 <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ HMAC (Variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<figure align="left" anchor="hmac-tlv-fig" title="HMAC TLV">
<artwork><![CDATA[
0 1 2 3 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| HMAC Type | Length | |STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC | | HMAC |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
where fields are defined as follows: <t>
<list style="symbols"> The fields are defined as follows:
<t>STAMP TLV Flags - is an eight-bit-long field. Its format is present </t>
ed in <xref target="tlv-flags-format"/>.</t> <dl spacing="normal">
<t>HMAC Type - is a one-octet-long field, value TBA8 allocated by IANA < <dt>STAMP TLV Flags:</dt><dd>An eight-bit-long field. Its format is pr
xref target="iana-stamp-tlv-registry"/>.</t> esented in <xref target="tlv-flags-format" format="default"/>.</dd>
<t>Length - two-octet-long field, set equal to 16 octets.</t> <dt>Type:</dt><dd>A one-octet-long field. Value 8 has been allocated b
<t>HMAC - is a 16-octet-long field that carries HMAC digest of the text y IANA (<xref target="iana-stamp-tlv-registry" format="default"/>).</dd>
of all preceding TLVs.</t> <dt>Length:</dt><dd>A two-octet-long field, set equal to the value 16
</list> octets.</dd>
</t> <dt>HMAC:</dt><dd>A 16-octet-long field that carries the HMAC digest o
f the text of all preceding TLVs.</dd>
<t> </dl>
As defined in <xref target="RFC8762"/>, STAMP uses HMAC-SHA-256 truncated to 128 <t>
bits (<xref target="RFC4868"/>). As defined in <xref target="RFC8762" format="default"/>, STAMP uses HMAC-SHA-256
All considerations regarding using the key listed in Section 4.4 of <xref target truncated to 128 bits (see <xref target="RFC4868" format="default"/>).
="RFC8762"/> All considerations regarding using the key listed in <xref target="RFC8762" sect
ionFormat="of" section="4.4"/>
are fully applicable to the use of the HMAC TLV. Key management and the mechanis ms to are fully applicable to the use of the HMAC TLV. Key management and the mechanis ms to
distribute the HMAC key are outside the scope of this specification. distribute the HMAC key are outside the scope of this specification.
HMAC TLV is anticipated to track updates in the base STAMP protocol <xref target The HMAC TLV is anticipated to track updates in the base STAMP protocol <xref ta
="RFC8762"/>, rget="RFC8762" format="default"/>,
including the use of more advanced cryptographic algorithms. HMAC is calculated including the use of more advanced cryptographic algorithms. HMAC is calculated
as defined in <xref target="RFC2104"/> as defined in <xref target="RFC2104" format="default"/>
over text as the concatenation of the Sequence Number field of the base STAMP pa cket and over text as the concatenation of the Sequence Number field of the base STAMP pa cket and
all preceding TLVs. The digest then MUST be truncated to 128 bits and written i nto the HMAC field. all preceding TLVs. The digest then <bcp14>MUST</bcp14> be truncated to 128 bit s and written into the HMAC field.
If the HMAC TLV is present in the extended STAMP test packet, e.g., in the authe nticated mode, If the HMAC TLV is present in the extended STAMP test packet, e.g., in the authe nticated mode,
HMAC MUST be verified before using any data in the included STAMP TLVs. If HMAC HMAC <bcp14>MUST</bcp14> be verified before using any data in the included STAMP
verification TLVs. If HMAC verification
by the Session-Reflector fails, then the Session-Reflector MUST stop processing by the Session-Reflector fails, then the Session-Reflector <bcp14>MUST</bcp14> s
the received extended STAMP test packet. top processing the received extended STAMP test packet.
The Session-Reflector MUST copy the TLVs from the received STAMP test packet in The Session-Reflector <bcp14>MUST</bcp14> copy the TLVs from the received STAMP
to the test packet into the
reflected packet. The Session-Reflector MUST set the I flag in each TLV copied o reflected packet. The Session-Reflector <bcp14>MUST</bcp14> set the I flag in ea
ver into ch TLV copied over into
the reflected packet to 1 before transmitting the reflected test packet. the reflected packet to 1 before transmitting the reflected test packet.
If the Session-Sender receives the extended STAMP test packet with I flag set to 1, If the Session-Sender receives the extended STAMP test packet with I flag set to 1,
then the Session-Sender MUST stop processing TLVs in the reflected test packet. then the Session-Sender <bcp14>MUST</bcp14> stop processing TLVs in the reflecte
If HMAC verification by the Session-Sender fails, then the Session-Sender MUST d test packet.
If HMAC verification by the Session-Sender fails, then the Session-Sender <bcp14
>MUST</bcp14>
stop processing TLVs in the reflected extended STAMP packet. stop processing TLVs in the reflected extended STAMP packet.
<!--
The Session-Sender MUST notify an operator of the failed HMAC verification.
Also, both the Session-Sender and Session-Reflector MAY log the notification tha
t
HMAC verification of STAMP TLVs failed. Note that the system MUST control the ra
te of logging.
</t> </t>
</section>
</section> </section>
<section anchor="iana-consider" numbered="true" toc="default">
</section> <name>IANA Considerations</name>
<t>IANA has created the following subregistries under the "Simple Two-way Active
<section anchor="iana-consider" title="IANA Considerations"> Measurement Protocol (STAMP) TLV Types" registry.</t>
<section anchor="iana-stamp-tlv-registry" numbered="true" toc="default">
<section anchor="iana-stamp-tlv-registry" title="STAMP TLV Registry"> <name>STAMP TLV Types Subregistry</name>
<t> <t>
IANA is requested to create the STAMP TLV Type registry. IANA has created the "STAMP TLV Types" subregistry. The code
All code points in the range 1 through 175 in this registry shall be allocat points in this registry are allocated according to the registration
ed procedures <xref target="RFC8126" format="default"/> described in <xref
according to the "IETF Review" procedure as specified in <xref target="RFC81 target="iana-stamp-type-tbl" format="default"/>.
26"/>. </t>
Code points in the range <table anchor="iana-stamp-type-tbl" align="center">
176 through 239 in this registry shall be allocated according to the "First <name>Registration Procedures for the STAMP TLV Types Subregistry</nam
Come First Served" procedure as e>
specified in <xref target="RFC8126"/>. <thead>
The remaining code points are allocated according to <xref target="iana <tr>
-stamp-type-tbl"/>: <th align="left">Range</th>
</t> <th align="center">Registration Procedures</th>
<texttable anchor="iana-stamp-type-tbl" title="STAMP TLV Type Registry"> </tr>
<ttcol align="left">Value</ttcol> </thead>
<ttcol align="center">Description</ttcol> <tbody>
<ttcol align="left">Reference</ttcol> <tr>
<c>0</c> <td align="left">1 - 175</td>
<c>Reserved</c> <td align="center">IETF Review</td>
<c>This document</c> </tr>
<c>1- 175</c> <tr>
<c>Unassigned</c> <td align="left">176 - 239</td>
<c>This document</c> <td align="center">First Come First Served</td>
<c>176 - 239</c> </tr>
<c>Unassigned</c> <tr>
<c>This document</c> <td align="left">240 - 251</td>
<c>240 - 251</c> <td align="center">Experimental Use</td>
<c>Experimental</c> </tr>
<c>This document</c> <tr>
<c>252 - 254</c> <td align="left">252 - 254</td>
<c>Private Use</c> <td align="center">Private Use</td>
<c>This document</c> </tr>
<c>255</c> </tbody>
<c>Reserved</c> </table>
<c>This document</c> <t>Per this document, IANA has allocated the following values in the "ST
</texttable> AMP TLV Types" subregistry:
</t>
<t>This document defines the following new values in the IETF Review range of th
e STAMP TLV Type registry:</t>
<texttable anchor="stamp-new-type-tbl" title="STAMP TLV Types">
<ttcol align="left">Value</ttcol>
<ttcol align="center">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>TBA1</c>
<c>Extra Padding</c>
<c>This&nbsp;document</c>
<c>TBA2</c>
<c>Location</c>
<c>This&nbsp;document</c>
<c>TBA3</c>
<c>Timestamp&nbsp;Information</c>
<c>This&nbsp;document</c>
<c>TBA4</c>
<c>Class of&nbsp;Service</c>
<c>This&nbsp;document</c>
<c>TBA5</c>
<c>Direct&nbsp;Measurement</c>
<c>This&nbsp;document</c>
<c>TBA6</c>
<c>Access&nbsp;Report</c>
<c>This&nbsp;document</c>
<c>TBA7</c>
<c>Follow-up&nbsp;Telemetry</c>
<c>This&nbsp;document</c>
<c>TBA8</c>
<c>HMAC</c>
<c>This&nbsp;document</c>
</texttable>
</section>
<section anchor="iana-tlv-flags-reg" title="STAMP TLV Flags Sub-registry">
<t>
IANA is requested to create the STAMP TLV Flags sub-registry as part of th
e STAMP TLV Type registry.
The registration procedure is "IETF Review" <xref target="RFC8126"/>. Flag
s are 8 bits.
This document defines the following bit positions in the STAMP TLV Flags s
ub-registry:
</t>
<texttable anchor="tlv-flags-new-tbl" title="STAMP TLV Flags">
<ttcol align="center">Bit position</ttcol>
<ttcol align="center">Symbol</ttcol>
<ttcol align="center">Description</ttcol>
<ttcol align="center">Reference</ttcol>
<c>0</c>
<c>U</c>
<c>Unrecognized TLV</c>
<c>This&nbsp;document</c>
<c>1</c>
<c>M</c>
<c>Malformed TLV</c>
<c>This&nbsp;document</c>
<c>2</c>
<c>I</c>
<c>Integrity check failed</c>
<c>This&nbsp;document</c>
</texttable>
</section>
<section anchor="iana-sub-tlv-registry" title="Sub-TLV Type Sub-regist
ry">
<t>
IANA is requested to create the sub-TLV Type sub-registry as part of the STAM
P TLV Type registry.
All code points in the range 1 through 175 in this registry shall be allocat
ed
according to the "IETF Review" procedure as specified in <xref target="RFC81
26"/>.
Code points in the range
176 through 239 in this registry shall be allocated according to the "First
Come First Served" procedure as
specified in <xref target="RFC8126"/>.
The remaining code points are allocated according to <xref target="iana
-sub-type-tbl"/>:
</t>
<texttable anchor="iana-sub-type-tbl" title="Location Sub-TLV Type Sub-re
gistry">
<ttcol align="left">Value</ttcol>
<ttcol align="center">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>0</c>
<c>Reserved</c>
<c>This document</c>
<c>1- 175</c>
<c>Unassigned</c>
<c>This document</c>
<c>176 - 239</c>
<c>Unassigned</c>
<c>This document</c>
<c>240 - 251</c>
<c>Experimental</c>
<c>This document</c>
<c>252 - 254</c>
<c>Private Use</c>
<c>This document</c>
<c>255</c>
<c>Reserved</c>
<c>This document</c>
</texttable>
<t>This document defines the following new values in the IETF Review range of th
e Location sub-TLV Type sub-registry:</t>
<texttable anchor="sub-tlv-type-tbl" title="STAMP sub-TLV Types">
<ttcol align="left">Value</ttcol>
<ttcol align="center">Description</ttcol>
<ttcol align="left">TLV Used</ttcol>
<ttcol align="left">Reference</ttcol>
<c>TBA9</c>
<c>Source MAC Address</c>
<c>Location</c>
<c>This&nbsp;document</c>
<c>TBA10</c>
<c>Source EUI-48 Address</c>
<c>Location</c>
<c>This&nbsp;document</c>
<c>TBA11</c>
<c>Source EUI-64 Address</c>
<c>Location</c>
<c>This&nbsp;document</c>
<c>TBA12</c>
<c>Destination IP Address</c>
<c>Location</c>
<c>This&nbsp;document</c>
<c>TBA13</c>
<c>Destination IPv4 Address</c>
<c>Location</c>
<c>This&nbsp;document</c>
<c>TBA14</c>
<c>Destination IPv6 Address</c>
<c>Location</c>
<c>This&nbsp;document</c>
<c>TBA15</c>
<c>Source&nbsp;IP Address</c>
<c>Location</c>
<c>This&nbsp;document</c>
<c>TBA16</c>
<c>Source&nbsp;IPv4 Address</c>
<c>Location</c>
<c>This&nbsp;document</c>
<c>TBA17</c>
<c>Source&nbsp;IPv6 Address</c>
<c>Location</c>
<c>This&nbsp;document</c>
</texttable>
</section>
<section anchor="iana-sync-source-reg" title="Synchronization Source Sub-re
gistry">
<t>
IANA is requested to create the Synchronization Source sub-registry as part o
f the STAMP TLV Type registry.
All code points in the range 1 through 127 in this registry shall be allocat
ed
according to the "IETF Review" procedure as specified in <xref target="RFC81
26"/>.
Code points in the range
128 through 239 in this registry shall be allocated according to the "First
Come First Served" procedure as
specified in <xref target="RFC8126"/>.
Remaining code points are allocated according to <xref target="iana-syn
c-source-tbl"/>:
</t>
<texttable anchor="iana-sync-source-tbl" title="Synchronization Source Su
b-registry">
<ttcol align="left">Value</ttcol>
<ttcol align="center">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>0</c>
<c>Reserved</c>
<c>This document</c>
<c>1- 127</c>
<c>Unassigned</c>
<c>This document</c>
<c>128 - 239</c>
<c>Unassigned</c>
<c>This document</c>
<c>240 - 249</c>
<c>Experimental</c>
<c>This document</c>
<c>250 - 254</c>
<c>Private Use</c>
<c>This document</c>
<c>255</c>
<c>Reserved</c>
<c>This document</c>
</texttable>
<t> This document defines the following new values in the Synchronization So
urce sub-registry:</t>
<texttable anchor="ssync-source-new-tbl" title="Synchronization Sources">
<ttcol align="left">Value</ttcol>
<ttcol align="center">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>1</c>
<c>NTP</c>
<c>This&nbsp;document</c>
<c>2</c>
<c>PTP</c>
<c>This&nbsp;document</c>
<c>3</c>
<c>SSU/BITS</c>
<c>This&nbsp;document</c>
<c>4</c>
<c>GPS/GLONASS/LORAN-C/BDS/Galileo</c>
<c>This&nbsp;document</c>
<c>5</c>
<c>Local free-running</c>
<c>This&nbsp;document</c>
</texttable>
</section>
<section anchor="iana-tiemstamp-methog-reg" title="Timestamping Method Sub-
registry">
<t>
IANA is requested to create the Timestamping Method sub-registry as part of t
he STAMP TLV Type registry.
All code points in the range 1 through 127 in this registry shall be allocat
ed
according to the "IETF Review" procedure as specified in <xref target="RFC81
26"/>.
Code points in the range
128 through 239 in this registry shall be allocated according to the "First
Come First Served" procedure as
specified in <xref target="RFC8126"/>.
Remaining code points are allocated according to <xref target="iana-tim
estamp-method-tbl"/>:
</t>
<texttable anchor="iana-timestamp-method-tbl" title="Timestamping Method
Sub-registry">
<ttcol align="left">Value</ttcol>
<ttcol align="center">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>0</c>
<c>Reserved</c>
<c>This document</c>
<c>1- 127</c>
<c>Unassigned</c>
<c>This document</c>
<c>128 - 239</c>
<c>Unassigned</c>
<c>This document</c>
<c>240 - 249</c>
<c>Experimental</c>
<c>This document</c>
<c>250 - 254</c>
<c>Private Use</c>
<c>This document</c>
<c>255</c>
<c>Reserved</c>
<c>This document</c>
</texttable>
<t> This document defines the following new values in the Timestamping Metho
ds sub-registry:</t>
<texttable anchor="timestamp-method-new-tbl" title="Timestamping Methods">
<ttcol align="left">Value</ttcol>
<ttcol align="center">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>1</c>
<c>HW Assist</c>
<c>This&nbsp;document</c>
<c>2</c>
<c>SW local</c>
<c>This&nbsp;document</c>
<c>3</c>
<c>Control plane</c>
<c>This&nbsp;document</c>
</texttable>
</section>
<!-- <table anchor="stamp-new-type-tbl" align="center">
<section anchor="iana-access-report-reg" title="Access ID Sub-registry"> <name>STAMP TLV Types</name>
<t> <thead>
IANA is requested to create Access ID sub-registry as part of STAMP TLV Type <tr>
registry. <th align="left">Value</th>
All code points in the range 1 through 127 in this registry shall be allocat <th align="center">Description</th>
ed <th align="left">Reference</th>
according to the "IETF Review" procedure as specified in <xref target="RFC81 </tr>
26"/>. </thead>
Code points in the range <tbody>
128 through 239 in this registry shall be allocated according to the "First <tr>
Come First Served" procedure as <td align="left">0</td>
specified in <xref target="RFC8126"/>. <td align="center">Reserved</td>
Remaining code points are allocated according to <xref target="iana-acc <td align="left">RFC 8972</td>
ess-id-tbl"/>: </tr>
</t> <tr>
<texttable anchor="iana-access-id-tbl" title="Access ID Sub-registry"> <td align="left">1</td>
<ttcol align="left">Value</ttcol> <td align="center">Extra Padding</td>
<ttcol align="center">Description</ttcol> <td align="left">RFC 8972</td>
<ttcol align="left">Reference</ttcol> </tr>
<c>0</c> <tr>
<c>Reserved</c> <td align="left">2</td>
<c>This document</c> <td align="center">Location</td>
<c>1- 127</c> <td align="left">RFC 8972</td>
<c>Unassigned</c> </tr>
<c>IETF Review</c> <tr>
<c>128 - 239</c> <td align="left">3</td>
<c>Unassigned</c> <td align="center">Timestamp&nbsp;Information</td>
<c>First Come First Served</c> <td align="left">RFC 8972</td>
<c>240 - 249</c> </tr>
<c>Experimental</c> <tr>
<c>This document</c> <td align="left">4</td>
<c>250 - 254</c> <td align="center">Class of&nbsp;Service</td>
<c>Private Use</c> <td align="left">RFC 8972</td>
<c>This document</c> </tr>
<c>255</c> <tr>
<c>Reserved</c> <td align="left">5</td>
<c>This document</c> <td align="center">Direct&nbsp;Measurement</td>
</texttable> <td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">6</td>
<td align="center">Access&nbsp;Report</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">7</td>
<td align="center">Follow-Up&nbsp;Telemetry</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">8</td>
<td align="center">HMAC</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">255</td>
<td align="center">Reserved</td>
<td align="left">RFC 8972</td>
</tr>
</tbody>
</table>
</section>
<t> This document defines the following new values in the Access ID sub-regi <section anchor="iana-tlv-flags-reg" numbered="true" toc="default">
stry:</t> <name>STAMP TLV Flags Subregistry</name>
<texttable anchor="access-id-new-tbl" title="Access IDs"> <t>
<ttcol align="left">Value</ttcol> IANA has created the "STAMP TLV Flags" subregistry.
<ttcol align="center">Description</ttcol> The registration procedure is "IETF Review" <xref target="RFC8126" format=
<ttcol align="left">Reference</ttcol> "default"/>. The flags are 8 bits.
<c>1</c> Per this document, IANA has allocated the following bit positions in the "
<c>3GPP </c> STAMP TLV Flags" subregistry.
<c>This&nbsp;document</c> </t>
<c>2</c> <table anchor="tlv-flags-new-tbl" align="center">
<c>Non-3GPP</c> <name>STAMP TLV Flags</name>
<c>This&nbsp;document</c> <thead>
</texttable> <tr>
</section> <th align="center">Bit position</th>
<th align="center">Symbol</th>
<th align="center">Description</th>
<th align="center">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">0</td>
<td align="center">U</td>
<td align="center">Unrecognized TLV</td>
<td align="center">RFC 8972</td>
</tr>
<tr>
<td align="center">1</td>
<td align="center">M</td>
<td align="center">Malformed TLV</td>
<td align="center">RFC 8972</td>
</tr>
<tr>
<td align="center">2</td>
<td align="center">I</td>
<td align="center">Integrity check failed</td>
<td align="center">RFC 8972</td>
</tr>
</tbody>
</table>
</section>
<section anchor="iana-sub-tlv-registry" numbered="true" toc="default">
<name>STAMP Sub-TLV Types Subregistry</name>
<t>
IANA has created the "STAMP Sub-TLV Types" subregistry.
The code points in this registry are allocated according to the
registration procedures <xref target="RFC8126" format="default"/> described
in <xref target="iana-sub-type-tbl" format="default"/>.
</t>
<table anchor="iana-sub-type-tbl" align="center">
<name>Registration Procedures for the STAMP Sub-TLV Types Subregistry<
/name>
<thead>
<tr>
<th align="center">Range</th>
<th align="center">Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">1 - 175</td>
<td align="center">IETF Review</td>
</tr>
<tr>
<td align="left">176 - 239</td>
<td align="center">First Come First Served</td>
</tr>
<tr>
<td align="left">240 - 251</td>
<td align="center">Experimental Use</td>
</tr>
<tr>
<td align="left">252 - 254</td>
<td align="center">Private Use</td>
</tr>
</tbody>
</table>
<t>Per this document, IANA has allocated the following values in the "ST
AMP Sub-TLV Types" subregistry:</t>
<table anchor="sub-tlv-type-tbl" align="center">
<name>STAMP Sub-TLV Types</name>
<thead>
<tr>
<th align="center">Value</th>
<th align="center">Description</th>
<th align="left">TLV Used</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0</td>
<td align="center">Reserved</td>
<td></td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">1</td>
<td align="center">Source MAC Address</td>
<td align="left">Location</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">2</td>
<td align="center">Source EUI-48 Address</td>
<td align="left">Location</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">3</td>
<td align="center">Source EUI-64 Address</td>
<td align="left">Location</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">4</td>
<td align="center">Destination IP Address</td>
<td align="left">Location</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">5</td>
<td align="center">Destination IPv4 Address</td>
<td align="left">Location</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">6</td>
<td align="center">Destination IPv6 Address</td>
<td align="left">Location</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">7</td>
<td align="center">Source&nbsp;IP Address</td>
<td align="left">Location</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">8</td>
<td align="center">Source&nbsp;IPv4 Address</td>
<td align="left">Location</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">9</td>
<td align="center">Source&nbsp;IPv6 Address</td>
<td align="left">Location</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">255</td>
<td align="center">Reserved</td>
<td></td>
<td align="left">RFC 8972</td>
</tr>
</tbody>
</table>
</section>
<section anchor="iana-sync-source-reg" numbered="true" toc="default">
<name>STAMP Synchronization Sources Subregistry</name>
<t>
IANA has created the "STAMP Synchronization Sources" subregistry.
The code points in this registry are allocated according
to the registration procedures
<xref target="RFC8126" format="default"/> described in
<xref target="iana-sync-source-tbl" format="default"/>.
</t>
<table anchor="iana-sync-source-tbl" align="center">
<name>Registration Procedures for the STAMP Synchronization Sources Su
bregistry</name>
<thead>
<tr>
<th align="left">Range</th>
<th align="center">Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">1 - 127</td>
<td align="center">IETF Review</td>
</tr>
<tr>
<td align="left">128 - 239</td>
<td align="center">First Come First Served</td>
</tr>
<tr>
<td align="left">240 - 249</td>
<td align="center">Experimental Use</td>
</tr>
<tr>
<td align="left">250 - 254</td>
<td align="center">Private Use</td>
</tr>
</tbody>
</table>
<t>Per this document, IANA has allocated the following values in the "ST
AMP Synchronization Sources" subregistry:
</t>
<table anchor="ssync-source-new-tbl" align="center">
<name>STAMP Synchronization Sources</name>
<thead>
<tr>
<th align="left">Value</th>
<th align="center">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0</td>
<td align="center">Reserved</td>
<td align="left">RFC 8972</td>
</tr>
<section anchor="iana-return-code-reg" title="Return Code Sub-registry"> <tr>
<t> <td align="left">1</td>
IANA is requested to create the Return Code sub-registry as part of the STAMP <td align="center">NTP</td>
TLV Type registry. <td align="left">RFC 8972</td>
All code points in the range 1 through 127 in this registry shall be allocat </tr>
ed <tr>
according to the "IETF Review" procedure as specified in <xref target="RFC81 <td align="left">2</td>
26"/>. <td align="center">PTP</td>
Code points in the range <td align="left">RFC 8972</td>
128 through 239 in this registry shall be allocated according to the "First </tr>
Come First Served" procedure as <tr>
specified in <xref target="RFC8126"/>. <td align="left">3</td>
Remaining code points are allocated according to <xref target="iana-ret <td align="center">SSU/BITS</td>
urn-code-tbl"/>: <td align="left">RFC 8972</td>
</t> </tr>
<texttable anchor="iana-return-code-tbl" title="Return Code Sub-registry" <tr>
> <td align="left">4</td>
<ttcol align="left">Value</ttcol> <td align="center">GPS/GLONASS/LORAN-C/BDS/Galileo</td>
<ttcol align="center">Description</ttcol> <td align="left">RFC 8972</td>
<ttcol align="left">Reference</ttcol> </tr>
<c>0</c> <tr>
<c>Reserved</c> <td align="left">5</td>
<c>This document</c> <td align="center">Local free-running</td>
<c>1- 127</c> <td align="left">RFC 8972</td>
<c>Unassigned</c> </tr>
<c>This document</c> <tr>
<c>128 - 239</c> <td align="left">255</td>
<c>Unassigned</c> <td align="center">Reserved</td>
<c>This document</c> <td align="left">RFC 8972</td>
<c>240 - 249</c> </tr>
<c>Experimental</c>
<c>This document</c>
<c>250 - 254</c>
<c>Private Use</c>
<c>This document</c>
<c>255</c>
<c>Reserved</c>
<c>This document</c>
</texttable>
<t> This document defines the following new values in the Return Code sub-re </tbody>
gistry:</t> </table>
<texttable anchor="return-code-new-tbl" title="Return Codes"> </section>
<ttcol align="left">Value</ttcol> <section anchor="iana-tiemstamp-methog-reg" numbered="true" toc="default">
<ttcol align="center">Description</ttcol> <name>STAMP Timestamping Methods Subregistry</name>
<ttcol align="left">Reference</ttcol> <t>
<c>1</c> IANA has created the "STAMP Timestamping Methods" subregistry.
<c>Network&nbsp;available</c> The code points in this registry are allocated
<c>This&nbsp;document</c> according to the registration procedures
<c>2</c> <xref target="RFC8126" format="default"/>
<c>Network&nbsp;unavailable</c> described in
<c>This&nbsp;document</c> <xref target="iana-timestamp-method-tbl" format="default"/>.
</texttable> </t>
</section> <table anchor="iana-timestamp-method-tbl" align="center">
<name>Registration Procedures for the STAMP Timestamping Methods Subre
gistry</name>
<thead>
<tr>
<th align="left">Range</th>
<th align="center">Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">1 - 127</td>
<td align="center">IETF Review</td>
</tr>
<tr>
<td align="left">128 - 239</td>
<td align="center">First Come First Served</td>
</tr>
<tr>
<td align="left">240 - 249</td>
<td align="center">Experimental Use</td>
</tr>
<tr>
<td align="left">250 - 254</td>
<td align="center">Private Use</td>
</tr>
</tbody>
</table>
<t>Per this document, IANA has allocated the following values in the "ST
AMP Timestamping Methods" subregistry:</t>
<table anchor="timestamp-method-new-tbl" align="center">
<name>STAMP Timestamping Methods</name>
<thead>
<tr>
<th align="left">Value</th>
<th align="center">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0</td>
<td align="center">Reserved</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">1</td>
<td align="center">HW Assist</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">2</td>
<td align="center">SW Local</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">3</td>
<td align="center">Control Plane</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">255</td>
<td align="center">Reserved</td>
<td align="left">RFC 8972</td>
</tr>
</tbody>
</table>
</section>
<section anchor="iana-return-code-reg" numbered="true" toc="default">
<name>STAMP Return Codes Subregistry</name>
<t>
IANA has created the "STAMP Return Codes" subregistry.
The code points in this registry are allocated
according to the registration procedures <xref target="RFC8126" format="defau
lt"/> described in
<xref target="iana-return-code-tbl" format="default"/>.
</t>
<table anchor="iana-return-code-tbl" align="center">
<name>Registration Procedures for the STAMP Return Codes Subregistry</
name>
<thead>
<tr>
<th align="left">Range</th>
<th align="center">Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">1 - 127</td>
<td align="center">IETF Review</td>
</tr>
<tr>
<td align="left">128 - 239</td>
<td align="center">First Come First Served</td>
</tr>
<tr>
<td align="left">240 - 249</td>
<td align="center">Experimental Use</td>
</tr>
<tr>
<td align="left">250 - 254</td>
<td align="center">Private Use</td>
</tr>
</tbody>
</table>
<t>Per this document, IANA has allocated the following values in the "ST
AMP Return Codes" subregistry:</t>
<table anchor="return-code-new-tbl" align="center">
<name>STAMP Return Codes</name>
<thead>
<tr>
<th align="left">Value</th>
<th align="center">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0</td>
<td align="center">Reserved</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">1</td>
<td align="center">Network&nbsp;available</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">2</td>
<td align="center">Network&nbsp;unavailable</td>
<td align="left">RFC 8972</td>
</tr>
<tr>
<td align="left">255</td>
<td align="center">Reserved</td>
<td align="left">RFC 8972</td>
</tr>
</tbody>
</table>
</section>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section anchor="security" title="Security Considerations"> <name>Security Considerations</name>
<t> <t>
This document defines extensions to STAMP <xref target="RFC8762"/> and inherits This document defines extensions to STAMP <xref target="RFC8762" format="default
all the security considerations "/> and inherits all the security considerations
applicable to the base protocol. Additionally, the HMAC TLV is defined in this d ocument. applicable to the base protocol. Additionally, the HMAC TLV is defined in this d ocument.
Though the HMAC TLV protects the integrity of STAMP extensions; it does not prot Though the HMAC TLV protects the integrity of STAMP extensions, it does not prot
ect against a replay attack. ect against a replay attack.
The use of HMAC TLV is discussed in detail in <xref target="hmac-sec"/>. The use of the HMAC TLV is discussed in detail in <xref target="hmac-sec" format
</t> ="default"/>.
<t> </t>
To protect against a malformed TLV an implementation of a Session-Sender an <t>
d Session-Reflector MUST: To protect against a malformed TLV, an implementation of a Session-Sender a
<list style="symbols"> nd Session-Reflector <bcp14>MUST</bcp14>:
<t>check the setting of the M flag;</t> </t>
<t>validate the Length field value.</t> <ul spacing="normal">
</list> <li>check the setting of the M flag and</li>
</t> <li>validate the Length field value.</li>
<t> </ul>
As this specification defined the mechanism to test DSCP mapping, <t>
this document inherits all the security considerations discussed in <xref tar As this specification defines the mechanism to test DSCP mapping,
get="RFC2474"/>. this document inherits all the security considerations discussed in <xref tar
get="RFC2474" format="default"/>.
Monitoring and optional control of DSCP using the CoS TLV may be used across the Internet so that Monitoring and optional control of DSCP using the CoS TLV may be used across the Internet so that
the Session-Sender and the Session-Reflector are located in domains that us e different CoS profiles. Thus, the Session-Sender and the Session-Reflector are located in domains that us e different CoS profiles. Thus,
it is essential that an operator verifies the set of CoS values that are us it is essential that an operator verify the set of CoS values that is used
ed in the Session-Reflector's domain. in the Session-Reflector's domain.
Also, an implementation of a Session-Reflector SHOULD support a local polic Also, an implementation of a Session-Reflector <bcp14>SHOULD</bcp14> suppor
y to confirm whether the value sent by the Session-Sender t a local policy to confirm whether the value sent by the Session-Sender
can be used as the value of the DSCP field. <xref target="cos-info-section" can be used as the value of the DSCP field. <xref target="cos-info-section"
/> defines the use of that local policy. format="default"/> defines the use of that local policy.
</t> </t>
</section>
</section>
<section title="Acknowledgments">
<t>
Authors much appreciate the thorough review and thoughtful comments rec
eived from
Tianran Zhou, Rakesh Gandhi, Yuezhong Song and Yali Wang.
The authors express their gratitude to Al Morton for his comments and t
he most valuable suggestions.
The authors greatly appreciate comments and thoughtful suggestions rece
ived from Martin Duke.
</t>
</section>
<section title="Contributors">
<t>
The following people contributed text to this document:
<figure align="left">
<artwork><![CDATA[
Guo Jun
ZTE Corporation
68# Zijinghua Road
Nanjing, Jiangsu 210012
P.R.China
Phone: +86 18105183663
Email: guo.jun2@zte.com.cn
]]></artwork>
</figure>
</t>
</section>
</middle> </middle>
<back>
<back> <displayreference target="I-D.irtf-pearg-numeric-ids-generation" to="NUM-IDS-GEN
<references title="Normative References"> "/>
<?rfc include="reference.RFC.2119"?> <references>
<?rfc include="reference.RFC.8174"?> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8762.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2104.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5905.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4868.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2474.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5357.xml"/>
<?rfc include="reference.RFC.8126"?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .irtf-pearg-numeric-ids-generation-06.xml"/>
<?rfc include="reference.RFC.8762"?> <reference anchor="IEEE.1588.2008">
<front>
<title>IEEE Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems</title>
<author>
<organization/>
</author>
<date month="July" year="2008"/>
</front>
<seriesInfo name="IEEE Std." value="1588-2008"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2008.4579760"/>
</reference>
<?rfc include="reference.RFC.2104"?> <reference anchor="TS23501">
<front>
<title>Technical
Specification Group Services and System Aspects; System
Architecture for the 5G System (5GS); Stage 2 (Release 16)</title>
<author>
<organization>3GPP</organization>
</author>
<date year="2019"/>
</front>
<seriesInfo name="3GPP TS" value="23.501"/>
</reference>
<reference anchor="GPS">
<front>
<title>Global Positioning System (GPS) Standard Positioning Service
(SPS) Performance Standard</title>
<author>
<organization/>
</author>
<date month="April" year="2020"/>
</front>
<seriesInfo name="GPS SPS" value="5th Edition"/>
</reference>
</references>
</references> </references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
The authors very much appreciate the thorough review and thoughtful com
ments received from <contact fullname="Tianran Zhou"/>, <contact fullname="Rakes
h Gandhi"/>, <contact fullname="Yuezhong Song"/>, and <contact fullname="Yali Wa
ng"/>.
The authors express their gratitude to <contact fullname="Al Morton"/>
for his comments and valuable suggestions.
The authors greatly appreciate the comments and thoughtful suggestions
received from <contact fullname="Martin Duke"/>.
</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<t>
The following individual contributed text to this document:
</t>
<contact fullname="Guo Jun">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>68# Zijinghua Road</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<phone>+86 18105183663</phone>
<email>guo.jun2@zte.com.cn</email>
</address>
</contact>
</section>
</back>
<references title="Informative References"> </rfc>
<?rfc include="reference.RFC.5905"?>
<?rfc include="reference.RFC.4868"?>
<?rfc include="reference.RFC.2474"?>
<?rfc include="reference.RFC.5357"?>
<?rfc include="reference.I-D.gont-numeric-ids-generation"?>
<reference anchor="IEEE.1588.2008">
<front>
<title>Standard for a Precision Clock Synchronization Protocol for Networked Mea
surement and Control Systems</title>
<author>
<organization/>
</author>
<date month="March" year="2008"/>
</front>
<seriesInfo name="IEEE" value="Standard 1588"/>
</reference>
<reference anchor="TS23501">
<front>
<title>Technical Specification Group Services and System Aspects; System Archite
cture for the 5G System; Stage 2 (Release 16)</title>
<author>
<organization>3GPP (3rd Generation Partnership Project)</organization>
</author>
<date year="2019"/>
</front>
<seriesInfo name="3GPP" value="TS23501"/>
</reference>
<reference anchor="GPS">
<front>
<title>Global Positioning System (GPS) Standard Positioning Service (SPS) Perfor
mance Standard</title>
<author>
<organization/>
</author>
<date month="April" year="2020"/>
</front>
<seriesInfo name="GPS SPS" value="5th Edition"/>
</reference>
</references>
</back>
</rfc>
 End of changes. 153 change blocks. 
1379 lines changed or deleted 1535 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/