< draft-ietf-ippm-stamp-option-tlv-07.txt		draft-ietf-ippm-stamp-option-tlv-08.txt >
	Network Working Group G. Mirsky		Network Working Group G. Mirsky
	Internet-Draft X. Min		Internet-Draft X. Min
	Updates: 8762 (if approved) ZTE Corp.		Updates: 8762 (if approved) ZTE Corp.
	Intended status: Standards Track H. Nydell		Intended status: Standards Track H. Nydell
	Expires: January 9, 2021 Accedian Networks		Expires: January 26, 2021 Accedian Networks
	R. Foote		R. Foote
	Nokia		Nokia
	A. Masputra		A. Masputra
	Apple Inc.		Apple Inc.
	E. Ruffini		E. Ruffini
	OutSys		OutSys
	July 8, 2020		July 25, 2020
	Simple Two-way Active Measurement Protocol Optional Extensions		Simple Two-way Active Measurement Protocol Optional Extensions
	draft-ietf-ippm-stamp-option-tlv-07		draft-ietf-ippm-stamp-option-tlv-08
	Abstract		Abstract
	This document describes optional extensions to Simple Two-way Active		This document describes optional extensions to Simple Two-way Active
	Measurement Protocol (STAMP) that enable measurement of performance		Measurement Protocol (STAMP) that enable measurement of performance
	metrics, in addition to ones supported by the STAMP base		metrics. The document also defines a STAMP Test Session Identifier
	specification. The document also defines a STAMP Test Session		and thus updates RFC 8762.
	Identifier and thus updates RFC 8762.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 9, 2021.		This Internet-Draft will expire on January 26, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 24 ¶		skipping to change at page 2, line 21 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions Used in This Document . . . . . . . . . . . . . . 3		2. Conventions Used in This Document . . . . . . . . . . . . . . 3
	2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3		2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
	3. STAMP Test Session Identifier . . . . . . . . . . . . . . . . 4		3. STAMP Test Session Identifier . . . . . . . . . . . . . . . . 4
	4. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 8		4. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 8
	4.1. Extra Padding TLV . . . . . . . . . . . . . . . . . . . . 11		4.1. Extra Padding TLV . . . . . . . . . . . . . . . . . . . . 11
	4.2. Location TLV . . . . . . . . . . . . . . . . . . . . . . 11		4.2. Location TLV . . . . . . . . . . . . . . . . . . . . . . 12
	4.3. Timestamp Information TLV . . . . . . . . . . . . . . . . 13		4.2.1. Location Sub-TLVs . . . . . . . . . . . . . . . . . . 13
	4.4. Class of Service TLV . . . . . . . . . . . . . . . . . . 14		4.2.2. Theory of Operation of Location TLV . . . . . . . . . 14
	4.5. Direct Measurement TLV . . . . . . . . . . . . . . . . . 15		4.3. Timestamp Information TLV . . . . . . . . . . . . . . . . 16
	4.6. Access Report TLV . . . . . . . . . . . . . . . . . . . . 17		4.4. Class of Service TLV . . . . . . . . . . . . . . . . . . 17
	4.7. Follow-up Telemetry TLV . . . . . . . . . . . . . . . . . 18		4.5. Direct Measurement TLV . . . . . . . . . . . . . . . . . 18
	4.8. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 20		4.6. Access Report TLV . . . . . . . . . . . . . . . . . . . . 19
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		4.7. Follow-up Telemetry TLV . . . . . . . . . . . . . . . . . 21
	5.1. STAMP TLV Registry . . . . . . . . . . . . . . . . . . . 21		4.8. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 23
	5.2. STAMP TLV Flags Sub-registry . . . . . . . . . . . . . . 22		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	5.3. Synchronization Source Sub-registry . . . . . . . . . . . 22		5.1. STAMP TLV Registry . . . . . . . . . . . . . . . . . . . 24
	5.4. Timestamping Method Sub-registry . . . . . . . . . . . . 23		5.2. STAMP TLV Flags Sub-registry . . . . . . . . . . . . . . 25
	5.5. Return Code Sub-registry . . . . . . . . . . . . . . . . 24		5.3. Sub-TLV Type Sub-registry . . . . . . . . . . . . . . . . 25
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 25		5.4. Synchronization Source Sub-registry . . . . . . . . . . . 26
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25		5.5. Timestamping Method Sub-registry . . . . . . . . . . . . 27
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25		5.6. Return Code Sub-registry . . . . . . . . . . . . . . . . 28
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	9.1. Normative References . . . . . . . . . . . . . . . . . . 26		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
	9.2. Informative References . . . . . . . . . . . . . . . . . 26		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
			9.1. Normative References . . . . . . . . . . . . . . . . . . 30
			9.2. Informative References . . . . . . . . . . . . . . . . . 30
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] supports		Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] defined
	the use of optional extensions that use Type-Length-Value (TLV)		the STAMP base functionalities. This document specifies the use of
	encoding. Such extensions enhance the STAMP base functions, such as		optional extensions that use Type-Length-Value (TLV) encoding. Such
	measurement of one-way and round-trip delay, latency, packet loss,		extensions enhance the STAMP base functions, such as measurement of
	packet duplication, and out-of-order delivery of test packets. This		one-way and round-trip delay, latency, packet loss, packet
			duplication, and out-of-order delivery of test packets. This
	specification defines optional STAMP extensions, their formats, and		specification defines optional STAMP extensions, their formats, and
	the theory of operation. Also, a STAMP Test Session Identifier is		the theory of operation. Also, a STAMP Test Session Identifier is
	defined as an update of the base STAMP specification [RFC8762].		defined as an update of the base STAMP specification [RFC8762].
	2. Conventions Used in This Document		2. Conventions Used in This Document
	2.1. Acronyms		2.1. Acronyms
	BDS BeiDou Navigation Satellite System		BDS BeiDou Navigation Satellite System
	skipping to change at page 4, line 25 ¶		skipping to change at page 4, line 27 ¶
	packets are compatible on the wire with unauthenticated TWAMP-Test		packets are compatible on the wire with unauthenticated TWAMP-Test
	[RFC5357] packets.		[RFC5357] packets.
	By default, STAMP uses symmetrical packets, i.e., the size of the		By default, STAMP uses symmetrical packets, i.e., the size of the
	packet transmitted by the Session-Reflector equals the size of the		packet transmitted by the Session-Reflector equals the size of the
	packet received by the Session-Reflector.		packet received by the Session-Reflector.
	A STAMP Session is identified by the 4-tuple (source and destination		A STAMP Session is identified by the 4-tuple (source and destination
	IP addresses, source and destination UDP port numbers). A STAMP		IP addresses, source and destination UDP port numbers). A STAMP
	Session-Sender MAY generate a locally unique STAMP Session Identifier		Session-Sender MAY generate a locally unique STAMP Session Identifier
	(SSID). SSID is a two-octet-long non-zero unsigned integer. A		(SSID). The SSID is a two-octet-long non-zero unsigned integer.
	Session-Sender MAY use SSID to identify a STAMP test session. If		SSID generation policy is implementation-specific.
	SSID is used, it MUST be present in each test packet of the given		[I-D.gont-numeric-ids-generation] thoroughly analyzes common
	test session. In the unauthenticated mode, SSID is located as		algorithms for identifier generation and their vulnerabilities. For
	displayed in Figure 1.		example, an implementation can use algorithms described in
			Section 7.1 of [I-D.gont-numeric-ids-generation]. An implementation
			MUST NOT assign the same identifier to different STAMP test sessions.
			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 the unauthenticated mode, the SSID is located
			as displayed in Figure 1.
	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 page 5, line 26 ¶		skipping to change at page 5, line 26 ¶
	| |		| |
	| MBZ (28 octets) |		| MBZ (28 octets) |
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ TLVs ~		~ TLVs ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: An example of an extended STAMP Session-Sender test packet		Figure 1: The format of an extended STAMP Session-Sender test packet
	format in unauthenticated mode		in unauthenticated mode
	An implementation of the STAMP Session-Reflector that supports this		An implementation of the STAMP Session-Reflector that supports this
	specification SHOULD identify a STAMP Session using the SSID in		specification MUST identify a STAMP Session using the SSID in
	combination with elements of the usual 4-tuple for the session.		combination with elements of the usual 4-tuple for the session.
	Before a test session commences, a Session-Reflector MUST be		Before a test session commences, a Session-Reflector MUST be
	provisioned with all the elements that identify the STAMP Session. A		provisioned with all the elements that identify the STAMP Session. A
	STAMP Session-Reflector MUST discard non-matching STAMP test		STAMP Session-Reflector MUST discard non-matching STAMP test
	packet(s). The means of provisioning the STAMP Session		packet(s). The means of provisioning the STAMP Session
	identification is outside the scope of this specification. A		identification is outside the scope of this specification. A
	conforming implementation of STAMP Session-Reflector MUST copy the		conforming implementation of STAMP Session-Reflector MUST copy the
	SSID value from the received test packet and put it into the		SSID value from the received test packet and put it into the
	reflected packet, as displayed in Figure 2.		reflected packet, as displayed in Figure 2.
	skipping to change at page 6, line 30 ¶		skipping to change at page 6, line 30 ¶
	| 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 ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: An example of an extended STAMP Session-Reflector test		Figure 2: The format of an extended STAMP Session-Reflector test
	packet format in unauthenticated mode		packet in unauthenticated mode
	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		The Session-Sender MAY stop the session if it receives a zeroed SSID
	field. An implementation of a Session-Sender MUST support control of		field. An implementation of a Session-Sender MUST support control of
	its behavior in such a scenario. If the test session is not stopped,		its behavior in such a scenario. If the test session is not stopped,
	the Session-Sender, can, for example, send a base STAMP packet		the Session-Sender, can, for example, send a base STAMP packet
	[RFC8762].		[RFC8762] or continue transmitting STAMP test packets with the SSID.
	Location of the SSID field in the authenticated mode is shown in		Location of the SSID field in the authenticated mode is shown in
	Figure 3 and Figure 4.		Figure 3 and Figure 4.
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 28 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ~		~ ~
	| MBZ (68 octets) |		| MBZ (68 octets) |
	~ ~		~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| HMAC (16 octets) |		| HMAC (16 octets) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ TLVs ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Base STAMP Session-Sender test packet format in		Figure 3: Base STAMP Session-Sender test packet format in
	authenticated mode		authenticated mode
	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) |
	skipping to change at page 8, line 29 ¶		skipping to change at page 8, line 31 ¶
	+-+-+-+-+-+-+-+-+ +		+-+-+-+-+-+-+-+-+ +
	| |		| |
	| MBZ (15 octets) |		| MBZ (15 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| HMAC (16 octets) |		| HMAC (16 octets) |
	| |		| |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ TLVs ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Base STAMP Session-Reflector test packet format in		Figure 4: Base STAMP Session-Reflector test packet format in
	authenticated mode		authenticated mode
	4. TLV Extensions to STAMP		4. TLV Extensions to STAMP
	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. TLV is an		extension mechanism for optional informational elements. TLV is an
	optional field in the STAMP test packet. Multiple TLVs MAY be placed		optional field in the STAMP test packet. Multiple TLVs MAY be placed
	in a STAMP test packet. A TLV MAY be enclosed in a TLV. TLVs have a		in a STAMP test packet. Additional TLVs may be enclosed within a
	one-octet-long STAMP TLV Flags field, one-octet-long Type field, and		given TLV, subject to the semantics of the (outer) TLV in question.
	two-octet-long Length field that is equal to the length of the Value		TLVs have a one-octet-long STAMP TLV Flags field, a one-octet-long
	field in octets. If a Type value for TLV or sub-TLV is in the range		Type field, and a two-octet-long Length field that is equal to the
	for Vendor Private Use, the Length MUST be at least 4, and the first		length of the Value field in octets. If a Type value for TLV or sub-
	four octets MUST be that vendor's the Structure of Management		TLV is in the range for Vendor Private Use, the Length MUST be at
	Information (SMI) Private Enterprise Code, as recorded in IANA's SMI		least 4, and the first four octets MUST be that vendor's Structure of
	Private Enterprise Codes sub-registry, in network octet order. The		Management Information (SMI) Private Enterprise Code, as recorded in
	rest of the Value field is private to the vendor. The following		IANA's SMI Private Enterprise Codes sub-registry, in network octet
	sections describe the use of TLVs for STAMP that extend STAMP		order. The rest of the Value field is private to the vendor. The
	capability beyond its base specification.		following sections describe the use of TLVs for STAMP that extend the
			STAMP capability beyond its base specification.
	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 ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: TLV Format in a STAMP Extended Packet		Figure 5: TLV Format in a STAMP Extended Packet
	skipping to change at page 9, line 30 ¶		skipping to change at page 9, line 33 ¶
	o Type - one-octet-long field that characterizes the interpretation		o Type - one-octet-long field that characterizes the interpretation
	of the Value field. It is allocated by IANA, as specified in		of the Value field. It is allocated by IANA, as specified in
	Section 5.1.		Section 5.1.
	o Length - two-octet-long field equal to the length of the Value		o Length - two-octet-long field equal to the length of the Value
	field in octets.		field in octets.
	o Value - a variable-length field. Its interpretation and encoding		o Value - a variable-length field. Its interpretation and encoding
	is determined by the value of the Type field.		is determined by the value of the Type field.
			All multibyte fields in the defined in this specification TLVs are in
			network byte order.
	The format of the STAMP TLV Flags displayed in Figure 6 and the		The format of the STAMP TLV Flags displayed in Figure 6 and the
	location of flags is according to Section 5.2.		location of flags is according to Section 5.2.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|U|L|A|R|R|R|R|R|		|U|M|I|R|R|R|R|R|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 6: STAMP TLV Flags Format		Figure 6: STAMP TLV Flags Format
	where fields are defined as the following:		where fields are defined as the following:
	o U - a one-bit flag. A Session-Sender MUST set the U flag to 0		o U (Unrecognized) is a one-bit flag. A Session-Sender MUST set the
	before transmitting an extended STAMP test packet. A Session-		U flag to 1 before transmitting an extended STAMP test packet. A
	Reflector MUST set the U flag to 1 if the Session-Reflector has		Session-Reflector MUST set the U flag to 1 if the Session-
	not understood the TLV.		Reflector has not understood the TLV. Otherwise, the Session-
			Reflector MUST set the U flag in the reflected packet to 0.
	o L - a one-bit flag. A Session-Sender MUST set the L flag to 0		o M (Malformed) is a one-bit flag. A Session-Sender MUST set the M
	before transmitting an extended STAMP test packet. A Session-		flag to 0 before transmitting an extended STAMP test packet. A
	Reflector MUST set the L flag to 1 if the Session-Reflector		Session-Reflector MUST set the M flag to 1 if the Session-
	determined the TLV is malformed, i.e., the Length field value of		Reflector determined the TLV is malformed, i.e., the Length field
	the fixed-size TLV is not equal to the value defined for the		value is not valid for the particular type, or the remaining
	particular type, or the remaining length of the extended STAMP		length of the extended STAMP packet is less than the size of the
	packet is less than the size of the TLV.		TLV. Otherwise, the Session-Reflector MUST set the M flag in the
			reflected packet to 0.
	o A - a one-bit flag. A Session-Sender MUST set the A flag to 0		o I (Integrity) is a one-bit flag. A Session-Sender MUST set the I
	before transmitting an extended STAMP test packet. A Session-		flag to 0 before transmitting an extended STAMP test packet. A
	Reflector MUST set the A flag to 1 if the STAMP extensions have		Session-Reflector MUST set the I flag to 1 if the STAMP extensions
	failed HMAC verification (Section 4.8).		have failed HMAC verification (Section 4.8). Otherwise, the
			Session-Reflector MUST set the I flag in the reflected packet to
			0.
	o R - reserved flags for future use. These flags MUST be zeroed on		o R - reserved flags for future use. These flags MUST be zeroed on
	transmit and ignored on receipt.		transmit and ignored on receipt.
	A STAMP node, whether Session-Sender or Session-Reflector, receiving		A STAMP node, whether Session-Sender or Session-Reflector, receiving
	a test packet MUST determine whether the packet is a base STAMP		a test packet MUST determine whether the packet is a base STAMP
	packet or includes one or more TLVs. The node MUST compare the value		packet or includes one or more TLVs. The node MUST compare the value
	in the Length field of the UDP header and the length of the base		in the Length field of the UDP header and the length of the base
	STAMP test packet in the mode, unauthenticated or authenticated based		STAMP test packet in the mode, unauthenticated or authenticated based
	on the configuration of the particular STAMP test session. If the		on the configuration of the particular STAMP test session. If the
	difference between the two values is larger than the length of the		difference between the two values is larger than the length of the
	UDP header, then the test packet includes one or more STAMP TLVs that		UDP header, then the test packet includes one or more STAMP TLVs that
	immediately follow the base STAMP test packet. A Session-Reflector		immediately follow the base STAMP test packet. A Session-Reflector
	that does not support STAMP extensions is not expected to compare the		that does not support STAMP extensions will not process but copy them
	value in the Length field of the UDP header and the length of the		into the reflected packet, as defined in Section 4.3 [RFC8762]. A
	STAMP base packet. Hence the Session-Reflector will transmit the		Session-Reflector that supports TLVs will indicate specific TLVs that
	base STAMP packet. It is the local policy on the Session-Sender		it did not process by setting the U flag to 1 in those TLVs.
	(similar to the handling of SSID == 0 scenario described in
	Section 3) that will control the sender's behavior.
	A system that has received a STAMP test packet with extension TLVs		A STAMP system, i.e., either a Session-Sender or a Session-Reflector,
	MUST validate each TLV:		that has received a STAMP test packet with extension TLVs MUST
			validate each TLV:
	If the U flag is set, the STAMP system MUST skip the processing of		If the U flag is set, the STAMP system MUST skip the processing of
	the TLV. The implementation MUST try to process the next TLV if		the TLV.
	present in the extended STAMP packet.
	If the L flag is set, the STAMP system MUST stop processing the		If the M flag is set, the STAMP system MUST stop processing the
	remainder of the extended STAMP packet.		remainder of the extended STAMP packet.
	If the A flag is set, the STAMP system MUST discard all TLVs and		If the I flag is set, the STAMP system MUST discard all TLVs and
	MUST stop processing the remainder of the extended STAMP packet.		MUST stop processing the remainder of the extended STAMP packet.
	If an implementation of a Session-Reflector does not recognize the		If an implementation of a Session-Reflector does not recognize the
	Type field value, it MUST include a copy of the TLV into the		Type field value, it MUST include a copy of the TLV into the
	reflected STAMP packet. The Session-Reflector MUST set the U flag		reflected STAMP packet. The Session-Reflector MUST set the U flag
	to 1. The Session-Reflector MUST try to process the next TLV in		to 1. The Session-Reflector MUST skip the processing of the
	the extended STAMP packet.		unrecognized TLV.
	If a TLV is malformed, the processing of extension TLVs MUST be		If a TLV is malformed, the processing of extension TLVs MUST be
	stopped. The Session-Reflector MUST copy the remainder of the		stopped. The Session-Reflector MUST copy the remainder of the
	received extended STAMP packet into the reflected STAMP packet.		received extended STAMP packet into the reflected STAMP packet.
	The Session-Reflector MUST set the L flag to 1.		The Session-Reflector MUST set the M flag to 1.
	Detected error events MUST be logged. Note that rate of logging MUST
	be controlled.
	4.1. Extra Padding TLV		4.1. Extra Padding TLV
	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|Extra Pad Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Extra Padding ~		~ Extra Padding ~
	skipping to change at page 11, line 35 ¶		skipping to change at page 11, line 41 ¶
	o STAMP TLV Flags - is an eight-bit-long field. Its format is		o STAMP TLV Flags - is an eight-bit-long field. Its format is
	presented in Figure 6.		presented in Figure 6.
	o Extra Padding Type - is a one-octet-long field, value TBA1		o Extra Padding Type - is a one-octet-long field, value TBA1
	allocated by IANA Section 5.1.		allocated by IANA Section 5.1.
	o Length - two-octet-long field equal to the length of the Extra		o Length - two-octet-long field equal to the length of the Extra
	Padding field in octets.		Padding field in octets.
	o Extra Padding - a pseudo-random sequence of bits. The field MAY		o Extra Padding - SHOULD be filled by a sequence of a pseudo-random
	be filled with all zeros.		numbers. The field MAY be filled with all zeros. An
			implementation MUST control the type of filling of the Extra
			Padding field.
	The Extra Padding TLV is similar to the Packet Padding field in a		The Extra Padding TLV is similar to the Packet Padding field in a
	TWAMP-Test packet [RFC5357]. The use of the Extra Padding TLV is		TWAMP-Test packet [RFC5357]. The use of the Extra Padding TLV is
	RECOMMENDED to perform a STAMP test using test packets of larger size		RECOMMENDED to perform a STAMP test using test packets of larger size
	than the base STAMP packet [RFC8762]. The length of the base STAMP		than the base STAMP packet [RFC8762]. The length of the base STAMP
	packet is 44 octets in the unauthenticated mode or 112 octets in the		packet is 44 octets in the unauthenticated mode or 112 octets in the
	authenticated mode. The Extra Padding TLV MAY be present more than		authenticated mode. The Extra Padding TLV MAY be present more than
	one time in an extended STAMP test packet.		one time in an extended STAMP test packet.
	4.2. Location TLV		4.2. Location TLV
	STAMP Session-Senders MAY include the Location TLV to request		STAMP Session-Senders MAY include the variable-size Location TLV to
	information from the Session-Reflector. The Session-Sender SHOULD		query location information from the Session-Reflector. The Session-
	NOT fill any information fields except for STAMP TLV Flags, Type, and		Sender MUST NOT fill any information fields except for STAMP TLV
	Length. The Session-Reflector MUST validate the Length value against		Flags, Type, and Length. The Session-Reflector MUST verify that the
	the address family of the transport encapsulating the STAMP test		TLV is well-formed. If it is not, the Session-Reflector follows the
	packet. If the Length field's value is invalid, the Session-		procedure defined in Section 4 for a malformed TLV.
	Reflector MUST zero all fields and MUST NOT return any information to
	the Session-Sender. The Session-Reflector MUST ignore all other
	fields of the received Location TLV.
	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| Location Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source MAC |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Destination IP Address ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Source IP Address ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Destination Port | Source Port |		| Destination Port | Source Port |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ Sub-TLVs ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 8: Session-Reflector Location TLV		Figure 8: Location TLV
	where fields are defined as the following:		where fields are defined as the following:
	o STAMP TLV Flags - is an eight-bit-long field. Its format is		o STAMP TLV Flags - is an eight-bit-long field. Its format is
	presented in Figure 6.		presented in Figure 6.
	o Location Type - is a one-octet-long field, value TBA2 allocated by		o Location Type - is a one-octet-long field, value TBA2 allocated by
	IANA Section 5.1.		IANA Section 5.1.
	o Length - two-octet-long field equal to the length of the Value		o Length - two-octet-long field equal to the length of the Value
	field in octets. The Length field value MUST equal 20 octets for		field in octets.
	the IPv4 address family. For the IPv6 address family, the value
	of the Length field MUST equal 44 octets. All other values are
	invalid.
	o Source MAC - 6-octet-long field. The Session-Reflector MUST copy
	the Source MAC of the received STAMP packet into this field.
	o Reserved - two-octet-long field. MUST be zeroed on transmission
	and ignored on reception.
	o Destination IP Address - IPv4 or IPv6 destination address of the
	packet received by the STAMP Session-Reflector.
	o Source IP Address - IPv4 or IPv6 source address of the packet
	received by the STAMP Session-Reflector.
	o Destination Port - two-octet-long UDP destination port number of		o Destination Port - two-octet-long UDP destination port number of
	the received STAMP packet.		the received STAMP packet.
	o Source Port - two-octet-long UDP source port number of the		o Source Port - two-octet-long UDP source port number of the
	received STAMP packet.		received STAMP packet.
			o Sub-TLVs - a sequence of sub-TLVs, as defined further in this
			section. The sub-TLVs are used by the Session-Sender to request
			location information with generic sub-TLV types, and the Session-
			Reflector responds with the corresponding more-specific sub-TLVs
			for the type of address (e.g., IPv4 or IPv6) used at the Session-
			Reflector.
			4.2.1. Location Sub-TLVs
			A sub-TLV in the Location TLV uses the format displayed in Figure 5.
			Handling of the U and M flags in the sub-TLV is as defined in
			Section 4. The I flag MUST be set by a Session-Sender and Session-
			Reflector to 0 before transmission and its value ignored on receipt.
			The following types of sub-TLV for the Location TLV are defined in
			this specification (type values are assigned according to Table 5):
			o 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 a 12-octet-long MBZ field that MUST be zeroed
			on transmission and ignored on receipt.
			o Source EUI-48 Address sub-TLV - is a 12-octet-long sub-TLV that
			includes the EUI-48 source MAC address. The Type value is TBA10.
			The value of the Length field MUST equal to 8.
			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 consists of the following fields (Figure 9):
			* The EUI-48 is a six-octet-long field.
			* Two-octet-ling MBZ field MUST be zeroed on transmission and
			ignored on receipt.
			o 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 12. The Value field
			consists of an eight-octet-long EUI-64 field.
			o Destination IP Address sub-TLV - is a 20-octet-long sub-TLV. The
			Type value is TBA12. The value of the Length field MUST equal to
			16. The Value field consists of a 16-octet-long MBZ field that
			MUST be zeroed on transmit and ignored on receipt
			o Destination IPv4 Address sub-TLV - is a 20-octet-long sub-TLV that
			includes IPv4 destination address. The Type value is TBA13. The
			value of the Length field MUST equal to 16.
			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 consists of the following fields (Figure 10):
			* The IPv4 Address is a four-octet-long field.
			* 12-octet-long MBZ field MUST be zeroed on transmit and ignored
			on receipt.
			o Destination IPv6 Address sub-TLV - is a 20-octet-long sub-TLV that
			includes IPv6 destination address. The Type value is TBA14. The
			value of the Length field MUST equal to 16. The Value field is a
			16-octet-long IP v6 Address field.
			o Source IP Address sub-TLV - is a 20-octet-long sub-TLV. 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 transmit and ignored on receipt
			o Source IPv4 Address sub-TLV - is a 20-octet-long sub-TLV that
			includes IPv4 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 (Figure 10):
			* The IPv4 Address is a four-octet-long field.
			* 12-octet-long MBZ field that MUST be zeroed on transmit and
			ignored on receipt.
			o Source IPv6 Address sub-TLV - is a 20-octet-long sub-TLV that
			includes IPv6 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.
			4.2.2. Theory of Operation of Location TLV
			The Session-Reflector that received an extended STAMP packet with the
			Location TLV MUST include the Location TLV of the size equal to the
			size of Location TLV in the received packet in the reflected packet.
			Based on the local policy, the Session-Reflector MAY leave some
			fields unreported by filling them with zeroes. An implementation of
			the stateful Session-Reflector MUST provide control for managing such
			policies.
			A Session-Sender MAY include the Source MAC Address sub-TLV is the
			Location TLV. If the Session-Reflector receives the Location TLV
			that includes the Source MAC Address sub-TLV, it MUST include the
			Source EUI-48 Address sub-TLV if the source MAC address of the
			received extended test packet is in EUI-48 format. And the Session-
			Reflector MUST 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 and MUST copy the value 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 address, the
			Session-Reflector MUST zero the EUI-64 field before transmitting the
			reflected packet.
			A Session-Sender MAY include the Destination IP Address sub-TLV is
			the Location TLV. If the Session-Reflector receives the Location TLV
			that includes the Destination IP Address sub-TLV, it MUST include the
			Destination IPv4 Address sub-TLV if the source IP address of the
			received extended test packet is of IPv4 address family. And the
			Session-Reflector MUST 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 of the
			destination IP address from the received packet into the IPv6 Address
			field.
			A Session-Sender MAY include the Source IP Address sub-TLV is the
			Location TLV. 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 received
			extended test packet is of IPv4 address family. And the Session-
			Reflector MUST 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 of the source IP address
			from the received packet into the IPv6 Address field.
	The Location TLV MAY be used to determine the last-hop IP addresses,		The Location TLV MAY be used to determine the last-hop IP addresses,
	ports, and last-hop MAC address for STAMP packets. The MAC address		ports, and last-hop MAC address for STAMP packets. The MAC address
	can indicate a path switch on the last hop. The IP addresses and UDP		can indicate a path switch on the last hop. The IP addresses and UDP
	ports will indicate if there is a NAT router on the path. It allows		ports will indicate if there is a NAT router on the path. It allows
	the Session-Sender to identify the IP address of the Session-		the Session-Sender to identify the IP address of the Session-
	Reflector behind the NAT, and detect changes in the NAT mapping that		Reflector behind the NAT, and detect changes in the NAT mapping that
	could cause sending the STAMP packets to the wrong Session-Reflector.		could cause sending the STAMP packets to the wrong Session-Reflector.
	4.3. Timestamp Information TLV		4.3. Timestamp Information TLV
	The STAMP Session-Sender MAY include the Timestamp Information TLV to		The STAMP Session-Sender MAY include the Timestamp Information TLV to
	request information from the Session-Reflector. The Session-Sender		request information from the Session-Reflector. The Session-Sender
	SHOULD NOT fill any information fields except for STAMP TLV Flags,		MUST NOT fill any information fields except for STAMP TLV Flags,
	Type, and Length. The Session-Reflector MUST validate the Length		Type, and Length. All other fields MUST be filled with zeroes The
	value of the TLV. If the value of the Length field is invalid, the		Session-Reflector MUST validate the Length value of the TLV. If the
	Session-Reflector MUST zero all fields and MUST NOT return any		value of the Length field is invalid, the Session-Reflector follows
	information to the Session-Sender.		the procedure defined in Section 4 for a malformed TLV.
	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|Times Info 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 ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 9: Timestamp Information TLV		Figure 11: Timestamp Information TLV
	where fields are defined as the following:		where fields are defined as the following:
	o STAMP TLV Flags - is an eight-bit-long field. Its format is		o STAMP TLV Flags - is an eight-bit-long field. Its format is
	presented in Figure 6.		presented in Figure 6.
	o Timestamp Information Type - is a one-octet-long field, value TBA3		o Timestamp Information Type - is a one-octet-long field, value TBA3
	allocated by IANA Section 5.1.		allocated by IANA Section 5.1.
	o Length - two-octet-long field, set equal to the value 4.		o Length - two-octet-long field, set equal to the length of the
			Value field in octets (Figure 5).
	o Sync Src In - one-octet-long field that characterizes the source		o Sync Src In - one-octet-long field that characterizes the source
	of clock synchronization at the ingress of a Session-Reflector.		of clock synchronization at the ingress of a Session-Reflector.
	There are several methods to synchronize the clock, e.g., Network		There are several methods to synchronize the clock, e.g., Network
	Time Protocol (NTP) [RFC5905]. The value is one of those listed		Time Protocol (NTP) [RFC5905]. The value is one of those listed
	in Table 5.		in Table 7.
	o Timestamp In - one-octet-long field that characterizes the method		o Timestamp In - one-octet-long field that characterizes the method
	by which the ingress of the Session-Reflector obtained the		by which the ingress of the Session-Reflector obtained the
	timestamp T2. A timestamp may be obtained with hardware		timestamp T2. A timestamp may be obtained with hardware
	assistance, via software API from a local wall clock, or from a		assistance, via software API from a local wall clock, or from a
	remote clock (the latter is referred to as "control plane"). The		remote clock (the latter is referred to as "control plane"). The
	value is one of those listed in Table 7.		value is one of those listed in Table 9.
	o Sync Src Out - one-octet-long field that characterizes the source		o Sync Src Out - one-octet-long field that characterizes the source
	of clock synchronization at the egress of the Session-Reflector.		of clock synchronization at the egress of the Session-Reflector.
	The value is one of those listed in Table 5.		The value is one of those listed in Table 7.
	o Timestamp Out - one-octet-long field that characterizes the method		o Timestamp Out - one-octet-long field that characterizes the method
	by which the egress of the Session-Reflector obtained the		by which the egress of the Session-Reflector obtained the
	timestamp T3. The value is one of those listed in Table 7.		timestamp T3. The value is one of those listed in Table 9.
			o Optional sub-TLVs - optional variable-length field.
	4.4. Class of Service TLV		4.4. Class of Service TLV
	The STAMP Session-Sender MAY include a Class of Service (CoS) TLV in		The STAMP Session-Sender MAY include a Class of Service (CoS) TLV in
	the STAMP test packet. The format of the CoS TLV is presented in		the STAMP test packet. The format of the CoS TLV is presented in
	Figure 10.		Figure 12.
	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| CoS Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DSCP1 | DSCP2 |ECN| Reserved |		| DSCP1 | DSCP2 |ECN| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 10: Class of Service TLV		Figure 12: Class of Service TLV
	where fields are defined as the following:		where fields are defined as the following:
	o STAMP TLV Flags - is an eight-bit-long field. Its format is		o STAMP TLV Flags - is an eight-bit-long field. Its format is
	presented in Figure 6.		presented in Figure 6.
	o CoS (Class of Service) Type - is a one-octet-long field, value		o CoS (Class of Service) Type - is a one-octet-long field, value
	TBA4 allocated by IANA Section 5.1.		TBA4 allocated by IANA Section 5.1.
	o Length - two-octet-long field, set equal to the value 4.		o Length - two-octet-long field, set equal to the value 4.
	o DSCP1 - The Differentiated Services Code Point (DSCP) intended by		o DSCP1 - The Differentiated Services Code Point (DSCP) intended by
	the Session-Sender to be used as the DSCP value of the reflected		the Session-Sender to be used as the DSCP value of the reflected
	test packet.		test packet.
	o DSCP2 - The received value in the DSCP field at the Session-		o DSCP2 - The received value in the DSCP field at the ingress of the
	Reflector in the forward direction.		Session-Reflector.
	o ECN - The received value in the ECN field at the Session-Reflector		o ECN - The received value in the ECN field at the ingress of the
	in the forward direction.		Session-Reflector.
	o Reserved - 18-bit-long field, MUST be zeroed on transmission and		o Reserved - 18-bit-long field, MUST be zeroed on transmission and
	ignored on receipt.		ignored on receipt.
	A STAMP Session-Reflector that receives a test packet with the CoS		A STAMP Session-Reflector that receives a test packet with the CoS
	TLV MUST include the CoS TLV in the reflected test packet. Also, the		TLV MUST include the CoS TLV in the reflected test packet. Also, the
	Session-Reflector MUST copy the value of the DSCP and ECN fields of		Session-Reflector MUST copy the value of the DSCP and ECN fields of
	the IP header of the received STAMP test packet into the DSCP2 field		the IP header of the received STAMP test packet into the DSCP2 field
	in the reflected test packet. Finally, the Session-Reflector MUST		in the reflected test packet. Finally, the Session-Reflector MUST
	set the DSCP field's value in the IP header of the reflected test		set the DSCP field's value in the IP header of the reflected test
	skipping to change at page 15, line 41 ¶		skipping to change at page 18, line 28 ¶
	it is misconfigured, then it is often difficult to diagnose the root		it is misconfigured, then it is often difficult to diagnose the root
	cause of excessive packet drops of higher-level service while packet		cause of excessive packet drops of higher-level service while packet
	drops for lower service packets are at a normal level. Using a CoS		drops for lower service packets are at a normal level. Using a CoS
	TLV in STAMP testing helps to troubleshoot the existing problem and		TLV in STAMP testing helps to troubleshoot the existing problem and
	also verify whether DiffServ policies are processing CoS as required		also verify whether DiffServ policies are processing CoS as required
	by the configuration.		by the configuration.
	4.5. Direct Measurement TLV		4.5. Direct Measurement TLV
	The Direct Measurement TLV enables collection of the number of in-		The Direct Measurement TLV enables collection of the number of in-
	profile packets that had been transmitted and received by the		profile packets, i.e., packets that form a specific data flow, that
	Session-Sender and Session-Reflector, respectively. The definition		had been transmitted and received by the Session-Sender and Session-
	of "in-profile packet" is outside the scope of this document and is		Reflector, respectively. The definition of "in-profile packet" is
	left to the test operators to determine.		outside the scope of this document and is left to the test operators
			to determine.
	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| Direct 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) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 11: Direct Measurement TLV		Figure 13: Direct Measurement TLV
	where fields are defined as the following:		where fields are defined as the following:
	o STAMP TLV Flags - is an eight-bit-long field. Its format is		o STAMP TLV Flags - is an eight-bit-long field. Its format is
	presented in Figure 6.		presented in Figure 6.
	o Direct (Measurement) Type - is a one-octet-long field, value TBA5		o Direct (Measurement) Type - is a one-octet-long field, value TBA5
	allocated by IANA Section 5.1.		allocated by IANA Section 5.1.
	o Length - two-octet-long field equals length of the Value field in		o Length - two-octet-long field equals the length of the Value field
	octets. The Length field value MUST equal 12 octets.		in octets. The Length field value MUST equal 12 octets.
	o Session-Sender Tx counter (S_TxC) is a four-octet-long field. The		o Session-Sender Tx counter (S_TxC) is a four-octet-long field. The
	Session-Sender MUST set its value equal to the number of the		Session-Sender MUST set its value equal to the number of the
	transmitted in-profile packets.		transmitted in-profile packets.
	o Session-Reflector Rx counter (R_RxC) is a four-octet-long field.		o Session-Reflector Rx counter (R_RxC) is a four-octet-long field.
	MUST be zeroed by the Session-Sender on transmit and ignored by		MUST be zeroed by the Session-Sender on transmit and ignored by
	the Session-Reflector on receipt. The Session-Reflector MUST fill		the Session-Reflector on receipt. The Session-Reflector MUST fill
	it with the value of in-profile packets received.		it with the value of in-profile packets received.
	o Session-Reflector Tx counter (R_TxC) is a four-octet-long field.		o Session-Reflector Tx counter (R_TxC) is a four-octet-long field.
	MUST be zeroed by the Session-Sender and ignored by the Session-		MUST be zeroed by the Session-Sender and ignored by the Session-
	Reflector on receipt. The Session-Reflector MUST fill it with the		Reflector on receipt. The Session-Reflector MUST fill it with the
	value of the transmitted in-profile packets.		value of the transmitted in-profile packets.
	A Session-Sender MAY include the Direct Measurement TLV in a STAMP		A Session-Sender MAY include the Direct Measurement TLV in a STAMP
	test packet. The Session-Sender MUST zero the R_RxC and R_TxC fields		test packet. If the received STAMP test packet includes the Direct
	before the transmission of the STAMP test packet. If the received		Measurement TLV, the Session-Reflector MUST include it in the
	STAMP test packet includes the Direct Measurement TLV, the Session-		reflected test packet. The Session-Reflector MUST copy the value
	Reflector MUST include it in the reflected test packet. The Session-		from the S_TxC field of the received test packet into the same field
	Reflector MUST copy the value from the S_TxC field of the received		of the reflected packet before its transmission.
	test packet into the same field of the reflected packet before its
	transmission.
	4.6. Access Report TLV		4.6. Access Report TLV
	A STAMP Session-Sender MAY include an Access Report TLV (Figure 12)		A STAMP Session-Sender MAY include an Access Report TLV (Figure 14)
	to indicate changes to the access network status to the Session-		to indicate changes to the access network status to the Session-
	Reflector. The definition of an access network is outside the scope		Reflector. The definition of an access network is outside the scope
	of this document.		of this document.
	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|Acc Report Type| Length |		|STAMP TLV Flags|Acc Report Type| Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ID | Resv | Return Code | Reserved |		| ID | Resv | Return Code | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 12: Access Report TLV		Figure 14: Access Report TLV
	where fields are defined as follows:		where fields are defined as follows:
	o STAMP TLV Flags - is an eight-bit-long field. Its format		o STAMP TLV Flags - is an eight-bit-long field. Its format
	presented in Figure 6.		presented in Figure 6.
	o Access Report Type - is a one-octet-long field, value TBA6		o Access Report Type - is a one-octet-long field, value TBA6
	allocated by IANA Section 5.1.		allocated by IANA Section 5.1.
	o Length - two-octet-long field, set equal to the value 4.		o Length - two-octet-long field, set equal to the value 4.
	skipping to change at page 17, line 51 ¶		skipping to change at page 20, line 29 ¶
	All other values are invalid and the TLV that contains it MUST be		All other values are invalid and the TLV that contains it MUST be
	discarded.		discarded.
	o Resv - four-bit-long field, MUST be zeroed on transmission and		o Resv - four-bit-long field, MUST be zeroed on transmission and
	ignored on receipt.		ignored on receipt.
	o Return Code - one-octet-long field that identifies the report		o Return Code - one-octet-long field that identifies the report
	signal, e.g., available or unavailable. The value is supplied to		signal, e.g., available or unavailable. The value is supplied to
	the STAMP end-point through some mechanism that is outside the		the STAMP end-point through some mechanism that is outside the
	scope of this document. The value is one of those listed in		scope of this document. The value is one of those listed in
	Section 5.5.		Section 5.6.
	o Reserved - two-octet-long field, MUST be zeroed on transmission		o Reserved - two-octet-long field, MUST be zeroed on transmission
	and ignored on receipt.		and ignored on receipt.
	The STAMP Session-Sender that includes the Access Report TLV sets the		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		value of the Access ID field according to the type of access network
	it reports on. Also, the Session-Sender sets the value of the Return		it reports on. Also, the Session-Sender sets the value of the Return
	Code field to reflect the operational state of the access network.		Code field to reflect the operational state of the access network.
	The mechanism to determine the state of the access network is outside		The mechanism to determine the state of the access network is outside
	the scope of this specification. A STAMP Session-Reflector that		the scope of this specification. A STAMP Session-Reflector that
	skipping to change at page 18, line 42 ¶		skipping to change at page 21, line 19 ¶
	The Access Report TLV is used by the Performance Measurement Function		The Access Report TLV is used by the Performance Measurement Function
	(PMF) components of the Access Steering, Switching and Splitting		(PMF) components of the Access Steering, Switching and Splitting
	feature for 5G networks [TS23501]. The PMF component in the User		feature for 5G networks [TS23501]. The PMF component in the User
	Equipment acts as the STAMP Session-Sender, and the PMF component in		Equipment acts as the STAMP Session-Sender, and the PMF component in
	the User Plane Function acts as the STAMP Session-Reflector.		the User Plane Function acts as the STAMP Session-Reflector.
	4.7. Follow-up Telemetry TLV		4.7. Follow-up Telemetry TLV
	A Session-Reflector might be able to put in the Timestamp field only		A Session-Reflector might be able to put in the Timestamp field only
	an "SW Local" (see Table 7) timestamp. But the hosting system might		an "SW Local" (see Table 9) timestamp. But the hosting system might
	provide a timestamp closer to the start of the actual packet		provide a timestamp closer to the start of the actual packet
	transmission even though it is not possible to deliver the		transmission even though it is not possible to deliver the
	information to the Session-Sender in time for the packet itself.		information to the Session-Sender in time for the packet itself.
	This timestamp might nevertheless be important for the Session-		This timestamp might nevertheless be important for the Session-
	Sender, as it improves the accuracy of measuring network delay by		Sender, as it improves the accuracy of measuring network delay by
	minimizing the impact of egress queuing delays on the measurement.		minimizing the impact of egress queuing delays on the measurement.
	A STAMP Session-Sender MAY include the Follow-up Telemetry TLV to		A STAMP Session-Sender MAY 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		MUST set the Follow-up Telemetry Type and Length fields to their
	appropriate values. The Sequence Number and Timestamp fields MUST be		appropriate values. The Sequence Number and Timestamp fields MUST be
	zeroed on transmission by the Session-Sender and ignored by the		zeroed on transmission by the Session-Sender and ignored by the
	Session-Reflector upon receipt of the STAMP test packet that includes		Session-Reflector upon receipt of the STAMP test packet that includes
	the Follow-up Telemetry TLV. The Session-Reflector MUST validate the		the Follow-up Telemetry TLV. The Session-Reflector MUST validate the
	Length value of the STAMP test packet. If the value of the Length		Length value of the STAMP test packet. If the value of the Length
	field is invalid, the Session-Reflector MUST zero the Sequence Number		field is invalid, the Session-Reflector MUST zero the Sequence Number
	and Timestamp fields and set the L flag in the STAMP TLV Flags field		and Timestamp fields and set the M flag in the STAMP TLV Flags field
	in the reflected packet. If the Session-Reflector is in stateless		in the reflected packet. If the Session-Reflector is in stateless
	mode (defined in Section 4.2 [RFC8762]), it MUST zero the Sequence		mode (defined in Section 4.2 [RFC8762]), it MUST zero the Sequence
	Number and Timestamp fields.		Number and Timestamp fields.
	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| Follow-up Type| Length |		|STAMP TLV Flags| Follow-up Type| Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number |		| Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Follow-up Timestamp |		| Follow-up Timestamp |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Timestamp M | Reserved |		| Timestamp M | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 13: Follow-up Telemetry TLV		Figure 15: Follow-up Telemetry TLV
	where fields are defined as follows:		where fields are defined as follows:
	o STAMP TLV Flags - is an eight-bit-long field. Its format		o STAMP TLV Flags - is an eight-bit-long field. Its format
	presented in Figure 6.		presented in Figure 6.
	o Follow-up (Telemetry) Type - is a one-octet-long field, value TBA7		o Follow-up (Telemetry) Type - is a one-octet-long field, value TBA7
	allocated by IANA Section 5.1.		allocated by IANA Section 5.1.
	o Length - two-octet-long field, set equal to the value 16 octets.		o Length - two-octet-long field, set equal to the value 16 octets.
	o Sequence Number - four-octet-long field indicating the sequence		o Sequence Number - four-octet-long field indicating the sequence
	number of the last packet reflected in the same STAMP-test		number of the last packet reflected in the same STAMP-test
	session. Since the Session-Reflector runs in the stateful mode		session. Since the Session-Reflector runs in the stateful mode
	(defined in Section 4.2 [RFC8762]), it is the Session-Reflector's		(defined in Section 4.2 [RFC8762]), it is the Session-Reflector's
	Sequence Number of the previous reflected packet.		Sequence Number of the previous reflected packet.
	o Follow-up Timestamp - eight-octet-long field, with the format		o Follow-up Timestamp - eight-octet-long field, with the format
	indicated by the Z flag of the Error Estimate field of the packet		indicated by the Z flag of the Error Estimate field of the STAMP
	transmitted by a Session-Reflector, as described in Section 4.1		base packet, which is contained in this reflected test packet
			transmitted by a Session-Reflector, as described in Section 4.2.1
	[RFC8762]. It carries the timestamp when the reflected packet		[RFC8762]. It carries the timestamp when the reflected packet
	with the specified sequence number was sent.		with the specified sequence number was sent.
	o Timestamp M(ode) - one-octet-long field that characterizes the		o Timestamp M(ode) - one-octet-long field that characterizes the
	method by which the entity that transmits a reflected STAMP packet		method by which the entity that transmits a reflected STAMP packet
	obtained the Follow-up Timestamp. The value is one of those		obtained the Follow-up Timestamp. The value is one of those
	listed in Table 7.		listed in Table 9.
	o Reserved - three-octet-long field. Its value MUST be zeroed on		o Reserved - three-octet-long field. Its value MUST be zeroed on
	transmission and ignored on receipt.		transmission and ignored on receipt.
	4.8. HMAC TLV		4.8. HMAC TLV
	The STAMP authenticated mode protects the integrity of data collected		The STAMP authenticated mode protects the integrity of data collected
	in the STAMP base packet. STAMP extensions are designed to provide		in the STAMP base packet. STAMP extensions are designed to provide
	valuable information about the condition of a network, and protecting		valuable information about the condition of a network, and protecting
	the integrity of that data is also essential. The keyed Hashed		the integrity of that data is also essential. All authenticated
	Message Authentication Code (HMAC) TLV MUST be included in a STAMP		STAMP base packets (per Section 4.2.2 and Section 4.3.2 [RFC8762])
	test packet in the authenticated mode, excluding when the only TLV		compatible with this specification MUST additionally authenticate the
	present is Extra Padding TLV. The HMAC TLV MUST follow all TLVs		option TLVs by including the keyed Hashed Message Authentication Code
	included in a STAMP test packet, except for the Extra Padding TLV.		(HMAC) TLV, with the sole exception of when there is only one TLV
			present, and it is 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 appears in any other position in a
			STAMP extended test packet, then the situation MUST be processed as
			HMAC verification failure, as defined in this section, further below.
	The HMAC TLV MAY be used to protect the integrity of STAMP extensions		The HMAC TLV MAY be used to protect the integrity of STAMP extensions
	in STAMP unauthenticated mode.		in STAMP unauthenticated mode. An implementation of STAMP extensions
			MUST provide controls to enable the integrity protection of STAMP
			extensions in STAMP unauthenticated mode.
	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| HMAC Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| HMAC |		| HMAC |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 14: HMAC TLV		Figure 16: HMAC TLV
	where fields are defined as follows:		where fields are defined as follows:
	o STAMP TLV Flags - is an eight-bit-long field. Its format is		o STAMP TLV Flags - is an eight-bit-long field. Its format is
	presented in Figure 6.		presented in Figure 6.
	o HMAC Type - is a one-octet-long field, value TBA8 allocated by		o HMAC Type - is a one-octet-long field, value TBA8 allocated by
	IANA Section 5.1.		IANA Section 5.1.
	o Length - two-octet-long field, set equal to 16 octets.		o Length - two-octet-long field, set equal to 16 octets.
	o HMAC - is a 16-octet-long field that carries HMAC digest of the		o HMAC - is a 16-octet-long field that carries HMAC digest of the
	text of all preceding TLVs.		text of all preceding TLVs.
	As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128		As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128
	bits ([RFC4868]). All considerations regarding using the key and key		bits ([RFC4868]). All considerations regarding using the key and key
	distribution and management listed in Section 4.4 of [RFC8762] are		distribution and management listed in Section 4.4 of [RFC8762] are
	fully applicable to the use of the HMAC TLV. HMAC is calculated as		fully applicable to the use of the HMAC TLV. HMAC TLV is anticipated
	defined in [RFC2104] over text as the concatenation of all preceding		to track updates in the base STAMP protocol [RFC8762], including the
	TLVs. The digest then MUST be truncated to 128 bits and written into		use of more advanced cryptographic algorithms. HMAC is calculated as
	the HMAC field. In the authenticated mode, HMAC MUST be verified		defined in [RFC2104] over text as the concatenation of the Sequence
	before using any data in the included STAMP TLVs. If HMAC		Number field of the base STAMP packet and all preceding TLVs. The
	verification by the Session-Reflector fails, then the Session-		digest then MUST be truncated to 128 bits and written into the HMAC
	Reflector MUST stop processing the received extended STAMP test		field. If the HMAC TLV is present in the extended STAMP test packet,
	packet. The Session-Reflector MUST copy the remainder of the		e.g., in the authenticated mode, HMAC MUST be verified before using
	extended STAMP test packet into the reflected packet. The Session-		any data in the included STAMP TLVs. If HMAC verification by the
	Reflector MUST set the A flag in the copy of the HMAC TLV in the		Session-Reflector fails, then the Session-Reflector MUST stop
	reflected packet to 1 before transmitting the reflected test packet.		processing the received extended STAMP test packet. The Session-
	Also, both the Session-Sender and Session-Reflector SHOULD log the		Reflector MUST copy the TLVs from the received STAMP test packet into
	notification that HMAC verification of STAMP TLVs failed.		the reflected packet. The Session-Reflector MUST set the I flag in
			each TLV copied over into 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, then
			the Session-Sender MUST stop processing TLVs in the reflected test
			packet. If HMAC verification by the Session-Sender fails, then the
			Session-Sender MUST stop processing TLVs in the reflected extended
			STAMP packet.
	5. IANA Considerations		5. IANA Considerations
	5.1. STAMP TLV Registry		5.1. STAMP TLV Registry
	IANA is requested to create the STAMP TLV Type registry. All code		IANA is requested to create the STAMP TLV Type registry. All code
	points in the range 1 through 175 in this registry shall be allocated		points in the range 1 through 175 in this registry shall be allocated
	according to the "IETF Review" procedure as specified in [RFC8126].		according to the "IETF Review" procedure as specified in [RFC8126].
	Code points in the range 176 through 239 in this registry shall be		Code points in the range 176 through 239 in this registry shall be
	allocated according to the "First Come First Served" procedure as		allocated according to the "First Come First Served" procedure as
	specified in [RFC8126]. The remaining code points are allocated		specified in [RFC8126]. The remaining code points are allocated
	according to Table 1:		according to Table 1:
	+-----------+--------------+-------------------------+		+-----------+--------------+---------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-----------+--------------+-------------------------+		+-----------+--------------+---------------+
	| 0 | Reserved | This document |		| 0 | Reserved | This document |
	| 1- 175 | Unassigned | IETF Review |		| 1- 175 | Unassigned | This document |
	| 176 - 239 | Unassigned | First Come First Served |		| 176 - 239 | Unassigned | This document |
	| 240 - 251 | Experimental | This document |		| 240 - 251 | Experimental | This document |
	| 252 - 254 | Private Use | This document |		| 252 - 254 | Private Use | This document |
	| 255 | Reserved | This document |		| 255 | Reserved | This document |
	+-----------+--------------+-------------------------+		+-----------+--------------+---------------+
	Table 1: STAMP TLV Type Registry		Table 1: STAMP TLV Type Registry
	This document defines the following new values in the STAMP Extension		This document defines the following new values in the IETF Review
	TLV range of the STAMP TLV Type registry:		range of the STAMP TLV Type registry:
	+-------+-----------------------+---------------+		+-------+-----------------------+---------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+-----------------------+---------------+		+-------+-----------------------+---------------+
	| TBA1 | Extra Padding | This document |		| TBA1 | Extra Padding | This document |
	| TBA2 | Location | This document |		| TBA2 | Location | This document |
	| TBA3 | Timestamp Information | This document |		| TBA3 | Timestamp Information | This document |
	| TBA4 | Class of Service | This document |		| TBA4 | Class of Service | This document |
	| TBA5 | Direct Measurement | This document |		| TBA5 | Direct Measurement | This document |
	| TBA6 | Access Report | This document |		| TBA6 | Access Report | This document |
	| TBA7 | Follow-up Telemetry | This document |		| TBA7 | Follow-up Telemetry | This document |
	| TBA8 | HMAC | This document |		| TBA8 | HMAC | This document |
	+-------+-----------------------+---------------+		+-------+-----------------------+---------------+
	Table 2: STAMP Types		Table 2: STAMP TLV Types
	5.2. STAMP TLV Flags Sub-registry		5.2. STAMP TLV Flags Sub-registry
	IANA is requested to create the STAMP TLV Flags sub-registry as part		IANA is requested to create the STAMP TLV Flags sub-registry as part
	of the STAMP TLV Type registry. The registration procedure is "IETF		of the STAMP TLV Type registry. The registration procedure is "IETF
	Review" [RFC8126]. Flags are 8 bits. This document defines the		Review" [RFC8126]. Flags are 8 bits. This document defines the
	following bit positions in the STAMP TLV Flags sub-registry:		following bit positions in the STAMP TLV Flags sub-registry:
	+--------------+--------+-----------------------+---------------+		+--------------+--------+------------------------+---------------+
	| Bit position | Symbol | Description | Reference |		| Bit position | Symbol | Description | Reference |
	+--------------+--------+-----------------------+---------------+		+--------------+--------+------------------------+---------------+
	| 0 | U | Unrecognized TLV | This document |		| 0 | U | Unrecognized TLV | This document |
	| 1 | L | Malformed TLV | This document |		| 1 | M | Malformed TLV | This document |
	| 2 | A | Authentication failed | This document |		| 2 | I | Integrity check failed | This document |
	+--------------+--------+-----------------------+---------------+		+--------------+--------+------------------------+---------------+
	Table 3: STAMP TLV Flags		Table 3: STAMP TLV Flags
	5.3. Synchronization Source Sub-registry		5.3. Sub-TLV Type Sub-registry
			IANA is requested to create the sub-TLV Type sub-registry as part of
			the STAMP TLV Type registry. All code points in the range 1 through
			175 in this registry shall be allocated according to the "IETF
			Review" procedure as specified in [RFC8126]. 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 [RFC8126].
			The remaining code points are allocated according to Table 4:
			+-----------+--------------+---------------+
			| Value | Description | Reference |
			+-----------+--------------+---------------+
			| 0 | Reserved | This document |
			| 1- 175 | Unassigned | This document |
			| 176 - 239 | Unassigned | This document |
			| 240 - 251 | Experimental | This document |
			| 252 - 254 | Private Use | This document |
			| 255 | Reserved | This document |
			+-----------+--------------+---------------+
			Table 4: Location Sub-TLV Type Sub-registry
			This document defines the following new values in the IETF Review
			range of the Location sub-TLV Type sub-registry:
			+-------+--------------------------+----------+---------------+
			| Value | Description | TLV Used | Reference |
			+-------+--------------------------+----------+---------------+
			| TBA9 | Source MAC Address | Location | This document |
			| TBA10 | Source EUI-48 Address | Location | This document |
			| TBA11 | Source EUI-64 Address | Location | This document |
			| TBA12 | Destination IP Address | Location | This document |
			| TBA13 | Destination IPv4 Address | Location | This document |
			| TBA14 | Destination IPv6 Address | Location | This document |
			| TBA15 | Source IP Address | Location | This document |
			| TBA16 | Source IPv4 Address | Location | This document |
			| TBA17 | Source IPv6 Address | Location | This document |
			+-------+--------------------------+----------+---------------+
			Table 5: STAMP sub-TLV Types
			5.4. Synchronization Source Sub-registry
	IANA is requested to create the Synchronization Source sub-registry		IANA is requested to create the Synchronization Source sub-registry
	as part of the STAMP TLV Type registry. All code points in the range		as part of the STAMP TLV Type registry. All code points in the range
	1 through 127 in this registry shall be allocated according to the		1 through 127 in this registry shall be allocated according to the
	"IETF Review" procedure as specified in [RFC8126]. Code points in		"IETF Review" procedure as specified in [RFC8126]. Code points in
	the range 128 through 239 in this registry shall be allocated		the range 128 through 239 in this registry shall be allocated
	according to the "First Come First Served" procedure as specified in		according to the "First Come First Served" procedure as specified in
	[RFC8126]. Remaining code points are allocated according to Table 4:		[RFC8126]. Remaining code points are allocated according to Table 6:
	+-----------+--------------+-------------------------+		+-----------+--------------+---------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-----------+--------------+-------------------------+		+-----------+--------------+---------------+
	| 0 | Reserved | This document |		| 0 | Reserved | This document |
	| 1- 127 | Unassigned | IETF Review |		| 1- 127 | Unassigned | This document |
	| 128 - 239 | Unassigned | First Come First Served |		| 128 - 239 | Unassigned | This document |
	| 240 - 249 | Experimental | This document |		| 240 - 249 | Experimental | This document |
	| 250 - 254 | Private Use | This document |		| 250 - 254 | Private Use | This document |
	| 255 | Reserved | This document |		| 255 | Reserved | This document |
	+-----------+--------------+-------------------------+		+-----------+--------------+---------------+
	Table 4: Synchronization Source Sub-registry		Table 6: Synchronization Source Sub-registry
	This document defines the following new values in the Synchronization		This document defines the following new values in the Synchronization
	Source sub-registry:		Source sub-registry:
	+-------+-------------------------+---------------+		+-------+---------------------------------+---------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+-------------------------+---------------+		+-------+---------------------------------+---------------+
	| 1 | NTP | This document |		| 1 | NTP | This document |
	| 2 | PTP | This document |		| 2 | PTP | This document |
	| 3 | SSU/BITS | This document |		| 3 | SSU/BITS | This document |
	| 4 | GPS/GLONASS/LORAN-C/BDS | This document |		| 4 | GPS/GLONASS/LORAN-C/BDS/Galileo | This document |
	| 5 | Local free-running | This document |		| 5 | Local free-running | This document |
	+-------+-------------------------+---------------+		+-------+---------------------------------+---------------+
	Table 5: Synchronization Sources		Table 7: Synchronization Sources
	5.4. Timestamping Method Sub-registry		5.5. Timestamping Method Sub-registry
	IANA is requested to create the Timestamping Method sub-registry as		IANA is requested to create the Timestamping Method sub-registry as
	part of the STAMP TLV Type registry. All code points in the range 1		part of the STAMP TLV Type registry. All code points in the range 1
	through 127 in this registry shall be allocated according to the		through 127 in this registry shall be allocated according to the
	"IETF Review" procedure as specified in [RFC8126]. Code points in		"IETF Review" procedure as specified in [RFC8126]. Code points in
	the range 128 through 239 in this registry shall be allocated		the range 128 through 239 in this registry shall be allocated
	according to the "First Come First Served" procedure as specified in		according to the "First Come First Served" procedure as specified in
	[RFC8126]. Remaining code points are allocated according to Table 6:		[RFC8126]. Remaining code points are allocated according to Table 8:
	+-----------+--------------+-------------------------+		+-----------+--------------+---------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-----------+--------------+-------------------------+		+-----------+--------------+---------------+
	| 0 | Reserved | This document |		| 0 | Reserved | This document |
	| 1- 127 | Unassigned | IETF Review |		| 1- 127 | Unassigned | This document |
	| 128 - 239 | Unassigned | First Come First Served |		| 128 - 239 | Unassigned | This document |
	| 240 - 249 | Experimental | This document |		| 240 - 249 | Experimental | This document |
	| 250 - 254 | Private Use | This document |		| 250 - 254 | Private Use | This document |
	| 255 | Reserved | This document |		| 255 | Reserved | This document |
	+-----------+--------------+-------------------------+		+-----------+--------------+---------------+
	Table 6: Timestamping Method Sub-registry		Table 8: Timestamping Method Sub-registry
	This document defines the following new values in the Timestamping		This document defines the following new values in the Timestamping
	Methods sub-registry:		Methods sub-registry:
	+-------+---------------+---------------+		+-------+---------------+---------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+---------------+---------------+		+-------+---------------+---------------+
	| 1 | HW Assist | This document |		| 1 | HW Assist | This document |
	| 2 | SW local | This document |		| 2 | SW local | This document |
	| 3 | Control plane | This document |		| 3 | Control plane | This document |
	+-------+---------------+---------------+		+-------+---------------+---------------+
	Table 7: Timestamping Methods		Table 9: Timestamping Methods
	5.5. Return Code Sub-registry		5.6. Return Code Sub-registry
	IANA is requested to create the Return Code sub-registry as part of		IANA is requested to create the Return Code sub-registry as part of
	the STAMP TLV Type registry. All code points in the range 1 through		the STAMP TLV Type registry. All code points in the range 1 through
	127 in this registry shall be allocated according to the "IETF		127 in this registry shall be allocated according to the "IETF
	Review" procedure as specified in [RFC8126]. Code points in the		Review" procedure as specified in [RFC8126]. Code points in the
	range 128 through 239 in this registry shall be allocated according		range 128 through 239 in this registry shall be allocated according
	to the "First Come First Served" procedure as specified in [RFC8126].		to the "First Come First Served" procedure as specified in [RFC8126].
	Remaining code points are allocated according to Table 8:		Remaining code points are allocated according to Table 10:
	+-----------+--------------+-------------------------+		+-----------+--------------+---------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-----------+--------------+-------------------------+		+-----------+--------------+---------------+
	| 0 | Reserved | This document |		| 0 | Reserved | This document |
	| 1- 127 | Unassigned | IETF Review |		| 1- 127 | Unassigned | This document |
	| 128 - 239 | Unassigned | First Come First Served |		| 128 - 239 | Unassigned | This document |
	| 240 - 249 | Experimental | This document |		| 240 - 249 | Experimental | This document |
	| 250 - 254 | Private Use | This document |		| 250 - 254 | Private Use | This document |
	| 255 | Reserved | This document |		| 255 | Reserved | This document |
	+-----------+--------------+-------------------------+		+-----------+--------------+---------------+
	Table 8: Return Code Sub-registry		Table 10: Return Code Sub-registry
	This document defines the following new values in the Return Code		This document defines the following new values in the Return Code
	sub-registry:		sub-registry:
	+-------+---------------------+---------------+		+-------+---------------------+---------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+---------------------+---------------+		+-------+---------------------+---------------+
	| 1 | Network available | This document |		| 1 | Network available | This document |
	| 2 | Network unavailable | This document |		| 2 | Network unavailable | This document |
	+-------+---------------------+---------------+		+-------+---------------------+---------------+
	Table 9: Return Codes		Table 11: Return Codes
	6. Security Considerations		6. Security Considerations
	This document defines extensions to STAMP [RFC8762] and inherits all		This document defines extensions to STAMP [RFC8762] and inherits all
	the security considerations applicable to the base protocol.		the security considerations applicable to the base protocol.
	Additionally, the HMAC TLV is defined in this document to protect the		Additionally, the HMAC TLV is defined in this document to protect the
	integrity of optional STAMP extensions. The use of HMAC TLV is		integrity of optional STAMP extensions. The use of HMAC TLV is
	discussed in detail in Section 4.8.		discussed in detail in Section 4.8.
			To protect against a malformed TLV an implementation of a Session-
			Sender and Session-Reflector MUST:
			o check the setting of the M flag;
			o validate the Length field value.
			Monitoring and optional control of DSCP do not appear to introduce
			any additional security threat to hosts that communicate with STAMP
			as defined in [RFC8762]. As this specification defined the mechanism
			to test DSCP mapping, this document inherits all the security
			considerations discussed in [RFC2474].
	7. Acknowledgments		7. Acknowledgments
	Authors much appreciate the thorough review and thoughtful comments		Authors much appreciate the thorough review and thoughtful comments
	received from Tianran Zhou, Rakesh Gandhi, Yuezhong Song and Yali		received from Tianran Zhou, Rakesh Gandhi, Yuezhong Song and Yali
	Wang. The authors express their gratitude to Al Morton for his		Wang. The authors express their gratitude to Al Morton for his
	comments and the most valuable suggestions. The authors greatly		comments and the most valuable suggestions. The authors greatly
	appreciate comments and thoughtful suggestions received from Martin		appreciate comments and thoughtful suggestions received from Martin
	Duke.		Duke.
	8. Contributors		8. Contributors
	skipping to change at page 26, line 4 ¶		skipping to change at page 30, line 15 ¶
	Guo Jun		Guo Jun
	ZTE Corporation		ZTE Corporation
	68# Zijinghua Road		68# Zijinghua Road
	Nanjing, Jiangsu 210012		Nanjing, Jiangsu 210012
	P.R.China		P.R.China
	Phone: +86 18105183663		Phone: +86 18105183663
	Email: guo.jun2@zte.com.cn		Email: guo.jun2@zte.com.cn
	9. References		9. References
	9.1. Normative References		9.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		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple		[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
	Two-Way Active Measurement Protocol", RFC 8762,		Two-Way Active Measurement Protocol", RFC 8762,
	DOI 10.17487/RFC8762, March 2020,		DOI 10.17487/RFC8762, March 2020,
	<https://www.rfc-editor.org/info/rfc8762>.		<https://www.rfc-editor.org/info/rfc8762>.
	[TS23501] 3GPP (3rd Generation Partnership Project), "Technical
	Specification Group Services and System Aspects; System
	Architecture for the 5G System; Stage 2 (Release 16)",
	3GPP TS23501, 2019.
	9.2. Informative References		9.2. Informative References
	[GPS] "Global Positioning System (GPS) Standard Positioning		[GPS] "Global Positioning System (GPS) Standard Positioning
	Service (SPS) Performance Standard", GPS SPS 5th Edition,		Service (SPS) Performance Standard", GPS SPS 5th Edition,
	April 2020.		April 2020.
			[I-D.gont-numeric-ids-generation]
			Gont, F. and I. Arce, "On the Generation of Transient
			Numeric Identifiers", draft-gont-numeric-ids-generation-04
			(work in progress), July 2019.
	[IEEE.1588.2008]		[IEEE.1588.2008]
	"Standard for a Precision Clock Synchronization Protocol		"Standard for a Precision Clock Synchronization Protocol
	for Networked Measurement and Control Systems",		for Networked Measurement and Control Systems",
	IEEE Standard 1588, March 2008.		IEEE Standard 1588, March 2008.
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
	Hashing for Message Authentication", RFC 2104,		"Definition of the Differentiated Services Field (DS
	DOI 10.17487/RFC2104, February 1997,		Field) in the IPv4 and IPv6 Headers", RFC 2474,
	<https://www.rfc-editor.org/info/rfc2104>.		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-		[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
	384, and HMAC-SHA-512 with IPsec", RFC 4868,		384, and HMAC-SHA-512 with IPsec", RFC 4868,
	DOI 10.17487/RFC4868, May 2007,		DOI 10.17487/RFC4868, May 2007,
	<https://www.rfc-editor.org/info/rfc4868>.		<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,		[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
	"Network Time Protocol Version 4: Protocol and Algorithms		"Network Time Protocol Version 4: Protocol and Algorithms
	Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,		Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
	<https://www.rfc-editor.org/info/rfc5905>.		<https://www.rfc-editor.org/info/rfc5905>.
			[TS23501] 3GPP (3rd Generation Partnership Project), "Technical
			Specification Group Services and System Aspects; System
			Architecture for the 5G System; Stage 2 (Release 16)",
			3GPP TS23501, 2019.
	Authors' Addresses		Authors' Addresses
	Greg Mirsky		Greg Mirsky
	ZTE Corp.		ZTE Corp.
	Email: gregimirsky@gmail.com		Email: gregimirsky@gmail.com
	Xiao Min		Xiao Min
	ZTE Corp.		ZTE Corp.
End of changes. 91 change blocks.
	269 lines changed or deleted		493 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/