RFC 8972
Simple Two-Way Active Measurement Protocol Optional Extensions
RFC 8972: Simple Two-Way Active Measurement Protocol Optional Extensions 🎀
okay bestie, so this one is the optional extensions pack for STAMP (the Simple Two-way Active Measurement Protocol) 🦋 it was published in January 2021 as a Standards Track document, which means it's a real, officially approved Internet standard, not just a suggestion 💅 it's the IETF's official stamp of approval ✨
Authors: G. Mirsky, X. Min (ZTE Corp.), H. Nydell (Accedian Networks), R. Foote (Nokia), A. Masputra (Apple Inc.), and E. Ruffini (OutSys). six authors, very collaborative, very iconic 🫶
Updates: RFC 8762 🌸 this doc adds a STAMP Test Session Identifier to the base STAMP spec, so it's officially an update to that one
Obsoletes: nothing! this one doesn't replace any older RFC 🙌
The ISSN is 2070-1721 and the date is January 2021 📅 this is part 1 of 8, so there's more to come, stay tuned bestie 💖
Abstract
okay so the abstract is the quick pitch 🎤 this document describes optional extensions to STAMP that let you measure performance metrics ✨ it also defines a STAMP Test Session Identifier, which is what makes it an update to RFC 8762 💜
Status of This Memo
this section is the legal-ish bit that says what kind of doc this is 🙈 it's an Internet Standards Track document, and it's a product of the IETF 🌈 it represents consensus of the IETF community and got public review and was approved by the IESG (Internet Engineering Steering Group) 👑 more info on Internet Standards is in Section 2 of RFC 7841 💅
for the current status, errata, and feedback, check this link:
https://www.rfc-editor.org/info/rfc8972
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. 🧚
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at:
https://trustee.ietf.org/license-info
basically, read those carefully because they spell out your rights 🫶 and if you extract any Code Components from this document, they must include Simplified BSD License text (as described in Section 4.e of the Trust Legal Provisions) and they come with no warranty, as the Simplified BSD License says 🔥
Table of Contents
1. Introduction
2. Conventions Used in This Document
2.1. Acronyms
2.2. Requirements Language
3. STAMP Test Session Identifier
4. TLV Extensions to STAMP
4.1. Extra Padding TLV
4.2. Location TLV
4.2.1. Location Sub-TLVs
4.2.2. Theory of Operation of Location TLV
4.3. Timestamp Information TLV
4.4. Class of Service TLV
4.5. Direct Measurement TLV
4.6. Access Report TLV
4.7. Follow-Up Telemetry TLV
4.8. HMAC TLV
5. IANA Considerations
5.1. STAMP TLV Types Subregistry
5.2. STAMP TLV Flags Subregistry
5.3. STAMP Sub-TLV Types Subregistry
5.4. STAMP Synchronization Sources Subregistry
5.5. STAMP Timestamping Methods Subregistry
5.6. STAMP Return Codes Subregistry
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Contributors
Authors' Addresses1. Introduction ✨
1. Introduction
okay so the STAMP base spec ([RFC8762]) is the foundation 🧱 and this doc is all about the optional TLV-based extensions (TLV = Type-Length-Value encoding) 💖 they level up base STAMP functions like measuring one-way and round-trip delay, latency, packet loss, packet duplication, and out-of-order delivery of test packets 📦 this spec defines the extensions, their formats, and how they work 🦋 and it also defines a STAMP Test Session Identifier as an update to base STAMP [RFC8762] 🌸
2. Conventions Used in This Document 💅
2.1. Acronyms
here's the acronym cheat sheet, bestie 📝
BDS BeiDou Navigation Satellite System
BITS Building Integrated Timing Supply
CoS Class of Service
DSCP Differentiated Services Code Point
ECN Explicit Congestion Notification
GLONASS Global Orbiting Navigation Satellite System
GPS Global Positioning System [GPS]
HMAC Hashed Message Authentication Code
LORAN-C Long Range Navigation System Version C
MBZ Must Be Zero
NTP Network Time Protocol [RFC5905]
PMF Performance Measurement Function
PTP Precision Time Protocol [IEEE.1588.2008]
RP Reverse Path
SMI Structure of Management Information
SSID STAMP Session Identifier
SSU Synchronization Supply Unit
STAMP Simple Two-way Active Measurement Protocol
TLV Type-Length-Value2.2. Requirements Language
the key words are a whole vibe 🎀 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" mean what BCP 14 [RFC2119] [RFC8174] says they mean, but only when they show up in ALL CAPS like that 💜 otherwise they're just regular words, no cap 🙈
Part 1 of 8. More parts coming, bestie! 🦋
3. STAMP Test Session Identifier ✨
Okay bestie, so the STAMP Session-Sender is the one shooting test packets over to the STAMP Session-Reflector 💌. The Reflector catches each packet and acts based on its configuration plus any optional control info riding along in the Session-Sender's test packet 🎀. STAMP has two packet formats, one for Session-Sender packets and one for Session-Reflector packets. Same party, different outfits 💅. It also runs in two modes, unauthenticated and authenticated 🔐. And here's the lowkey iconic part: unauthenticated STAMP test packets are wire-compatible with unauthenticated TWAMP-Test [RFC5357] packets 🦋.
By default, STAMP goes symmetrical 🪞. The packet the Session-Reflector sends back is the same size as the one it received.
A STAMP Session is identified by a 4-tuple: the source and destination IP addresses, plus the source and destination UDP port numbers 🫶. A STAMP Session-Sender MAY generate a locally unique STAMP Session Identifier (SSID) 🆔. The SSID is a two-octet, non-zero unsigned integer. How you generate it is implementation specific. [NUM-IDS-GEN] thoroughly analyzes common ID generation algorithms and their vulnerabilities, so go read that if you're nerdy like me 🤓. For example, an implementation can use the algorithms described in Section 7.1 of [NUM-IDS-GEN].
Main character rule 👑: an implementation MUST NOT assign the same identifier to different STAMP test sessions. No dupes, periodt!
A Session-Sender MAY use the SSID to identify a STAMP test session. If the SSID is used, it MUST be present in each test packet of the given test session. In unauthenticated mode, the SSID lives right here, as shown in Figure 1 🧚:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | SSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| MBZ (28 octets) |
| |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Format of an Extended STAMP Session-Sender Test
Packet in Unauthenticated ModeAn implementation of the STAMP Session-Reflector that supports this specification MUST identify a STAMP Session using the SSID in combination with elements of the usual 4-tuple for the session. Before a test session starts, a Session-Reflector MUST be provisioned with all the elements that identify the STAMP Session. A STAMP Session-Reflector MUST discard non-matching STAMP test packets 🗑️. How you provision the STAMP Session identification is outside the scope of this specification, so that's a different chapter 📖. A conforming implementation of a STAMP Session-Reflector MUST copy the SSID value from the received test packet and put it into the reflected packet, as shown in Figure 2 💖:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | SSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ses-Sender TTL | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Format of an Extended STAMP Session-Reflector Test
Packet in Unauthenticated ModeA STAMP Session-Reflector that doesn't support this specification 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 implementation of a Session-Sender MUST support control of its behavior in such a scenario. If the test session is not stopped, the Session-Sender can, for example, send a base STAMP packet [RFC8762] or keep transmitting STAMP test packets with the SSID 🌈.
The SSID field in authenticated mode is in a different spot, as shown in Figures 3 and 4 🔥:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | SSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| MBZ (68 octets) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The Format of an Extended STAMP Session-Sender Test
Packet in Authenticated Mode
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | SSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ses-Sender TTL | |
+-+-+-+-+-+-+-+-+ +
| |
| MBZ (15 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Format of an Extended STAMP Session-Reflector Test
Packet in Authenticated Mode4. TLV Extensions to STAMP ✨
okay bestie, this is where STAMP gets its glow-up 💖 TLV (Type-Length-Value) is a flexible extension mechanism for optional info elements, and it's literally how you add new features without breaking everything 🎀 TLV is an optional field in the STAMP test packet. You MAY put multiple TLVs in one packet 🦋 You can also nest extra TLVs inside a TLV, but only if the semantics of the outer TLV allow it. Each TLV has a one-octet STAMP TLV Flags field, a one-octet Type field, and a two-octet Length field that equals the length of the Value field in octets. If a Type value (for a TLV or sub-TLV) is in the Private Use range [RFC8126], the length MUST be at least 4, and the first four octets MUST be that vendor's Structure of Management Information (SMI) Private Enterprise Code, as recorded in IANA's "SMI Network Management Private Enterprise Codes" subregistry, in network octet order. The rest of the Value field belongs to the vendor 💅 The next sections show how TLVs extend STAMP beyond its base spec 🌈
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| STAMP TLV Flags | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: TLV Format in a STAMP Extended Packet
The fields work like this 🫶
STAMP TLV Flags: an eight-bit field. The detailed format and interpretation of the flags defined in this spec are below.
Type: a one-octet field that characterizes how the Value field is interpreted. IANA allocates it, as specified in Section 5.1.
Length: a two-octet field equal to the length of the Value field in octets.
Value: a variable-length field. Its interpretation and encoding are determined by the value of the Type field.
All multi-byte fields in TLVs defined in this spec are in network byte order 🔥
The STAMP TLV Flags format is shown in Figure 6, and where the flags live is defined in Section 5.2 🌸
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+
| U | M | I | R | R | R | R | R |
+-+-+-+-+-+-+-+-+
Figure 6: STAMP TLV Flags Format
The fields are defined as follows:
U (Unrecognized): a one-bit flag. A Session-Sender MUST set the U flag to 1 before transmitting an extended STAMP test packet. A Session-Reflector MUST set the U flag to 1 if it has not understood the TLV. Otherwise, the Session-Reflector MUST set the U flag in the reflected packet to 0 🙈
M (Malformed): a one-bit flag. A Session-Sender MUST set the M flag to 0 before transmitting an extended STAMP test packet. A Session-Reflector MUST set the M flag to 1 if it determined the TLV is malformed, 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. Otherwise, the Session-Reflector MUST set the M flag in the reflected packet to 0 💀
I (Integrity): a one-bit flag. A Session-Sender MUST set the I flag to 0 before transmitting an extended STAMP test packet. A Session-Reflector MUST set the I flag to 1 if the STAMP extensions have failed HMAC verification (Section 4.8). Otherwise, the Session-Reflector MUST set the I flag in the reflected packet to 0 🔐
R: reserved flags for future use. These flags MUST be zeroed on transmit and ignored on receipt 🧚
Okay, the receiving part is important, so pay attention 👑 A STAMP node, whether it's a Session-Sender or a Session-Reflector, that receives a test packet MUST figure out whether it's a base STAMP packet or whether it includes one or more TLVs. The node MUST compare the value in the Length field of the UDP header with the length of the base STAMP test packet in the mode (unauthenticated or authenticated) based on the configuration of that STAMP test session. If the difference between those two values is greater than the length of the UDP header, the test packet includes one or more STAMP TLVs right after the base STAMP test packet. A Session-Reflector that doesn't support STAMP extensions will not process them but will copy them into the reflected packet, as defined in Section 4.3 of [RFC8762]. A Session-Reflector that supports TLVs will flag the specific TLVs it didn't process by setting the U flag to 1 in those TLVs 🦋
A STAMP Session-Sender that receives a reflected STAMP test packet with extension TLVs MUST validate each TLV, and here's how:
- If the U flag is set, the STAMP system MUST skip processing the TLV.
- If the M flag is set, the STAMP system MUST stop processing the rest of the extended STAMP packet.
- If the I flag is set, the STAMP system MUST discard all TLVs and MUST stop processing the rest of the extended STAMP packet.
- If an implementation of a Session-Reflector does not recognize the Type field value, it MUST include a copy of the TLV in the reflected STAMP packet. The Session-Reflector MUST set the U flag to 1. The Session-Reflector MUST skip processing the unrecognized TLV.
- If a TLV is malformed, processing of extension TLVs MUST be stopped. The Session-Reflector MUST copy the rest of the received extended STAMP packet into the reflected STAMP packet. The Session-Reflector MUST set the M flag to 1.
4.1. Extra Padding TLV
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| STAMP TLV Flags | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Extra Padding ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Extra Padding TLV
The fields are defined as follows:
STAMP TLV Flags: an eight-bit field. Its format is presented in Figure 6.
Type: a one-octet field. Value 1 has been allocated by IANA (Section 5.1).
Length: a two-octet field equal to the length of the Extra Padding field in octets.
Extra Padding: this field SHOULD be filled with a sequence of pseudorandom numbers. The field MAY be filled with all zeros. An implementation MUST control the content of the Extra Padding field 🎀
The Extra Padding TLV is kinda like the Packet Padding field in a TWAMP-Test packet [RFC5357]. Using it is RECOMMENDED when you want a STAMP test with packets bigger than the base STAMP packet [RFC8762]. The base STAMP packet is 44 octets in unauthenticated mode or 112 octets in authenticated mode. The Extra Padding TLV MAY be present more than once in an extended STAMP test packet ✨
4.2. Location TLV
STAMP Session-Senders MAY include the variable-size Location TLV to ask the Session-Reflector for location information 🗺️ The Session-Sender MUST NOT fill in any information fields except for the STAMP TLV Flags, Type, and Length fields. The Session-Reflector MUST verify that the TLV is well formed. If it isn't, the Session-Reflector follows the procedure defined in Section 4 for a malformed TLV 🙅♀️
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| STAMP TLV Flags | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port | Source Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Sub-TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Location TLV
The fields are defined as follows:
STAMP TLV Flags: an eight-bit field. Its format is presented in Figure 6.
Type: a one-octet field. Value 2 has been allocated by IANA (Section 5.1).
Length: a two-octet field equal to the length of the Value field in octets.
Destination Port: a two-octet UDP destination port number of the received STAMP packet.
Source Port: a two-octet UDP source port number of the received STAMP packet.
Sub-TLVs: a sequence of sub-TLVs, defined further in this section. The Session-Sender uses the sub-TLVs to request location information with generic sub-TLV types, and the Session-Reflector responds with the matching more-specific sub-TLVs for the type of address (e.g., IPv4 or IPv6) used at the Session-Reflector 💜
Heads up: all fields not filled in by either the Session-Sender or the Session-Reflector are transmitted with all bits set to zero. 🫧
4.2.1. Location Sub-TLVs ✨
okay so a sub-TLV inside the Location TLV uses the format in Figure 5 💖 the U and M flags work exactly how they work in Section 4 🎀 and the I flag MUST be set to 0 by both the Session-Sender and the Session-Reflector before sending, and its value gets ignored when it's received 🫶 here are the sub-TLV types this spec defines (Table 5 has the Type values) 🦋
- Source MAC Address sub-TLV: a 12-octet sub-TLV 🌸 the Type is
1and the Length field MUST be equal to8. The Value field is an 8-octet MBZ field that MUST be zeroed on transmission and ignored on receipt 💅 - Source EUI-48 Address sub-TLV: a 12-octet sub-TLV that carries the EUI-48 source MAC address 🍓 the Type is
2and the Length field MUST be equal to8.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: The Value Field of the Source EUI-48 Address Sub-TLV
The Value field has these fields (see Figure 9) 🧚
- EUI-48 Address: a six-octet field.
- MBZ: a two-octet field. It MUST be zeroed on transmission and ignored on receipt.
- Source EUI-64 Address sub-TLV: a 12-octet sub-TLV that carries the EUI-64 source MAC address 🌈 the Type is
3and the Length field MUST be equal to8. The Value field is an eight-octet EUI-64 field. - Destination IP Address sub-TLV: a 20-octet sub-TLV 🦋 the Type is
4and the Length field MUST be equal to16. The Value field is a 16-octet MBZ field that MUST be zeroed on transmit and ignored on receipt. - Destination IPv4 Address sub-TLV: a 20-octet sub-TLV that carries the IPv4 destination address 💜 the Type is
5and the Length field MUST be equal to16.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MBZ (12 octets) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 10: IPv4 Address in a Sub-TLV's Value Field
The Value field has these fields (see Figure 10) 🌸
- IPv4 Address: a four-octet field.
- MBZ: a 12-octet field. It MUST be zeroed on transmit and ignored on receipt.
- Destination IPv6 Address sub-TLV: a 20-octet sub-TLV that carries the IPv6 destination address 🍓 the Type is
6and the Length field MUST be equal to16. The Value field is a 16-octet IPv6 Address field. - Source IP Address sub-TLV: a 20-octet sub-TLV 🫶 the Type is
7and the Length field MUST be equal to16. The Value field is a 16-octet MBZ field that MUST be zeroed on transmit and ignored on receipt. - Source IPv4 Address sub-TLV: a 20-octet sub-TLV that carries the IPv4 source address 🔥 the Type is
8and the Length field MUST be equal to16. The Value field has these fields (see Figure 10) 👑- IPv4 Address: a four-octet field.
- MBZ: a 12-octet field. It MUST be zeroed on transmit and ignored on receipt.
- Source IPv6 Address sub-TLV: a 20-octet sub-TLV that carries the IPv6 source address ⭐ the Type is
9and the Length field MUST be equal to16. The Value field is a 16-octet IPv6 Address field.
4.2.2. Theory of Operation of Location TLV 🧠
okay this part is the main character of the whole Location TLV 💅 the Session-Reflector that gets an extended STAMP packet with the Location TLV MUST put the Location TLV in the reflected packet too, with a length equal to the Location TLV length in the received packet 🎀 based on local policy, the Session-Reflector MAY leave some fields unreported by filling them with zeroes 🙈 and any implementation of the stateful Session-Reflector MUST provide control for managing those policies ✨
a Session-Sender MAY include the Source MAC Address sub-TLV in the Location TLV 🦋 if the Session-Reflector gets a Location TLV with the Source MAC Address sub-TLV, it MUST include the Source EUI-48 Address sub-TLV when the source MAC address of the received extended test packet is in EUI-48 format, and it MUST copy the source MAC address into the EUI-48 field 🍓 otherwise, the Session-Reflector MUST use the Source EUI-64 Address sub-TLV and MUST copy the value of the Source MAC Address from the received packet into the EUI-64 field 🌈 and if the received extended STAMP test packet has no Source MAC Address, the Session-Reflector MUST zero the EUI-64 field before sending the reflected packet 💀
a Session-Sender MAY include the Destination IP Address sub-TLV in the Location TLV 🧚 if the Session-Reflector gets a Location TLV with the Destination IP Address sub-TLV, it MUST include the Destination IPv4 Address sub-TLV when the source IP address of the received extended test packet is IPv4, and it MUST copy the destination IP address into the IPv4 Address field 💜 otherwise, the Session-Reflector MUST use the Destination IPv6 Address sub-TLV and MUST copy the destination IP address from the received packet into the IPv6 Address field 🌸
a Session-Sender MAY include the Source IP Address sub-TLV in the Location TLV 🫶 if the Session-Reflector gets a Location TLV with the Source IP Address sub-TLV, it MUST include the Source IPv4 Address sub-TLV when the source IP address of the received extended test packet is IPv4, and it MUST copy the source IP address into the IPv4 Address field 🔥 otherwise, the Session-Reflector MUST use the Source IPv6 Address sub-TLV and MUST copy the source IP address from the received packet into the IPv6 Address field 👑
The Location TLV MAY be used to figure out the last-hop IP addresses, ports, and last-hop MAC address for STAMP packets 😭 the MAC address can show a path switch on the last hop, and the IP addresses and UDP ports show whether there's a NAT router on the path. It lets the Session-Sender find the IP address of the Session-Reflector behind the NAT, and spot changes in the NAT mapping that could send STAMP packets to the wrong Session-Reflector 🚨
4.3. Timestamp Information TLV 🕰️
the STAMP Session-Sender MAY include the Timestamp Information TLV to ask the Session-Reflector for information 🎀 the Session-Sender MUST NOT fill in any information fields except STAMP TLV Flags, Type, and Length 🙅♀️ every other field MUST be filled with zeroes. The Session-Reflector MUST validate the Length value of the TLV 🫶 if the Length field value is invalid, the Session-Reflector follows the procedure in Section 4 for a malformed TLV 💥
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sync Src In | Timestamp In | Sync Src Out | Timestamp Out |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 11: Timestamp Information TLV
here's what each field means 🧁
- STAMP TLV Flags: an eight-bit field. Its format is shown in Figure 6 ✨
- Type: a one-octet field. The value
3was allocated by IANA (Section 5.1) 🌷 - Length: a two-octet field, set equal to the length of the Value field in octets (Figure 5) 📏
- Sync Src In: a one-octet field that describes the source of clock synchronization at the ingress of a Session-Reflector 🕒 there are a few ways to sync a clock, e.g., the Network Time Protocol (NTP) [RFC5905] ⏰ Table 7 lists the possible values.
- Timestamp In: a one-octet field that describes how the ingress of the Session-Reflector got the timestamp T2 🫧 a timestamp can come from hardware assistance through a software API, from a local wall clock, or from a remote clock (the latter is called a "control plane") 🛸 Table 9 lists the possible values.
- Sync Src Out: a one-octet field that describes the source of clock synchronization at the egress of the Session-Reflector 🌊 Table 7 lists the possible values.
- Timestamp Out: a one-octet field that describes how the egress of the Session-Reflector got the timestamp T3 🌙 Table 9 lists the possible values.
- Optional sub-TLVs: an optional variable-length field 💫
4.4. Class of Service TLV ✨
okay so bestie, the STAMP Session-Sender MAY pop a Class of Service (CoS) TLV into the STAMP test packet 💅 The layout is in Figure 12 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP1 | DSCP2 |ECN| RP| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Class of Service TLVHere's the field breakdown 🦋
STAMP TLV Flags: an eight-bit field. Its format is in Figure 6 🌸
Type: a one-octet field. Value 4 was allocated by IANA (Section 5.1) 💖
Length: a two-octet field, set to the value 4 🧚
DSCP1: the Differentiated Services Code Point (DSCP) the Session-Sender wants used as the DSCP value of the reflected test packet ✨
DSCP2: the value that showed up in the DSCP field at the ingress of the Session-Reflector 👑
ECN: the value that showed up in the ECN field at the ingress of the Session-Reflector 🌈
RP (Reverse Path): a two-bit field. A Session-Sender MUST set RP to 0 on transmission. Non-negotiable, bestie 🫶
Reserved: a 16-bit field that MUST be zeroed on transmission and ignored on receipt 🍓
Now the Session-Reflector side, which is where it gets spicy 🔥 A STAMP Session-Reflector that receives a test packet with the CoS TLV MUST include the CoS TLV in the reflected test packet. It also MUST copy the DSCP and ECN values from the IP header of the received STAMP test packet into the DSCP2 field of the reflected test packet 💜 Then it MUST use local policy to check whether the CoS matching the DSCP1 value is permitted in the domain. If it is, the Session-Reflector MUST set the DSCP field in the IP header of the reflected test packet equal to the DSCP1 value from the received test packet 🎀 If it isn't, the Session-Reflector MUST use the DSCP value of the received STAMP packet instead and set RP to 1 😭
When the reflected packet comes back, the Session-Sender checks RP. If RP is 0, it saves the DSCP and ECN values so it can analyze the CoS in the reverse direction 🦋 If RP is 1, only the forward-direction CoS can be analyzed 💀
Why does any of this matter? Re-mapping CoS is how you can run multiple services (think 2G, 3G, and LTE in mobile backhaul) over the same network 🌸 But if it's misconfigured, it's super hard to figure out why higher-level service packets are getting dropped excessively while the lower-service packets look totally normal 🙈 A CoS TLV in STAMP testing helps troubleshoot that mess AND checks whether Diffserv policies are handling CoS the way the config says they should 🫶✨
4.5. Direct Measurement TLV 📊
The Direct Measurement TLV lets you collect the number of in-profile packets (packets that form a specific data flow) that were transmitted and received by the Session-Sender and Session-Reflector, respectively 🧚 What counts as an "in-profile packet" is outside the scope of this document and is up to the test operators to decide 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Tx counter (S_TxC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Reflector Rx counter (R_RxC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Reflector Tx counter (R_TxC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Direct Measurement TLVField time 🎀
STAMP TLV Flags: an eight-bit field. Its format is in Figure 6 ✨
Type: a one-octet field. Value 5 was allocated by IANA (Section 5.1) 🌈
Length: a two-octet field equal to the length of the Value field in octets. The Length field value MUST equal 12 octets 🍓
Session-Sender Tx counter (S_TxC): a four-octet field. The Session-Sender MUST set it equal to the number of transmitted in-profile packets 💖
Session-Reflector Rx counter (R_RxC): a four-octet field. The Session-Sender MUST zero it on transmit, and the Session-Reflector MUST ignore it on receipt. The Session-Reflector MUST fill it with the number of in-profile packets received 🦋
Session-Reflector Tx counter (R_TxC): a four-octet field. It MUST be zeroed by the Session-Sender and ignored by the Session-Reflector on receipt. The Session-Reflector MUST fill it with the number of transmitted in-profile packets 🫶
A Session-Sender MAY include the Direct Measurement TLV in a STAMP test packet 💜 If the received STAMP test packet includes it, the Session-Reflector MUST include it in the reflected test packet. The Session-Reflector MUST copy the value from the S_TxC field of the received test packet into the same field of the reflected packet before transmission 🔥
4.6. Access Report TLV 📡
A STAMP Session-Sender MAY include an Access Report TLV (Figure 14) to tell the Session-Reflector about changes in the access network status 🌸 What counts as an access network is outside the scope of this document 🙈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | Resv | Return Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Access Report TLVField check 🧚
STAMP TLV Flags: an eight-bit field. Its format is in Figure 6 💅
Type: a one-octet field. Value 6 was allocated by IANA (Section 5.1) ✨
Length: a two-octet field, set to the value 4 👑
ID (Access ID): a four-bit 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) [TS23501]. The value is one of the following:
1: 3GPP Network2: Non-3GPP Network
All other values are invalid. A TLV containing values other than '1' or '2' MUST be discarded 💀
Resv: a four-bit field that MUST be zeroed on transmission and ignored on receipt 🦋
Return Code: a one-octet field that identifies the report signal, e.g., available or unavailable. The value is supplied to the STAMP endpoint through a mechanism outside the scope of this document. Section 5.6 lists the possible values 🌈
Reserved: a two-octet field that MUST be zeroed on transmission and ignored on receipt 🍓
The Session-Sender that includes the Access Report TLV sets the Access ID field according to the type of access network it's reporting on 💖 It also sets Return Code to reflect the operational state of the access network. How the state gets determined is outside the scope of this specification 🫶 A Session-Reflector that receives a test packet with the Access Report TLV MUST include the Access Report TLV in the reflected test packet. It MUST set the Access ID and Return Code fields equal to the values from the corresponding fields of the test packet it received 🔥
The Session-Sender MUST also arm a retransmission timer after sending a test packet that includes the Access Report TLV ⏰ That timer MUST be disarmed when the reflected STAMP test packet containing the Access Report TLV comes back. If the timer expires before that packet arrives, the Session-Sender MUST retransmit the STAMP test packet containing the Access Report TLV 😭 This retransmission SHOULD be repeated up to four times before the procedure is aborted. How to set the retransmission timer depends on local policies and the network environment 🌸 The default value of the retransmission timer for the Access Report TLV SHOULD be three seconds ⭐ An implementation MUST provide control over the retransmission timer value and the number of retransmissions 👑
The Access Report TLV is used by the Performance Measurement Function (PMF) components of the Access Steering, Switching, and Splitting feature for 5G networks [TS23501] 🌈 The PMF component in the User Equipment acts as the STAMP Session-Sender, and the PMF component in the User Plane Function acts as the STAMP Session-Reflector 🧚✨
4.7. Follow-Up Telemetry TLV ✨
okay so this TLV is all about getting a timestamp that's closer to when the packet actually leaves 🕰️. A Session-Reflector might only be able to stamp an "SW Local" (see Table 9) timestamp into the Follow-Up Timestamp field. But the hosting system might know a timestamp nearer the start of the real transmission, even if it can't get that info back to the Session-Sender in time for that very packet 😭. That timestamp can still matter a lot, because it makes the delay measurement more accurate by cutting down how much egress queuing delay sneaks into the number 🎯.
A STAMP Session-Sender MAY include the Follow-Up Telemetry TLV to request information from the Session-Reflector 💌. The Session-Sender MUST set the Follow-Up Telemetry Type and Length fields to their appropriate values 🫶. The Sequence Number and Follow-Up Timestamp fields MUST be zeroed on transmission by the Session-Sender, and the Session-Reflector MUST ignore them when it receives the STAMP test packet that includes the Follow-Up Telemetry TLV 🙈. The Session-Reflector MUST validate the Length value of the STAMP test packet. If the Length field is invalid, the Session-Reflector MUST zero the Sequence Number and Follow-Up Timestamp fields and set the M flag in the STAMP TLV Flags field of the reflected packet 🚩. And if the Session-Reflector is in the stateless mode (defined in Section 4.2 of [RFC8762]), it MUST zero the Sequence Number and Follow-Up Timestamp fields 🧚.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Follow-Up Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp M | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Follow-Up Telemetry TLVHere's how the fields work 🧁:
STAMP TLV Flags: An eight-bit field. Its format is presented in Figure 6.
Type: A one-octet field. Value 7 has been allocated by IANA (Section 5.1).
Length: A two-octet field, set equal to the value 16 octets.
Sequence Number: A four-octet 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 (defined in Section 4.2 of [RFC8762]), this is the Session-Reflector's Sequence Number of the previous reflected packet 🔁.
Follow-Up Timestamp: An eight-octet field. Its format is indicated by the Z flag of the Error Estimate field of the STAMP base packet contained in this reflected test packet, as described in Section 4.2.1 of [RFC8762], and it's transmitted by a Session-Reflector ⏱️. It carries the timestamp for when the reflected packet with the specified sequence number was sent.
Timestamp M(ode): A one-octet field that describes the method the entity transmitting a reflected STAMP packet used to get the Follow-Up Timestamp 🔍. Table 9 lists the possible values.
Reserved: A three-octet field. Its value MUST be zeroed on transmission and ignored on receipt 🌸.
4.8. HMAC TLV 🔐
okay the STAMP authenticated mode protects the integrity of the data collected in the STAMP base packet, and STAMP extensions give you super valuable info about how a network is doing, so protecting that data is basically essential 👑. All authenticated STAMP base packets (per Sections 4.2.2 and 4.3.2 of [RFC8762]) that are compatible with this specification MUST additionally authenticate the optional TLVs by including the keyed Hashed Message Authentication Code (HMAC) TLV. The one exception is when there's only one TLV present and it's the Extended Padding TLV 🫧. The HMAC TLV MUST follow all TLVs included in a STAMP test packet, except for the Extra Padding TLV. If the HMAC TLV shows up anywhere else in a STAMP extended test packet, then the situation MUST be processed as an HMAC verification failure, as defined later in this section 🚨. The HMAC TLV MAY be used to protect the integrity of STAMP extensions in the STAMP unauthenticated mode. And an implementation of STAMP extensions MUST provide controls to enable integrity protection of STAMP extensions in the STAMP unauthenticated mode 🛡️.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: HMAC TLVThe fields are defined like this 🩷:
STAMP TLV Flags: An eight-bit field. Its format is presented in Figure 6.
Type: A one-octet field. Value 8 has been allocated by IANA (Section 5.1).
Length: A two-octet field, set equal to the value 16 octets.
HMAC: A 16-octet field that carries the HMAC digest of the text of all preceding TLVs.
As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128 bits (see [RFC4868]) 🧮. All considerations about using the key listed in Section 4.4 of [RFC8762] fully apply to the HMAC TLV too. Key management and the mechanisms for distributing the HMAC key are outside the scope of this specification 🗝️. The HMAC TLV is expected to track updates to the base STAMP protocol [RFC8762], including the use of more advanced cryptographic algorithms 📈.
Here's how the HMAC gets calculated 🧠: it's defined in [RFC2104] and runs over text made by concatenating the Sequence Number field of the base STAMP packet with all preceding TLVs. The digest then MUST be truncated to 128 bits and written into the HMAC field. If the HMAC TLV is present in the extended STAMP test packet (for example, in the authenticated mode), HMAC MUST be verified before any data in the included STAMP TLVs gets used 🙅♀️. If HMAC verification by the Session-Reflector fails, the Session-Reflector MUST stop processing the received extended STAMP test packet. The Session-Reflector MUST copy the TLVs from the received STAMP test packet into the reflected packet, and it MUST set the I flag in each TLV it copied over to 1 before transmitting the reflected test packet 🪞. If the Session-Sender receives an extended STAMP test packet with the I flag set to 1, the Session-Sender MUST stop processing TLVs in the reflected test packet. And if HMAC verification by the Session-Sender fails, the Session-Sender MUST stop processing TLVs in the reflected extended STAMP packet 💀.
5. IANA Considerations 🌈
IANA has created the following subregistries under the "Simple Two-way Active Measurement Protocol (STAMP) TLV Types" registry 📋.
5.1. STAMP TLV Types Subregistry 🎀
IANA has created the "STAMP TLV Types" subregistry. The code points in this registry are allocated according to the registration procedures [RFC8126] described in Table 1.
+===========+=========================+
| Range | Registration Procedures |
+===========+=========================+
| 1 - 175 | IETF Review |
+-----------+-------------------------+
| 176 - 239 | First Come First Served |
+-----------+-------------------------+
| 240 - 251 | Experimental Use |
+-----------+-------------------------+
| 252 - 254 | Private Use |
+-----------+-------------------------+
Table 1: Registration Procedures
for the STAMP TLV Types SubregistryPer this document, IANA has allocated the following values in the "STAMP TLV Types" subregistry 💖:
+=======+=======================+===========+
| Value | Description | Reference |
+=======+=======================+===========+
| 0 | Reserved | RFC 8972 |
+-------+-----------------------+-----------+
| 1 | Extra Padding | RFC 8972 |
+-------+-----------------------+-----------+
| 2 | Location | RFC 8972 |
+-------+-----------------------+-----------+
| 3 | Timestamp Information | RFC 8972 |
+-------+-----------------------+-----------+
| 4 | Class of Service | RFC 8972 |
+-------+-----------------------+-----------+
| 5 | Direct Measurement | RFC 8972 |
+-------+-----------------------+-----------+
| 6 | Access Report | RFC 8972 |
+-------+-----------------------+-----------+
| 7 | Follow-Up Telemetry | RFC 8972 |
+-------+-----------------------+-----------+
| 8 | HMAC | RFC 8972 |
+-------+-----------------------+-----------+
| 255 | Reserved | RFC 8972 |
+-------+-----------------------+-----------+
Table 2: STAMP TLV Types5.2. STAMP TLV Flags Subregistry 🦋
IANA has created the "STAMP TLV Flags" subregistry. The registration procedure is "IETF Review" [RFC8126]. The flags are 8 bits. Per this document, IANA has allocated the following bit positions in the "STAMP TLV Flags" subregistry 🌷:
+==============+========+========================+===========+
| Bit position | Symbol | Description | Reference |
+==============+========+========================+===========+
| 0 | U | Unrecognized TLV | RFC 8972 |
+--------------+--------+------------------------+-----------+
| 1 | M | Malformed TLV | RFC 8972 |
+--------------+--------+------------------------+-----------+
| 2 | I | Integrity check failed | RFC 8972 |
+--------------+--------+------------------------+-----------+
Table 3: STAMP TLV Flags5.3. STAMP Sub-TLV Types Subregistry 🎀
okay so IANA made a brand new registry called the "STAMP Sub-TLV Types" subregistry 🧚 and the code points in it get handed out based on the registration procedures from [RFC8126], which are laid out in Table 4 (it's giving organized, bestie 💅):
+===========+=========================+
| Range | Registration Procedures |
+===========+=========================+
| 1 - 175 | IETF Review |
+-----------+-------------------------+
| 176 - 239 | First Come First Served |
+-----------+-------------------------+
| 240 - 251 | Experimental Use |
+-----------+-------------------------+
| 252 - 254 | Private Use |
+-----------+-------------------------+
Table 4: Registration Procedures
for the STAMP Sub-TLV Types
Subregistryso per this document, IANA has already filled in these values in the "STAMP Sub-TLV Types" subregistry 🌸:
+=======+==========================+==========+===========+
| Value | Description | TLV Used | Reference |
+=======+==========================+==========+===========+
| 0 | Reserved | | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 1 | Source MAC Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 2 | Source EUI-48 Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 3 | Source EUI-64 Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 4 | Destination IP Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 5 | Destination IPv4 Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 6 | Destination IPv6 Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 7 | Source IP Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 8 | Source IPv4 Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 9 | Source IPv6 Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 255 | Reserved | | RFC 8972 |
+-------+--------------------------+----------+-----------+
Table 5: STAMP Sub-TLV Types5.4. STAMP Synchronization Sources Subregistry ⭐
next up, IANA made the "STAMP Synchronization Sources" subregistry 🦋. same deal, the code points get allocated using the [RFC8126] registration procedures from Table 6 (ngl the ranges are very tidy 🍓):
+===========+=========================+
| Range | Registration Procedures |
+===========+=========================+
| 1 - 127 | IETF Review |
+-----------+-------------------------+
| 128 - 239 | First Come First Served |
+-----------+-------------------------+
| 240 - 249 | Experimental Use |
+-----------+-------------------------+
| 250 - 254 | Private Use |
+-----------+-------------------------+
Table 6: Registration Procedures
for the STAMP Synchronization
Sources Subregistryand per this document, IANA has allocated these values in the "STAMP Synchronization Sources" subregistry 💜:
+=======+=================================+===========+
| Value | Description | Reference |
+=======+=================================+===========+
| 0 | Reserved | RFC 8972 |
+-------+---------------------------------+-----------+
| 1 | NTP | RFC 8972 |
+-------+---------------------------------+-----------+
| 2 | PTP | RFC 8972 |
+-------+---------------------------------+-----------+
| 3 | SSU/BITS | RFC 8972 |
+-------+---------------------------------+-----------+
| 4 | GPS/GLONASS/LORAN-C/BDS/Galileo | RFC 8972 |
+-------+---------------------------------+-----------+
| 5 | Local free-running | RFC 8972 |
+-------+---------------------------------+-----------+
| 255 | Reserved | RFC 8972 |
+-------+---------------------------------+-----------+
Table 7: STAMP Synchronization Sources5.5. STAMP Timestamping Methods Subregistry 🌈
okay this one is the "STAMP Timestamping Methods" subregistry 💖. the code points are allocated using the [RFC8126] registration procedures in Table 8, which look exactly like the last two tables (lowkey iconic 🫶):
+===========+=========================+
| Range | Registration Procedures |
+===========+=========================+
| 1 - 127 | IETF Review |
+-----------+-------------------------+
| 128 - 239 | First Come First Served |
+-----------+-------------------------+
| 240 - 249 | Experimental Use |
+-----------+-------------------------+
| 250 - 254 | Private Use |
+-----------+-------------------------+
Table 8: Registration Procedures
for the STAMP Timestamping Methods
Subregistryper this document, IANA has allocated these values in the "STAMP Timestamping Methods" subregistry 🧚♀️:
+=======+===============+===========+
| Value | Description | Reference |
+=======+===============+===========+
| 0 | Reserved | RFC 8972 |
+-------+---------------+-----------+
| 1 | HW Assist | RFC 8972 |
+-------+---------------+-----------+
| 2 | SW Local | RFC 8972 |
+-------+---------------+-----------+
| 3 | Control Plane | RFC 8972 |
+-------+---------------+-----------+
| 255 | Reserved | RFC 8972 |
+-------+---------------+-----------+
Table 9: STAMP Timestamping Methods5.6. STAMP Return Codes Subregistry 🍓
last registry, I promise 🙈. IANA created the "STAMP Return Codes" subregistry, and the code points in it are allocated per the [RFC8126] registration procedures in Table 10:
+===========+=========================+
| Range | Registration Procedures |
+===========+=========================+
| 1 - 127 | IETF Review |
+-----------+-------------------------+
| 128 - 239 | First Come First Served |
+-----------+-------------------------+
| 240 - 249 | Experimental Use |
+-----------+-------------------------+
| 250 - 254 | Private Use |
+-----------+-------------------------+
Table 10: Registration Procedures
for the STAMP Return Codes
Subregistryand per this document, IANA has allocated these values in the "STAMP Return Codes" subregistry 👑:
+=======+=====================+===========+
| Value | Description | Reference |
+=======+=====================+===========+
| 0 | Reserved | RFC 8972 |
+-------+---------------------+-----------+
| 1 | Network available | RFC 8972 |
+-------+---------------------+-----------+
| 2 | Network unavailable | RFC 8972 |
+-------+---------------------+-----------+
| 255 | Reserved | RFC 8972 |
+-------+---------------------+-----------+
Table 11: STAMP Return Codes6. Security Considerations 💀
okay bestie, this part is serious so let's be careful 🔥. this document extends STAMP [RFC8762] and inherits ALL the security considerations of the base protocol. on top of that, the HMAC TLV is defined here. it protects the integrity of STAMP extensions, but it does NOT protect against a replay attack. see Section 4.8 for the full HMAC TLV details ✨.
to protect against a malformed TLV, a Session-Sender and a Session-Reflector MUST:
- check the setting of the M flag and
- validate the Length field value.
⚠️ PSA: these two checks are a MUST, not a suggestion. no skipping 🙅♀️
next, this spec defines the mechanism for testing DSCP mapping, so it inherits all the security considerations discussed in [RFC2474] 🦋. monitoring and optional control of DSCP using the CoS TLV may be used across the Internet, so the Session-Sender and the Session-Reflector can be located in domains that use different CoS profiles. that means it's ESSENTIAL that an operator verifies the set of CoS values used in the Session-Reflector's domain 🚨. also, an implementation of a Session-Reflector SHOULD support a local policy to confirm whether the value sent by the Session-Sender can be used as the value of the DSCP field. Section 4.4 defines how that local policy is used 🌟.
7. References 📚
7.1. Normative References 🎀
- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
- [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
- [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
- [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, <https://www.rfc-editor.org/info/rfc8762>.
7.2. Informative References 📚✨
- [GPS] "Global Positioning System (GPS) Standard Positioning Service (SPS) Performance Standard", GPS SPS 5th Edition, April 2020.
- [IEEE.1588.2008] "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std. 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July 2008,
<https://doi.org/10.1109/IEEESTD.2008.4579760>. - [NUM-IDS-GEN] Gont, F. and I. Arce, "On the Generation of Transient Numeric Identifiers", Work in Progress, Internet-Draft, draft-irtf-pearg-numeric-ids-generation-06, 13 January 2021,
<https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation-06>. 🔍 - [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>. 🎀 - [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>. 🔐 - [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/info/rfc5357>. 🦋 - [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. ⏰ - [TS23501] 3GPP, "Technical Specification Group Services and System Aspects; System Architecture for the 5G System (5GS); Stage 2 (Release 16)", 3GPP TS 23.501, 2019. 📡
Acknowledgments 🫶
Huge thanks to Tianran Zhou, Rakesh Gandhi, Yuezhong Song, and Yali Wang for the super thorough reviews and thoughtful comments. 💖 The authors also want to give a big shoutout to Al Morton for his comments and valuable suggestions, and to Martin Duke for the comments and thoughtful suggestions. You all are literally the best. 👑
Contributors 🌸
Guo Jun from ZTE Corporation contributed text to this document. Here's how to reach them:
Guo Jun
ZTE Corporation
68# Zijinghua Road
Nanjing
Jiangsu, 210012
China
Phone: +86 18105183663
Email: guo.jun2@zte.com.cnAuthors' Addresses 💌
Meet the crew! 🧚
Greg Mirsky
ZTE Corp.
Email: gregimirsky@gmail.com
Xiao Min
ZTE Corp.
Email: xiao.min2@zte.com.cn
Henrik Nydell
Accedian Networks
Email: hnydell@accedian.com
Richard Foote
Nokia
Email: footer.foote@nokia.com
Adi Masputra
Apple Inc.
One Apple Park Way
Cupertino, CA 95014
United States of America
Email: adi@apple.com
Ernesto Ruffini
OutSys
via Caracciolo, 65
20155 Milan
Italy
Email: eruffini@outsys.org📦 where this page comes from
- ietf: rfc8972 2021-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms