draft-ietf-ippm-stamp-option-tlv-04.txt		draft-ietf-ippm-stamp-option-tlv-05.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: September 23, 2020 Accedian Networks		Expires: December 14, 2020 Accedian Networks
	R. Foote		R. Foote
	Nokia		Nokia
	A. Masputra		A. Masputra
	Apple Inc.		Apple Inc.
	E. Ruffini		E. Ruffini
	OutSys		OutSys
	March 22, 2020		June 12, 2020
	Simple Two-way Active Measurement Protocol Optional Extensions		Simple Two-way Active Measurement Protocol Optional Extensions
	draft-ietf-ippm-stamp-option-tlv-04		draft-ietf-ippm-stamp-option-tlv-05
	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) which enable measurement performance		Measurement Protocol (STAMP) which enable measurement performance
	metrics in addition to ones supported by the STAMP base		metrics in addition to ones supported by the STAMP base
	specification. The document also defines a STAMP Test Session		specification. The document also defines a STAMP Test Session
	Identifier and thus updates RFC 8762.		Identifier and thus updates RFC 8762.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 September 23, 2020.		This Internet-Draft will expire on December 14, 2020.
	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 28 ¶		skipping to change at page 2, line 28 ¶
	2. Conventions used in this document . . . . . . . . . . . . . . 3		2. Conventions used in this document . . . . . . . . . . . . . . 3
	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 9		4.1. Extra Padding TLV . . . . . . . . . . . . . . . . . . . . 9
	4.2. Location TLV . . . . . . . . . . . . . . . . . . . . . . 10		4.2. Location TLV . . . . . . . . . . . . . . . . . . . . . . 10
	4.3. Timestamp Information TLV . . . . . . . . . . . . . . . . 11		4.3. Timestamp Information TLV . . . . . . . . . . . . . . . . 11
	4.4. Class of Service TLV . . . . . . . . . . . . . . . . . . 12		4.4. Class of Service TLV . . . . . . . . . . . . . . . . . . 12
	4.5. Direct Measurement TLV . . . . . . . . . . . . . . . . . 14		4.5. Direct Measurement TLV . . . . . . . . . . . . . . . . . 14
	4.6. Access Report TLV . . . . . . . . . . . . . . . . . . . . 14		4.6. Access Report TLV . . . . . . . . . . . . . . . . . . . . 15
	4.7. Follow-up Telemetry TLV . . . . . . . . . . . . . . . . . 16		4.7. Follow-up Telemetry TLV . . . . . . . . . . . . . . . . . 16
	4.8. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 17		4.8. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 18
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	5.1. STAMP TLV Registry . . . . . . . . . . . . . . . . . . . 19		5.1. STAMP TLV Registry . . . . . . . . . . . . . . . . . . . 19
	5.2. Synchronization Source Sub-registry . . . . . . . . . . . 20		5.2. Synchronization Source Sub-registry . . . . . . . . . . . 20
	5.3. Timestamping Method Sub-registry . . . . . . . . . . . . 20		5.3. Timestamping Method Sub-registry . . . . . . . . . . . . 20
	5.4. Access ID Sub-registry . . . . . . . . . . . . . . . . . 21		5.4. Return Code Sub-registry . . . . . . . . . . . . . . . . 21
	5.5. Return Code Sub-registry . . . . . . . . . . . . . . . . 22		6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 23		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		9.1. Normative References . . . . . . . . . . . . . . . . . . 22
	9.1. Normative References . . . . . . . . . . . . . . . . . . 23		9.2. Informative References . . . . . . . . . . . . . . . . . 23
	9.2. Informative References . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] supports		Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] supports
	the use of optional extensions that use Type-Length-Value (TLV)		the use of optional extensions that use Type-Length-Value (TLV)
	encoding. Such extensions are to enhance the STAMP base functions,		encoding. Such extensions enhance the STAMP base functions, such as
	such as measurement of one-way and round-trip delay, latency, packet		measurement of one-way and round-trip delay, latency, packet loss,
	loss, as well as ability to detect packet duplication and out-of-		and the ability to detect packet duplication and out-of- order
	order delivery of the test packets. This specification provides		delivery of the test packets. This specification defines optional
	definitions of optional STAMP extensions, their formats, and theory		STAMP extensions, their formats, and the theory of operation. Also,
	of operation. Also, a STAMP Test Session Identifier is defined for		a STAMP Test Session Identifier is defined as an update of the base
	as an update of the base STAMP specification [RFC8762].		STAMP specification [RFC8762].
	2. Conventions used in this document		2. Conventions used in this document
	2.1. Terminology		2.1. Terminology
	STAMP - Simple Two-way Active Measurement Protocol		STAMP - Simple Two-way Active Measurement Protocol
	DSCP - Differentiated Services Code Point		DSCP - Differentiated Services Code Point
	ECN - Explicit Congestion Notification		ECN - Explicit Congestion Notification
	skipping to change at page 3, line 36 ¶		skipping to change at page 3, line 35 ¶
	BITS Building Integrated Timing Supply		BITS Building Integrated Timing Supply
	SSU Synchronization Supply Unit		SSU Synchronization Supply Unit
	GPS Global Positioning System		GPS Global Positioning System
	GLONASS Global Orbiting Navigation Satellite System		GLONASS Global Orbiting Navigation Satellite System
	LORAN-C Long Range Navigation System Version C		LORAN-C Long Range Navigation System Version C
	MBZ Must Be Zeroed		MBZ Must Be Zero
	CoS Class of Service		CoS Class of Service
	PMF Performance Measurement Function		PMF Performance Measurement Function
	SSID STAMP Session Identifier		SSID STAMP Session Identifier
	2.2. Requirements Language		2.2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 4, line 24 ¶		skipping to change at page 4, line 24 ¶
	modes: unauthenticated and authenticated. Unauthenticated STAMP test		modes: unauthenticated and authenticated. Unauthenticated STAMP test
	packets are compatible on the wire with unauthenticated TWAMP-Test		packets are compatible on the wire with unauthenticated TWAMP-Test
	[RFC5357] packet formats.		[RFC5357] packet formats.
	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 Session-Reflector equals the size of the packet		packet transmitted by Session-Reflector equals the size of the packet
	received by the Session-Reflector.		received by the Session-Reflector.
	A STAMP Session is identified using 4-tuple (source and destination		A STAMP Session is identified using 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 locally unique STAMP Session Identifier		Session-Sender MAY generate a locally unique STAMP Session Identifier
	(SSID). SSID is two octets long non-zero unsigned integer. A		(SSID). SSID is two octets long non-zero unsigned integer. A
	Session-Sender MAY use SSID to identify a STAMP test session. If		Session-Sender MAY use SSID to identify a STAMP test session. If
	SSID is used, it MUST be present in each test packet of the given		SSID is used, it MUST be present in each test packet of the given
	test session. In the unauthenticated mode, SSID is located, as		test session. In the unauthenticated mode, SSID is located, as
	displayed in Figure 1.		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 |
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 28 ¶
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Value ~		~ Value ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: STAMP Session-Sender test packet format with TLV in		Figure 1: An example of an extended STAMP Session-Sender test packet
	unauthenticated mode		format in unauthenticated mode
	An implementation of STAMP Session-Reflector that supports this		An implementation of STAMP Session-Reflector that supports this
	specification SHOULD identify a STAMP Session using the SSID in		specification SHOULD identify a STAMP Session using the SSID in
	combination with elements of the usual 4-tuple. A conforming		combination with elements of the usual 4-tuple for the session.
	implementation of STAMP Session-Reflector MUST copy the SSID value		Before a test session commenced, a Session-Reflector MUST be
	from the received test packet and put it into the reflected packet as		provisioned with all the elements that identify the STAMP Session. A
	displayed in Figure 2.		STAMP Session-Reflector MUST discard the non-matching STAMP test
			packet(s). The means of provisioning the STAMP Session
			identification is outside the scope of this specification. A
			conforming implementation of STAMP Session-Reflector MUST copy the
			SSID value from the received test packet and put it into the
			reflected packet, as displayed in Figure 2.
	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 6, line 32 ¶		skipping to change at page 6, line 32 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Session-Sender Error Estimate | MBZ |		| Session-Sender Error Estimate | MBZ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Ses-Sender TTL | MBZ |		|Ses-Sender TTL | MBZ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Value ~		~ Value ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: STAMP Session-Reflector test packet format with TLV in		Figure 2: An example of an extended STAMP Session-Reflector test
	unauthenticated mode		packet format 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 MUST NOT stop the session if it receives a zeroed		The Session-Sender MUST stop the session if it receives a zeroed SSID
	SSID field.		field.
	In the authenticated mode, location of SSID field is shown in		In the authenticated mode, location of SSID field 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 29 ¶		skipping to change at page 7, line 29 ¶
	~ ~		~ ~
	| MBZ (68 octets) |		| MBZ (68 octets) |
	~ ~		~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| HMAC (16 octets) |		| HMAC (16 octets) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: STAMP Session-Sender test packet format in authenticated		Figure 3: Base STAMP Session-Sender test packet format in
	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 30 ¶		skipping to change at page 8, line 30 ¶
	| |		| |
	| MBZ (15 octets) |		| MBZ (15 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| HMAC (16 octets) |		| HMAC (16 octets) |
	| |		| |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: STAMP Session-Reflector test packet format in authenticated		Figure 4: Base STAMP Session-Reflector test packet format in
	mode		authenticated mode
	4. TLV Extensions to STAMP		4. TLV Extensions to STAMP
	Type-Length-Value (TLV) encoding scheme provides flexible extension		Type-Length-Value (TLV) encoding scheme provides a flexible extension
	mechanism for optional informational elements. TLV is an optional		mechanism for optional informational elements. TLV is an optional
	field in the STAMP test packet. TLVs have the two octets long Type		field in the STAMP test packet. Multiple TLVs MAY be placed in the
	field, two octets long Length field that is the length of the Value		STAMP test packet. A TLV MAY be enclosed in a TLV. TLVs have the
	field in octets. Type values, see Section 5.1, less than 32768		two octets long Type field, two octets long Length field that is
	identify mandatory TLVs that MUST be supported by an implementation.		equal to the length of the Value field in octets. Type values, see
	Type values greater than or equal to 32768 identify optional TLVs		Section 5.1, less than 32768 identify mandatory TLVs that MUST be
	that SHOULD be ignored if the implementation does not understand or		supported by an implementation. Type values greater than or equal to
	support them. If a Type value for TLV or sub-TLV is in the range for		32768 identify optional TLVs that SHOULD be ignored if the
	Vendor Private Use, the Length MUST be at least 4, and the first four		implementation does not understand or support them. If a Type value
	octets MUST be that vendor's the Structure of Management Information		for TLV or sub-TLV is in the range for Vendor Private Use, the Length
	(SMI) Private Enterprise Number, in network octet order. The rest of		MUST be at least 4, and the first four octets MUST be that vendor's
	the Value field is private to the vendor. Following sections		the Structure of Management Information (SMI) Private Enterprise
	describe the use of TLVs for STAMP that extend STAMP capability		Number, in network octet order. The rest of the Value field is
	beyond its base specification.		private to the vendor. The following sections describe the use of
			TLVs for STAMP that extend STAMP capability beyond its base
			specification.
	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 UDP		difference between the two values is larger than the length of UDP
	header, then the test packet includes one or more STAMP TLVs that		header, then the test packet includes one or more STAMP TLVs that
	immediately follow the base STAMP test packet.		immediately follow the base STAMP test packet.
	A system that has received a STAMP test packet with extension TLVs		A system that has received a STAMP test packet with extension TLVs
	MUST validate each fixed-size TLV by verifying that the value in the		MUST validate each TLV:
	Length field equals the value defined for the particular type. If
	the values are not equal, the processing of extension TLVs MUST be		if the value of the Type field is one from the Mandatory TLV range
	stopped and the event logged (logging SHOULD be throttled). Also, if		(Table 1) that the system does not support, the processing of the
	the system is the Session-Reflector in that test, it MUST send		TLV MUST be stopped. If the system is the Session-Reflector, it
	(transmission of ICMP Error messages SHOULD be throttled) the ICMP		MUST send the ICMP Parameter Problem message with Code set to 0
	Parameter Problem message with Code set to 0 and the Pointer		and the Pointer referring to the Type field of the TLV;
	referring to the Length field of the TLV.
			fixed-size TLVs are verified that the Length field value equals
			the value defined for the particular type. If the values are not
			equal, the processing of extension TLVs MUST be stopped. Also, if
			the system is the Session-Reflector, it MUST send the ICMP
			Parameter Problem message with Code set to 0 and the Pointer
			referring to the Length field of the TLV.
			Detected error events MUST be logged. Note that transmission of ICMP
			Error messages and logging SHOULD be throttled.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Extra Padding Type | Length |		| Extra Padding Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Extra Padding ~		~ Extra Padding ~
	skipping to change at page 9, line 47 ¶		skipping to change at page 10, line 11 ¶
	Figure 5: Extra Padding TLV		Figure 5: Extra Padding TLV
	where fields are defined as the following:		where fields are defined as the following:
	o Extra Padding Type - TBA1 allocated by IANA Section 5.1		o Extra Padding Type - TBA1 allocated by IANA Section 5.1
	o Length - two octets long field equals length on the Extra Padding		o Length - two octets long field equals length on the Extra Padding
	field in octets.		field in octets.
	o Extra Padding - a pseudo-random sequence of numbers. The field		o Extra Padding - a pseudo-random sequence of numbers. The field
	MAY be filled with all zeroes.		MAY be filled with all zeros.
	The Extra Padding TLV is similar to the Packet Padding field in		The Extra Padding TLV is similar to the Packet Padding field in
	TWAMP-Test packet [RFC5357]. The Extra Padding TLV MUST be used to		TWAMP-Test packet [RFC5357]. The Extra Padding TLV MUST be used to
	create STAMP test packets of larger size. The Extra Padding TLV MUST		create STAMP test packets of larger size that the base STAMP packet
	be the last TLV in a STAMP test packet.		[RFC8762]. The length of the base STAMP is 44 octets in the
			unauthenticated mode or 112 octets in the authenticated mode. The
			Extra Padding TLV MUST be the last TLV in a STAMP test packet.
	4.2. Location TLV		4.2. Location TLV
	STAMP session-sender MAY include the Location TLV to request		STAMP Session-Sender MAY include the Location TLV to request
	information from the session-reflector. The session-sender SHOULD		information from the Session-Reflector. The Session-Sender SHOULD
	NOT fill any information fields except for Type and Length. The		NOT fill any information fields except for Type and Length. The
	session-reflector MUST validate the Length value against the address		Session-Reflector MUST validate the Length value against the address
	family of the transport encapsulating the STAMP test packet. If the		family of the transport encapsulating the STAMP test packet. If the
	value of the Length field is invalid, the session-reflector MUST zero		Length field's value is invalid, the Session-Reflector MUST zero all
	all fields and MUST NOT return any information to the session-sender.		fields and MUST NOT return any information to the Session-Sender.
	The session-reflector MUST ignore all other fields of the received		The Session-Reflector MUST ignore all other fields of the received
	Location TLV.		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Location Type | Length |		| Location Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source MAC |		| Source MAC |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | Reserved |		| | Reserved |
	skipping to change at page 10, line 38 ¶		skipping to change at page 11, line 4 ¶
	~ Source IP Address ~		~ Source IP Address ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Destination Port | Source Port |		| Destination Port | Source Port |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 6: Session-Reflector Location TLV		Figure 6: Session-Reflector Location TLV
	where fields are defined as the following:		where fields are defined as the following:
	o Location Type - TBA2 allocated by IANA Section 5.1		o Location Type - TBA2 allocated by IANA Section 5.1
			o Length - two octets long field equals the length of the Value
			field in octets. The Length field value MUST equal 20 octets for
			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 Length - two octets long field equals length on the Value field in		o Source MAC - 6 octets 48 bits long field. The Session-Reflector
	octets. Length field value MUST be 20 octets for the IPv4 address
	family. For the IPv6 address family value of the Length field
	MUST be 44 octets. All other values are invalid.
	o Source MAC - 6 octets 48 bits long field. The session-reflector
	MUST copy Source MAC of received STAMP packet into this field.		MUST copy Source MAC of received STAMP packet into this field.
	o Reserved - two octets long field. MUST be zeroed on transmission		o Reserved - two octets long field. MUST be zeroed on transmission
	and ignored on reception.		and ignored on reception.
	o Destination IP Address - IPv4 or IPv6 destination address of the		o Destination IP Address - IPv4 or IPv6 destination address of the
	received by the session-reflector STAMP packet.		packet received by the STAMP Session-Reflector.
	o Source IP Address - IPv4 or IPv6 source address of the received by		o Source IP Address - IPv4 or IPv6 source address of the packet
	the session-reflector STAMP packet.		received by the STAMP Session-Reflector.
	o Destination Port - two octets long UDP destination port number of		o Destination Port - two octets long UDP destination port number of
	the received STAMP packet.		the received STAMP packet.
	o Source Port - two octets long UDP source port number of the		o Source Port - two octets long UDP source port number of the
	received STAMP packet.		received STAMP packet.
	The Location TLV MAY be used to determine the last-hop addressing for		The Location TLV MAY be used to determine the last-hop addressing for
	STAMP packets including source and destination IP addresses as well		STAMP packets including source and destination IP addresses as well
	as the MAC address of the last-hop router. Last-hop MAC address MAY		as the MAC address of the last-hop router. Last-hop MAC address MAY
	be monitored by the Session-Sender whether there has been a path		be monitored by the Session-Sender whether there has been a path
	switch on the last hop, closest to the Session-Reflector. The IP		switch on the last hop, closest to the Session-Reflector. The IP
	addresses and UDP port will indicate if there is a NAT router on the		addresses and UDP port will indicate if there is a NAT router on the
	path, and allows the Session-Sender to identify the IP address of the		path, and allows the Session-Sender to identify the IP address of the
	Session-Reflector behind the NAT, detect changes in the NAT mapping		Session-Reflector behind the NAT, detect changes in the NAT mapping
	that could cause sending the STAMP packets to the wrong Session-		that could cause sending the STAMP packets to the wrong Session-
	Reflector.		Reflector.
	4.3. Timestamp Information TLV		4.3. Timestamp Information TLV
	STAMP session-sender MAY include the Timestamp Information TLV to		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 Type and Length.		SHOULD NOT fill any information fields except for Type and Length.
	The session-reflector MUST validate the Length value of the STAMP		The Session-Reflector MUST validate the Length value of the STAMP
	test packet. If the value of the Length field is invalid, the		test packet. If the value of the Length field is invalid, the
	session-reflector MUST zero all fields and MUST NOT return any		Session-Reflector MUST zero all fields and MUST NOT return any
	information to the session-sender.		information to the Session-Sender.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Timestamp Information Type | Length |		| Timestamp Information Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sync. Src In | Timestamp In | Sync. Src Out | Timestamp Out |		| Sync. Src In | Timestamp In | Sync. Src Out | Timestamp Out |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 7: Timestamp Information TLV		Figure 7: Timestamp Information TLV
	where fields are defined as the following:		where fields are defined as the following:
	o Timestamp Information Type - TBA3 allocated by IANA Section 5.1		o Timestamp Information Type - TBA3 allocated by IANA Section 5.1
	o Length - two octets long field, equals four octets.		o Length - two octets long field, set equal to the value 4.
	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 Session-Reflector.		of clock synchronization at the ingress of Session-Reflector.
			There are several methods to synchronize the clock, e.g., Network
	There are several of methods to synchronize the clock, e.g.,		Time Protocol (NTP) [RFC5905], Precision Time Protocol (PTP)
	Network Time Protocol (NTP) [RFC5905], Precision Time Protocol		[IEEE.1588.2008], Synchronization Supply Unit (SSU) or Building
	(PTP) [IEEE.1588.2008], Synchronization Supply Unit (SSU) or		Integrated Timing Supply (BITS), or Global Positioning System
	Building Integrated Timing Supply (BITS), or Global Positioning		(GPS), Global Orbiting Navigation Satellite System (GLONASS) and
	System (GPS), Global Orbiting Navigation Satellite System		Long Range Navigation System Version C (LORAN-C). The value is
	(GLONASS) and Long Range Navigation System Version C (LORAN-C).		one of those listed in Table 4.
	The value is one of the listed in Table 4.
	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 Session-Reflector obtained the timestamp		by which the ingress of Session-Reflector obtained the timestamp
	T2. A timestamp may be obtained with hardware assist, via		T2. A timestamp may be obtained with hardware assistance, via
	software API from a local wall clock, or from a remote clock (the		software API from a local wall clock, or from a remote clock (the
	latter referred to as "control plane"). The value is one of the		latter is referred to as "control plane"). The value is one of
	listed in Table 6.		those listed in Table 6.
	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 Session-Reflector. The		of clock synchronization at the egress of Session-Reflector. The
	value is one of the listed in Table 4.		value is one of those listed in Table 4.
	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 Session-Reflector obtained the timestamp		by which the egress of Session-Reflector obtained the timestamp
	T3. The value is one of the listed in Table 6.		T3. The value is one of those listed in Table 6.
	4.4. Class of Service TLV		4.4. Class of Service TLV
	The STAMP session-sender MAY include Class of Service (CoS) TLV in		The STAMP Session-Sender MAY include Class of Service (CoS) TLV in
	the STAMP test packet. If the CoS TLV is present in the STAMP test		the STAMP test packet. If the CoS TLV is present in the STAMP test
	packet and the value of the DSCP1 field is zero, then the STAMP		packet and the value of the DSCP1 field is zero, then the STAMP
	session-reflector MUST copy the values of Differentiated Services		Session-Reflector MUST copy the values of Differentiated Services
	Code Point (DSCP) ECN fields from the received STAMP test packet into		Code Point (DSCP) ECN fields from the received STAMP test packet into
	DSCP2 and ECN fields respectively of the CoS TLV of the reflected		DSCP2 and ECN fields respectively of the CoS TLV of the reflected
	STAMP test packet. If the value of the DSCP1 field is non-zero, then		STAMP test packet. If the value of the DSCP1 field is non-zero, then
	the STAMP session-reflector MUST use DSCP1 value from the CoS TLV in		the STAMP Session-Reflector MUST use DSCP1 value from the CoS TLV in
	the received STAMP test packet as DSCP value of STAMP reflected test		the received STAMP test packet as DSCP value of STAMP reflected test
	packet and MUST copy DSCP and ECN values of the received STAMP test		packet and MUST copy DSCP and ECN values of the received STAMP test
	packet into DSCP2 and ECN fields of Class of Service TLV in the STAMP		packet into DSCP2 and ECN fields of Class of Service TLV in the STAMP
	reflected a packet. The Session-Sender, upon receiving the reflected		reflected a packet. Upon receiving the reflected packet, the
	packet, will save the DSCP and ECN values for analysis of the CoS in		Session-Sender,will save the DSCP and ECN values for analysis of the
	the reverse direction.		CoS in the reverse direction.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Class of Service Type | Length |		| Class of Service Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DSCP1 | DSCP2 |ECN| Reserved |		| DSCP1 | DSCP2 |ECN| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 8: Class of Service TLV		Figure 8: Class of Service TLV
	where fields are defined as the following:		where fields are defined as the following:
	o Class of Service Type - TBA4 allocated by IANA Section 5.1		o Class of Service Type - TBA4 allocated by IANA Section 5.1
	o Length - two octets long field, equals four octets.		o Length - two octets 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 return DSCP from the		the Session-Sender. To be used as the return DSCP from the
	Session-Reflector.		Session-Reflector.
	o DSCP2 - The received value in the DSCP field at the Session-		o DSCP2 - The received value in the DSCP field at the Session-
	Reflector in the forward direction.		Reflector in the forward direction.
	o ECN - The received value in the ECN field at the Session-Reflector		o ECN - The received value in the ECN field at the Session-Reflector
	in the forward direction.		in the forward direction.
	o Reserved - 18 bits long field, must be zeroed in transmission and		o Reserved - 18 bits long field, must be zeroed in transmission and
	ignored on receipt.		ignored on receipt.
	A STAMP Session-Sender that includes the CoS TLV sets the value of		A STAMP Session-Sender that includes the CoS TLV sets the value of
	the DSCP1 field and zeroes the value of the DSCP2 field. A STAMP		the DSCP1 field and zeroes the value of the DSCP2 field. A STAMP
	Session-Reflector that received the test packet with the CoS TLV MUST		Session-Reflector that received the test packet with the CoS TLV MUST
	include the CoS TLV in the reflected test packet. Also, the Session-		include the CoS TLV in the reflected test packet. Also, the Session-
	Reflector MUST copy the value of the DSCP field of the IP header of		Reflector MUST copy the value of the DSCP field of the IP header of
	the received STAMP test packet into the DSCP2 field in the reflected		the received STAMP test packet into the DSCP2 field in the reflected
	test packet. And, at last, the Session-Reflector MUST set the value		test packet. At last, the Session-Reflector MUST set the value of
	of the DSCP field in the IP header of the reflected test packet equal		DSCP field's value in the IP header of the reflected test packet
	to the value of the DSCP1 field of the test packet it has received.		equal to the value of the DSCP1 field of the received test packet.
	Re-mapping of CoS in some use cases, for example, in mobile backhaul		Re-mapping of CoS in some use cases, for example, in mobile backhaul
	networks is used to provide multiple services, i.e., 2G, 3G, LTE,		networks is used to provide multiple services, i.e., 2G, 3G, LTE,
	over the same network. But if it is misconfigured, then it is often		over the same network. But if it is misconfigured, then it is often
	difficult to diagnose the root cause of the problem that is viewed as		difficult to diagnose the root cause of the problem that is viewed as
	an excessive packet drop of higher level service while packet drop		an excessive packet drop of higher-level service while packet drop
	for lower service packets is at a normal level. Using CoS TLV in		for lower service packets is at a normal level. Using CoS TLV in
	STAMP test helps to troubleshoot the existing problem and also verify		STAMP test helps to troubleshoot the existing problem and also verify
	whether DiffServ policies are processing CoS as required by the		whether DiffServ policies are processing CoS as required by the
	configuration.		configuration.
	4.5. Direct Measurement TLV		4.5. Direct Measurement TLV
	The Direct Measurement TLV enables collection of "in profile" IP		The Direct Measurement TLV enables collection of "in profile" IP
	packets that had been transmitted and received by the Session-Sender		packets that had been transmitted and received by the Session-Sender
	and Session-Reflector respectfully. The definition of "in-profile		and Session-Reflector respectfully. The definition of "in-profile
	packet" is outside the scope of this document.		packet" is 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Direct Measurement Type | Length |		| Direct Measurement 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 9: Direct Measurement TLV		Figure 9: Direct Measurement TLV
	where fields are defined as the following:		where fields are defined as the following:
	o Direct Measurement Type - TBA5 allocated by IANA Section 5.1		o Direct Measurement Type - TBA5 allocated by IANA Section 5.1
	o Length - two octets long field equals length on the Value field in		o Length - two octets long field equals length on the Value field in
	octets. Length field value MUST be 12 octets.		octets. Length field value MUST equal 12 octets.
	o Session-Sender Tx counter (S_TxC) is four octets long field.		o Session-Sender Tx counter (S_TxC) is four octets long field.
	o Session-Reflector Rx counter (R_RxC) is four octets long field.		o Session-Reflector Rx counter (R_RxC) is four octets long field.
	MUST be zeroed by the Session-Sender and filled by the Session-		MUST be zeroed by the Session-Sender and filled by the Session-
	Reflector.		Reflector.
	o Session-Reflector Tx counter (R_TxC) is four octets long field.		o Session-Reflector Tx counter (R_TxC) is four octets long field.
	MUST be zeroed by the Session-Sender and filled by the Session-		MUST be zeroed by the Session-Sender and filled by the Session-
	Reflector.		Reflector.
	skipping to change at page 15, line 10 ¶		skipping to change at page 15, line 17 ¶
	A STAMP Session-Sender MAY include Access Report TLV (Figure 10) to		A STAMP Session-Sender MAY include Access Report TLV (Figure 10) to
	indicate changes to the access network status to the Session-		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Access Report Type | Length |		| Access Report Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Access ID | Return Code | Reserved |		| ID | Resv | Return Code | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 10: Access Report TLV		Figure 10: Access Report TLV
	where fields are defined as follows:		where fields are defined as follows:
	o Access Report Type - TBA6 allocated by IANA Section 5.1.		o Access Report Type - TBA6 allocated by IANA Section 5.1.
	o Length - two octets long field, equals four octets.		o Length - two octets long field, set equal to the value 4.
	o Access ID - one octet long field that identifies the access		o ID (Access ID) - four bits long field that identifies the access
	network, e.g., 3GPP (Radio Access Technologies specified by 3GPP)		network, e.g., 3GPP (Radio Access Technologies specified by 3GPP)
	or Non-3GPP (accesses that are not specified by 3GPP) [TS23501].		or Non-3GPP (accesses that are not specified by 3GPP) [TS23501].
	The value is one of Section 5.4.		The value is one of those listed below:
			* 1 - 3GPP Network
			* 2 - Non-3GPP Network
			All other values are invalid and the TLV that contains it MUST be
			discarded.
			o Resv - four bits long field, must be zeroed on transmission and
			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, unavailable. The value is one of		signal, e.g., available, unavailable. The value is passed,
	Section 5.5.		supplied to the STAMP end-point through some mechanism that is
			outside the scope of this document. The value is one of those
			listed in Section 5.4.
	o Reserved - two octets long field, must be zeroed on transmission		o Reserved - two octets 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 16, line 18 ¶		skipping to change at page 16, line 39 ¶
	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
	a "SW Local" (see Table 6) timestamp. But the hosting system might		an "SW Local" (see Table 6) timestamp. But the hosting system might
	provide the timestamp closer to the start of actual packet		provide the timestamp closer to the start of the actual packet
	transmission even though when it is not possible to deliver the		transmission even though when it is not possible to deliver the
	information to the Session-Sender in the packet itself. This		information to the Session-Sender in the packet itself. This
	timestamp might nevertheless be important for the Session-Sender, as		timestamp might nevertheless be important for the Session-Sender, as
	it helps in to improve the accuracy of measuring network delay by		it improves the accuracy of measuring network delay by minimizing the
	minimizing the impact of egress queuing delays on the measurement.		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. Sequence Number and Timestamp fields MUST be		appropriate values. 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 Sequence Number and		field is invalid, the Session-Reflector MUST zero Sequence Number and
	skipping to change at page 17, line 24 ¶		skipping to change at page 17, line 30 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Timestamp M | Reserved |		| Timestamp M | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 11: Follow-up Telemetry TLV		Figure 11: Follow-up Telemetry TLV
	where fields are defined as follows:		where fields are defined as follows:
	o Follow-up Telemetry Type - TBA7 allocated by IANA Section 5.1.		o Follow-up Telemetry Type - TBA7 allocated by IANA Section 5.1.
	o Length - two octets long field, equals 16 octets.		o Length - two octets long field, set equal to the value 16 octets.
	o Sequence Number - four octets long field indicating the sequence		o Sequence Number - four octets 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 octets long field, with the format		o Follow-up Timestamp - eight octets 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 packet
	transmitted by a Session-Reflector, as described in Section 4.1		transmitted by a Session-Reflector, as described in Section 4.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 the listed		obtained the Follow-up Timestamp. The value is one of those
	in Table 6.		listed in Table 6.
	o Reserved - the three octest-long field. Its value MUST be zeroed		o Reserved - the three octets-long field. Its value MUST be zeroed
	on transmission and ignored on receipt.		on 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 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. The keyed Hashed
	Message Authentication Code (HMAC) TLV MUST be included in a STAMP		Message Authentication Code (HMAC) TLV MUST be included in a STAMP
	test packet in the authenticated mode, excluding when the only TLV		test packet in the authenticated mode, excluding when the only TLV
	present is Extra Padding TLV. The HMAC TLV MUST follow all TLVs		present is Extra Padding TLV. The HMAC TLV MUST follow all TLVs
	included in a STAMP test packet, except for the Extra Padding TLV.		included in a STAMP test packet, except for the Extra Padding TLV.
	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.
	0 1 2 3		0 1 2 3
	skipping to change at page 18, line 28 ¶		skipping to change at page 18, line 36 ¶
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 12: HMAC TLV		Figure 12: HMAC TLV
	where fields are defined as follows:		where fields are defined as follows:
	o HMAC Type - is two octets long field, value TBA8 allocated by IANA		o HMAC Type - is two octets long field, value TBA8 allocated by IANA
	Section 5.1.		Section 5.1.
	o Length - two octets long field, equals 16 octets.		o Length - two octets long field, set equal to the value 16 octets.
	o HMAC - is 16 octets long field that carries HMAC digest of the		o HMAC - is 16 octets 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 is calculated as
	defined in [RFC2104] over text as the concatenation of all preceding		defined in [RFC2104] over text as the concatenation of all preceding
	TLVs. The digest then MUST be truncated to 128 bits and written into		TLVs. The digest then MUST be truncated to 128 bits and written into
	skipping to change at page 19, line 32 ¶		skipping to change at page 19, line 35 ¶
	| | unassigned | |		| | unassigned | |
	| 32768 - 65279 | Optional TLV, | First Come First Served |		| 32768 - 65279 | Optional TLV, | First Come First Served |
	| | unassigned | |		| | unassigned | |
	| 65280 - 65519 | Experimental | This document |		| 65280 - 65519 | Experimental | This document |
	| 65520 - 65534 | Private Use | This document |		| 65520 - 65534 | Private Use | This document |
	| 65535 | Reserved | This document |		| 65535 | 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 TLV Type		This document defines the following new values in the Mandatory TLV
	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 Types
	5.2. Synchronization Source Sub-registry		5.2. Synchronization Source Sub-registry
	IANA is requested to create Synchronization Source sub-registry as		IANA is requested to create Synchronization Source sub-registry as
	part of 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 1:		[RFC8126]. Remaining code points are allocated according to Table 1:
	+-----------+--------------+-------------------------+		+-----------+--------------+-------------------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-----------+--------------+-------------------------+		+-----------+--------------+-------------------------+
	| 0 | Reserved | This document |		| 0 | Reserved | This document |
	skipping to change at page 20, line 46 ¶		skipping to change at page 20, line 46 ¶
	| 3 | SSU/BITS | This document |		| 3 | SSU/BITS | This document |
	| 4 | GPS/GLONASS/LORAN-C | This document |		| 4 | GPS/GLONASS/LORAN-C | This document |
	| 5 | Local free-running | This document |		| 5 | Local free-running | This document |
	+-------+---------------------+---------------+		+-------+---------------------+---------------+
	Table 4: Synchronization Sources		Table 4: Synchronization Sources
	5.3. Timestamping Method Sub-registry		5.3. Timestamping Method Sub-registry
	IANA is requested to create Timestamping Method sub-registry as part		IANA is requested to create Timestamping Method sub-registry as part
	of STAMP TLV Type registry. All code points in the range 1 through		of the STAMP TLV Type registry. All code points in the range 1
	127 in this registry shall be allocated according to the "IETF		through 127 in this registry shall be allocated according to the
	Review" procedure as specified in [RFC8126]. Code points in the		"IETF Review" procedure as specified in [RFC8126]. Code points in
	range 128 through 239 in this registry shall be allocated according		the range 128 through 239 in this registry shall be allocated
	to the "First Come First Served" procedure as specified in [RFC8126].		according to the "First Come First Served" procedure as specified in
	Remaining code points are allocated according to Table 1:		[RFC8126]. Remaining code points are allocated according to Table 1:
	+-----------+--------------+-------------------------+		+-----------+--------------+-------------------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-----------+--------------+-------------------------+		+-----------+--------------+-------------------------+
	| 0 | Reserved | This document |		| 0 | Reserved | This document |
	| 1- 127 | Unassigned | IETF Review |		| 1- 127 | Unassigned | IETF Review |
	| 128 - 239 | Unassigned | First Come First Served |		| 128 - 239 | Unassigned | First Come First Served |
	| 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 |
	skipping to change at page 21, line 31 ¶		skipping to change at page 21, line 31 ¶
	+-------+---------------+---------------+		+-------+---------------+---------------+
	| 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 6: Timestamping Methods		Table 6: Timestamping Methods
	5.4. Access ID Sub-registry		5.4. Return Code Sub-registry
	IANA is requested to create Access ID sub-registry as part of STAMP
	TLV Type registry. All code points in the range 1 through 127 in
	this registry shall be allocated according to the "IETF Review"
	procedure as specified in [RFC8126]. Code points in the range 128
	through 239 in this registry shall be allocated according to the
	"First Come First Served" procedure as specified in [RFC8126].
	Remaining code points are allocated according to Table 7:
	+-----------+--------------+-------------------------+
	| Value | Description | Reference |
	+-----------+--------------+-------------------------+
	| 0 | Reserved | This document |
	| 1- 127 | Unassigned | IETF Review |
	| 128 - 239 | Unassigned | First Come First Served |
	| 240 - 249 | Experimental | This document |
	| 250 - 254 | Private Use | This document |
	| 255 | Reserved | This document |
	+-----------+--------------+-------------------------+
	Table 7: Access ID Sub-registry
	This document defines the following new values in the Access ID sub-
	registry:
	+-------+-------------+---------------+
	| Value | Description | Reference |
	+-------+-------------+---------------+
	| 1 | 3GPP | This document |
	| 2 | Non-3GPP | This document |
	+-------+-------------+---------------+
	Table 8: Access IDs
	5.5. Return Code Sub-registry
	IANA is requested to create Return Code sub-registry as part of STAMP		IANA is requested to create Return Code sub-registry as part of STAMP
	TLV Type registry. All code points in the range 1 through 127 in		TLV Type registry. All code points in the range 1 through 127 in
	this registry shall be allocated according to the "IETF Review"		this registry shall be allocated according to the "IETF Review"
	procedure as specified in [RFC8126]. Code points in the range 128		procedure as specified in [RFC8126]. Code points in the range 128
	through 239 in this registry shall be allocated according to the		through 239 in this registry shall be allocated according to the
	"First Come First Served" procedure as specified in [RFC8126].		"First Come First Served" procedure as specified in [RFC8126].
	Remaining code points are allocated according to Table 7:		Remaining code points are allocated according to Table 7:
	+-----------+--------------+-------------------------+		+-----------+--------------+-------------------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-----------+--------------+-------------------------+		+-----------+--------------+-------------------------+
	| 0 | Reserved | This document |		| 0 | Reserved | This document |
	| 1- 127 | Unassigned | IETF Review |		| 1- 127 | Unassigned | IETF Review |
	| 128 - 239 | Unassigned | First Come First Served |		| 128 - 239 | Unassigned | First Come First Served |
	| 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 9: Return Code Sub-registry		Table 7: 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 10: Return Codes		Table 8: Return Codes
	6. Security Considerations		6. Security Considerations
	Use of HMAC in authenticated mode may be used to simultaneously		This document defines extensions to STAMP [RFC8762] and inherits all
	verify both the data integrity and the authentication of the STAMP		the security considerations applicable to the base protocol.
	test packets.		Additionally, the HMAC TLV is defined in this document to protect the
			integrity of optional STAMP extensions. The use of HMAC TLV is
			discussed in detail in Section 4.8.
	7. Acknowledgments		7. Acknowledgments
	Authors much appreciate the thorough review and thoughful comments		Authors much appreciate the thorough review and thoughtful comments
	received from Tianran Zhou.		received from Tianran Zhou, Rakesh Gandhi, Yuezhong Song and Yali
			Wang. Authors express their gratitude to Al Morton for his comments
			and the most valuable suggestions.
	8. Contributors		8. Contributors
	The following people contributed text to this document:		The following people contributed text to this document:
	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
End of changes. 67 change blocks.
	178 lines changed or deleted		176 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/