< draft-mirsky-ippm-hybrid-two-step-08.txt		draft-mirsky-ippm-hybrid-two-step-09.txt >
	IPPM Working Group G. Mirsky		IPPM Working Group G. Mirsky
	Internet-Draft ZTE Corp.		Internet-Draft ZTE Corp.
	Intended status: Standards Track W. Lingqiang		Intended status: Standards Track W. Lingqiang
	Expires: August 19, 2021 G. Zhui		Expires: 1 October 2021 G. Zhui
	ZTE Corporation		ZTE Corporation
	H. Song		H. Song
	Futurewei Technologies		Futurewei Technologies
	February 15, 2021		30 March 2021
	Hybrid Two-Step Performance Measurement Method		Hybrid Two-Step Performance Measurement Method
	draft-mirsky-ippm-hybrid-two-step-08		draft-mirsky-ippm-hybrid-two-step-09
	Abstract		Abstract
	Development of, and advancements in, automation of network operations		Development of, and advancements in, automation of network operations
	brought new requirements for measurement methodology. Among them is		brought new requirements for measurement methodology. Among them is
	the ability to collect instant network state as the packet being		the ability to collect instant network state as the packet being
	processed by the networking elements along its path through the		processed by the networking elements along its path through the
	domain. This document introduces a new hybrid measurement method,		domain. This document introduces a new hybrid measurement method,
	referred to as hybrid two-step, as it separates the act of measuring		referred to as hybrid two-step, as it separates the act of measuring
	and/or calculating the performance metric from the act of collecting		and/or calculating the performance metric from the act of collecting
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 August 19, 2021.		This Internet-Draft will expire on 1 October 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	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 . . . . . . . . . . . . . . . . . . 4		2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
	3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 4		3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 4
	4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5		4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Operation of the HTS Ingress Node . . . . . . . . . . . . 6		4.1. Operation of the HTS Ingress Node . . . . . . . . . . . . 6
	4.2. Operation of the HTS Intermediate Node . . . . . . . . . 8		4.2. Operation of the HTS Intermediate Node . . . . . . . . . 8
	4.3. Operation of the HTS Egress Node . . . . . . . . . . . . 9		4.3. Operation of the HTS Egress Node . . . . . . . . . . . . 9
	4.4. Considerations for HTS Timers . . . . . . . . . . . . . . 10		4.4. Considerations for HTS Timers . . . . . . . . . . . . . . 10
	4.5. Deploying HTS in a Multicast Network . . . . . . . . . . 10		4.5. Deploying HTS in a Multicast Network . . . . . . . . . . 10
	5. Authentication in HTS . . . . . . . . . . . . . . . . . . . . 10		5. Authentication in HTS . . . . . . . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	6.1. IOAM Option-Type for HTS . . . . . . . . . . . . . . . . 12		6.1. IOAM Option-Type for HTS . . . . . . . . . . . . . . . . 12
	6.2. HTS TLV Registry . . . . . . . . . . . . . . . . . . . . 12		6.2. HTS TLV Registry . . . . . . . . . . . . . . . . . . . . 12
	6.3. HTS Sub-TLV Type Sub-registry . . . . . . . . . . . . . . 12		6.3. HTS Sub-TLV Type Sub-registry . . . . . . . . . . . . . . 13
	6.4. HMAC Type Sub-registry . . . . . . . . . . . . . . . . . 13		6.4. HMAC Type Sub-registry . . . . . . . . . . . . . . . . . 14
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 14		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.1. Normative References . . . . . . . . . . . . . . . . . . 15		9.1. Normative References . . . . . . . . . . . . . . . . . . 15
	9.2. Informative References . . . . . . . . . . . . . . . . . 15		9.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	Successful resolution of challenges of automated network operation,		Successful resolution of challenges of automated network operation,
	as part of, for example, overall service orchestration or data center		as part of, for example, overall service orchestration or data center
	operation, relies on a timely collection of accurate information that		operation, relies on a timely collection of accurate information that
	reflects the state of network elements on an unprecedented scale.		reflects the state of network elements on an unprecedented scale.
	Because performing the analysis and act upon the collected		Because performing the analysis and act upon the collected
	information requires considerable computing and storage resources,		information requires considerable computing and storage resources,
	the network state information is unlikely to be processed by the		the network state information is unlikely to be processed by the
	skipping to change at page 4, line 26 ¶		skipping to change at page 4, line 28 ¶
	Performance measurements are meant to provide data that characterize		Performance measurements are meant to provide data that characterize
	conditions experienced by traffic flows in the network and possibly		conditions experienced by traffic flows in the network and possibly
	trigger operational changes (e.g., re-route of flows, or changes in		trigger operational changes (e.g., re-route of flows, or changes in
	resource allocations). Modifications to a network are determined		resource allocations). Modifications to a network are determined
	based on the performance metric information available when a change		based on the performance metric information available when a change
	is to be made. The correctness of this determination is based on the		is to be made. The correctness of this determination is based on the
	quality of the collected metrics data. The quality of collected		quality of the collected metrics data. The quality of collected
	measurement data is defined by:		measurement data is defined by:
	o the resolution and accuracy of each measurement;		* the resolution and accuracy of each measurement;
	o predictability of both the time at which each measurement is made		* predictability of both the time at which each measurement is made
	and the timeliness of measurement collection data delivery for		and the timeliness of measurement collection data delivery for
	use.		use.
	Consider the case of delay measurement that relies on collecting time		Consider the case of delay measurement that relies on collecting time
	of packet arrival at the ingress interface and time of the packet		of packet arrival at the ingress interface and time of the packet
	transmission at the egress interface. The method includes recording		transmission at the egress interface. The method includes recording
	a local clock value on receiving the first octet of an affected		a local clock value on receiving the first octet of an affected
	message at the device ingress, and again recording the clock value on		message at the device ingress, and again recording the clock value on
	transmitting the first byte of the same message at the device egress.		transmitting the first byte of the same message at the device egress.
	In this ideal case, the difference between the two recorded clock		In this ideal case, the difference between the two recorded clock
	skipping to change at page 5, line 25 ¶		skipping to change at page 5, line 27 ¶
	Maximum Transmission Unit (MTU) size, especially if the packet		Maximum Transmission Unit (MTU) size, especially if the packet
	traverses overlay domains or VPNs. Since the fragmentation is not		traverses overlay domains or VPNs. Since the fragmentation is not
	available at the transport network, operators may have to reduce MTU		available at the transport network, operators may have to reduce MTU
	size advertised to the client layer or risk missing network state		size advertised to the client layer or risk missing network state
	data for the part, most probably the latter part, of the path.		data for the part, most probably the latter part, of the path.
	4. Theory of Operation		4. Theory of Operation
	The HTS method consists of two phases:		The HTS method consists of two phases:
	o performing a measurement or obtaining network state information,		* performing a measurement or obtaining network state information,
	one or more than one type, on a node;		one or more than one type, on a node;
	o collecting and transporting the measurement.		* collecting and transporting the measurement.
	HTS uses HTS Trigger carried in a data packet or a specially		HTS uses HTS Trigger carried in a data packet or a specially
	constructed test packet. For example, an HTS Trigger could be a		constructed test packet. For example, an HTS Trigger could be a
	packet that has IOAM Option-Type set to the "IOAM Hybrid Two-Step		packet that has IOAM Option-Type set to the "IOAM Hybrid Two-Step
	Option-Type" value (TBA1) allocated by IANA (see Section 6.1). The		Option-Type" value (TBA1) allocated by IANA (see Section 6.1). The
	HTS Trigger also includes IOAM Namespace-ID and IOAM-Trace-Type		HTS Trigger also includes IOAM Namespace-ID and IOAM-Trace-Type
	information [I-D.ietf-ippm-ioam-data]. A packet in the flow to which		information [I-D.ietf-ippm-ioam-data]. A packet in the flow to which
	the Alternate-Marking method [RFC8321] is applied can be used as an		the Alternate-Marking method [RFC8321] is applied can be used as an
	HTS Trigger. The nature of the HTS Trigger is a transport network		HTS Trigger. The nature of the HTS Trigger is a transport network
	layer-specific, and its description is outside the scope of this		layer-specific, and its description is outside the scope of this
	skipping to change at page 6, line 45 ¶		skipping to change at page 6, line 47 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Telemetry Data TLVs ~		~ Telemetry Data TLVs ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Follow-up Packet Format		Figure 1: Follow-up Packet Format
	Fields of the HTS shim are as follows:		Fields of the HTS shim are as follows:
	Version (Ver) is the two-bits long field. It specifies the		Version (Ver) is the two-bits long field. It specifies the
	version of the HTS shim format. This document defines the format		version of the HTS shim format. This document defines the format
	for the 0b00 value of the field.		for the 0b00 value of the field.
	HTS Shim Length is the six bits-long field. It defines the length		HTS Shim Length is the six bits-long field. It defines the length
	of the HTS shim in bytes. The minimal value of the field is four		of the HTS shim in bytes. The minimal value of the field is four
	bytes.		bytes.
	0		0
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|F| Reserved |		|F| Reserved |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 2: Flags Field Format		Figure 2: Flags Field Format
	Flags is eight-bits long. The format of the Flags field displayed		Flags is eight-bits long. The format of the Flags field displayed
	in Figure 2.		in Figure 2.
	Full (F) flag MUST be set to zero by the node originating the		- Full (F) flag MUST be set to zero by the node originating the
	HTS follow-up packet and MUST be set to one by the node that		HTS follow-up packet and MUST be set to one by the node that
	does not add its telemetry data to avoid exceeding MTU size.		does not add its telemetry data to avoid exceeding MTU size.
	The node originating the follow-up packet MUST zero the		- The node originating the follow-up packet MUST zero the
	Reserved field and ignore it on the receipt.		Reserved field and ignore it on the receipt.
	Sequence Number is 16 bits-long field. The zero-based value of		Sequence Number is 16 bits-long field. The zero-based value of
	the field reflects the place of the HTS follow-up packet in the		the field reflects the place of the HTS follow-up packet in the
	sequence of the HTS follow-up packets that originated in response		sequence of the HTS follow-up packets that originated in response
	to the same HTS trigger. The ingress node MUST set the value of		to the same HTS trigger. The ingress node MUST set the value of
	the field to zero.		the field to zero.
	Telemetry Data Profile is the optional variable-length field of		Telemetry Data Profile is the optional variable-length field of
	bit-size flags. Each flag indicates the requested type of		bit-size flags. Each flag indicates the requested type of
	telemetry data to be collected at each HTS node. The increment of		telemetry data to be collected at each HTS node. The increment of
	the field is four bytes with a minimum length of zero. For		the field is four bytes with a minimum length of zero. For
	example, IOAM-Trace-Type information defined in		example, IOAM-Trace-Type information defined in
	[I-D.ietf-ippm-ioam-data] can be used in the Telemetry Data		[I-D.ietf-ippm-ioam-data] can be used in the Telemetry Data
	Profile field.		Profile field.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Reserved | Length |		| Type | Reserved | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Value ~		~ Value ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Telemetry Data TLV Format		Figure 3: Telemetry Data TLV Format
	Telemetry Data TLV is a variable-length field. Multiple TLVs MAY		Telemetry Data TLV is a variable-length field. Multiple TLVs MAY
	be placed in an HTS packet. Additional TLVs may be enclosed		be placed in an HTS packet. Additional TLVs may be enclosed
	within a given TLV, subject to the semantics of the (outer) TLV in		within a given TLV, subject to the semantics of the (outer) TLV in
	question. Figure 3 presents the format of a Telemetry Data TLV,		question. Figure 3 presents the format of a Telemetry Data TLV,
	where fields are defined as the following:		where fields are defined as the following:
	Type - a one-octet-long field that characterizes the		- Type - a one-octet-long field that characterizes the
	interpretation of the Value field.		interpretation of the Value field.
	Reserved - one-octet-long field.		- Reserved - one-octet-long field.
	Length - two-octet-long field equal to the length of the Value		- Length - two-octet-long field equal to the length of the Value
	field in octets.		field in octets.
	Value - a variable-length field. The value of the Type field		- Value - a variable-length field. The value of the Type field
	determines its interpretation and encoding. IOAM data fields,		determines its interpretation and encoding. IOAM data fields,
	defined in [I-D.ietf-ippm-ioam-data], MAY be carried in the		defined in [I-D.ietf-ippm-ioam-data], MAY be carried in the
	Value field.		Value field.
	All multibyte fields defined in this specification are in network		All multibyte fields defined in this specification are in network
	byte order.		byte order.
	4.2. Operation of the HTS Intermediate Node		4.2. Operation of the HTS Intermediate Node
	Upon receiving the trigger packet, the HTS intermediate node MUST:		Upon receiving the trigger packet, the HTS intermediate node MUST:
	o copy the transport information;		* copy the transport information;
	o start the HTS Follow-up Timer for the obtained flow;		* start the HTS Follow-up Timer for the obtained flow;
	o transmit the trigger packet.		* transmit the trigger packet.
	Upon receiving the follow-up packet, the HTS intermediate node MUST:		Upon receiving the follow-up packet, the HTS intermediate node MUST:
	1. verify that the matching transport information exists and the		1. verify that the matching transport information exists and the
	Full flag is cleared, then stop the associated HTS Follow-up		Full flag is cleared, then stop the associated HTS Follow-up
	Timer;		Timer;
	2. otherwise, transmit the received packet. Proceed to Step 8;		2. otherwise, transmit the received packet. Proceed to Step 8;
	3. collect telemetry data requested in the Telemetry Data Profile		3. collect telemetry data requested in the Telemetry Data Profile
	skipping to change at page 9, line 18 ¶		skipping to change at page 9, line 22 ¶
	value of the field in the received follow-up packet incremented		value of the field in the received follow-up packet incremented
	by one;		by one;
	7. copy collected telemetry data into the first Telemetry Data TLV's		7. copy collected telemetry data into the first Telemetry Data TLV's
	Value field and then transmit the packet;		Value field and then transmit the packet;
	8. processing completed.		8. processing completed.
	If the HTS Follow-up Timer expires, the intermediate node MUST:		If the HTS Follow-up Timer expires, the intermediate node MUST:
	o originate the follow-up packet using transport information		* originate the follow-up packet using transport information
	associated with the expired timer;		associated with the expired timer;
	o initialize the HTS shim by setting the Version field's value to		* initialize the HTS shim by setting the Version field's value to
	0b00 and Sequence Number field to 0. Values of HTS Shim Length		0b00 and Sequence Number field to 0. Values of HTS Shim Length
	and Telemetry Data Profile fields MAY be set according to the		and Telemetry Data Profile fields MAY be set according to the
	local policy.		local policy.
	o copy telemetry information into Telemetry Data TLV's Value field		* copy telemetry information into Telemetry Data TLV's Value field
	and transmit the packet.		and transmit the packet.
	If the intermediate node receives a "late" follow-up packet, i.e., a		If the intermediate node receives a "late" follow-up packet, i.e., a
	packet to which the node has no associated HTS Follow-up timer, the		packet to which the node has no associated HTS Follow-up timer, the
	node MUST forward the "late" packet.		node MUST forward the "late" packet.
	4.3. Operation of the HTS Egress Node		4.3. Operation of the HTS Egress Node
	Upon receiving the trigger packet, the HTS egress node MUST:		Upon receiving the trigger packet, the HTS egress node MUST:
	o copy the transport information;		* copy the transport information;
	o start the HTS Collection timer for the obtained flow.		* start the HTS Collection timer for the obtained flow.
	When the egress node receives the follow-up packet for the known		When the egress node receives the follow-up packet for the known
	flow, i.e., the flow to which the Collection timer is running, the		flow, i.e., the flow to which the Collection timer is running, the
	node for each of Telemetry Data TLVs MUST:		node for each of Telemetry Data TLVs MUST:
	o if HTS is used in the authenticated mode, verify the		* if HTS is used in the authenticated mode, verify the
	authentication of the Telemetry Data TLV using the Authentication		authentication of the Telemetry Data TLV using the Authentication
	sub-TLV (see Section 5);		sub-TLV (see Section 5);
	o copy telemetry information from the Value field;		* copy telemetry information from the Value field;
	o restart the corresponding Collection timer.		* restart the corresponding Collection timer.
	When the Collection timer expires, the egress relays the collected		When the Collection timer expires, the egress relays the collected
	telemetry information for processing and analysis to a local or		telemetry information for processing and analysis to a local or
	remote agent.		remote agent.
	4.4. Considerations for HTS Timers		4.4. Considerations for HTS Timers
	This specification defines two timers - HTS Follow-up and HTS		This specification defines two timers - HTS Follow-up and HTS
	Collection. For the particular flow, there MUST be no more than one		Collection. For the particular flow, there MUST be no more than one
	HTS Trigger, values of HTS timers bounded by the rate of the trigger		HTS Trigger, values of HTS timers bounded by the rate of the trigger
	skipping to change at page 10, line 29 ¶		skipping to change at page 10, line 33 ¶
	network. Multicast services are important, and the ability to		network. Multicast services are important, and the ability to
	collect telemetry information is invaluable in delivering a high		collect telemetry information is invaluable in delivering a high
	quality of experience. While the replication of data packets is		quality of experience. While the replication of data packets is
	necessary, replication of HTS follow-up packets is not. Replication		necessary, replication of HTS follow-up packets is not. Replication
	of multicast data packets down a multicast tree may be set based on		of multicast data packets down a multicast tree may be set based on
	multicast routing information or explicit information included in the		multicast routing information or explicit information included in the
	special header, as, for example, in Bit-Indexed Explicit Replication		special header, as, for example, in Bit-Indexed Explicit Replication
	[RFC8296]. A replicating node processes the HTS packet as defined		[RFC8296]. A replicating node processes the HTS packet as defined
	below:		below:
	o the first transmitted multicast packet MUST be followed by the		* the first transmitted multicast packet MUST be followed by the
	received corresponding HTS packet as described in Section 4.2;		received corresponding HTS packet as described in Section 4.2;
	o each consecutively transmitted copy of the original multicast		* each consecutively transmitted copy of the original multicast
	packet MUST be followed by the new HTS packet originated by the		packet MUST be followed by the new HTS packet originated by the
	replicating node that acts as an intermediate HTS node when the		replicating node that acts as an intermediate HTS node when the
	HTS Follow-up timer expired.		HTS Follow-up timer expired.
	As a result, there are no duplicate copies of Telemetry Data TLV for		As a result, there are no duplicate copies of Telemetry Data TLV for
	the same pair of ingress and egress interfaces. At the same time,		the same pair of ingress and egress interfaces. At the same time,
	all ingress/egress pairs traversed by the given multicast packet		all ingress/egress pairs traversed by the given multicast packet
	reflected in their respective Telemetry Data TLV. Consequently, a		reflected in their respective Telemetry Data TLV. Consequently, a
	centralized controller would reconstruct and analyze the state of the		centralized controller would reconstruct and analyze the state of the
	particular multicast distribution tree based on HTS packets collected		particular multicast distribution tree based on HTS packets collected
	skipping to change at page 11, line 18 ¶		skipping to change at page 11, line 27 ¶
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Authentic. Type| HMAC Type | Length |		|Authentic. Type| HMAC Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Digest |		| Digest |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: HMAC sub-TLV		Figure 4: HMAC sub-TLV
	where fields are defined as follows:		where fields are defined as follows:
	o Authentication Type - is a one-octet-long field, value TBA2		* Authentication Type - is a one-octet-long field, value TBA2
	allocated by IANA Section 6.2.		allocated by IANA Section 6.2.
	o Length - two-octet-long field, set equal to the length of the		* Length - two-octet-long field, set equal to the length of the
	Digest field in octets.		Digest field in octets.
	o HMAC Type - is a one-octet-long field that identifies the type of		* HMAC Type - is a one-octet-long field that identifies the type of
	the HMAC and the length of the digest and the length of the digest		the HMAC and the length of the digest and the length of the digest
	according to the HTS HMAC Type sub-registry (see Section 6.4).		according to the HTS HMAC Type sub-registry (see Section 6.4).
	o Digest - is a variable-length field that carries HMAC digest of		* Digest - is a variable-length field that carries HMAC digest of
	the text that includes the encompassing TLV.		the text that includes the encompassing TLV.
	This specification defines the use of HMAC-SHA-256 truncated to 128		This specification defines the use of HMAC-SHA-256 truncated to 128
	bits ([RFC4868]) in HTS. Future specifications may define the use in		bits ([RFC4868]) in HTS. Future specifications may define the use in
	HTS of more advanced cryptographic algorithms or the use of digest of		HTS of more advanced cryptographic algorithms or the use of digest of
	a different length. HMAC is calculated as defined in [RFC2104] over		a different length. HMAC is calculated as defined in [RFC2104] over
	text as the concatenation of the Sequence Number field of the follow-		text as the concatenation of the Sequence Number field of the follow-
	up packet (see Figure 1) and the preceding data collected in the		up packet (see Figure 1) and the preceding data collected in the
	Telemetry Data TLV. The digest then MUST be truncated to 128 bits		Telemetry Data TLV. The digest then MUST be truncated to 128 bits
	and written into the Digest field. Distribution and management of		and written into the Digest field. Distribution and management of
	skipping to change at page 12, line 13 ¶		skipping to change at page 12, line 20 ¶
	outside the scope of this document.		outside the scope of this document.
	6. IANA Considerations		6. IANA Considerations
	6.1. IOAM Option-Type for HTS		6.1. IOAM Option-Type for HTS
	The IOAM Option-Type registry is requested in		The IOAM Option-Type registry is requested in
	[I-D.ietf-ippm-ioam-data]. IANA is requested to allocate a new code		[I-D.ietf-ippm-ioam-data]. IANA is requested to allocate a new code
	point as listed in Table 1.		point as listed in Table 1.
	+-------+----------------------------------+---------------+		+=======+==================================+===============+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+----------------------------------+---------------+		+=======+==================================+===============+
	| TBA1 | IOAM Hybrid Two-Step Option-Type | This document |		| TBA1 | IOAM Hybrid Two-Step Option-Type | This document |
	+-------+----------------------------------+---------------+		+-------+----------------------------------+---------------+
	Table 1: IOAM Option-Type for HTS		Table 1: IOAM Option-Type for HTS
	6.2. HTS TLV Registry		6.2. HTS TLV Registry
	IANA is requested to create the HTS TLV Type registry. All code		IANA is requested to create the HTS 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 specified in [RFC8126].		according to the "IETF Review" procedure 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		allocated according to the "First Come First Served" procedure
	specified in [RFC8126]. The remaining code points are allocated		specified in [RFC8126]. The remaining code points are allocated
	according to Table 2:		according to Table 2:
	+-----------+--------------+---------------+		+===========+==============+===============+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-----------+--------------+---------------+		+===========+==============+===============+
	| 0 | Reserved | This document |		| 0 | Reserved | This document |
			+-----------+--------------+---------------+
	| 1- 175 | Unassigned | This document |		| 1- 175 | Unassigned | This document |
			+-----------+--------------+---------------+
	| 176 - 239 | Unassigned | This document |		| 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 2: HTS TLV Type Registry		Table 2: HTS TLV Type Registry
	6.3. HTS Sub-TLV Type Sub-registry		6.3. HTS Sub-TLV Type Sub-registry
	IANA is requested to create the HTS sub-TLV Type sub-registry as part		IANA is requested to create the HTS sub-TLV Type sub-registry as part
	of the HTS TLV Type registry. All code points in the range 1 through		of the HTS TLV Type registry. All code points in the range 1 through
	175 in this registry shall be allocated according to the "IETF		175 in this registry shall be allocated according to the "IETF
	Review" procedure specified in [RFC8126]. Code points in the range		Review" procedure specified in [RFC8126]. Code points in the range
	176 through 239 in this registry shall be allocated according to the		176 through 239 in this registry shall be allocated according to the
	"First Come First Served" procedure specified in [RFC8126]. The		"First Come First Served" procedure specified in [RFC8126]. The
	remaining code points are allocated according to Table 3:		remaining code points are allocated according to Table 3:
	+-----------+--------------+---------------+		+===========+==============+===============+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-----------+--------------+---------------+		+===========+==============+===============+
	| 0 | Reserved | This document |		| 0 | Reserved | This document |
			+-----------+--------------+---------------+
	| 1- 175 | Unassigned | This document |		| 1- 175 | Unassigned | This document |
			+-----------+--------------+---------------+
	| 176 - 239 | Unassigned | This document |		| 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 3: HTS Sub-TLV Type Sub-registry		Table 3: HTS Sub-TLV Type Sub-registry
	This document defines the following new values in the IETF Review		This document defines the following new values in the IETF Review
	range of the HTS sub-TLV Type sub-registry:		range of the HTS sub-TLV Type sub-registry:
	+-------+-------------+----------+---------------+		+=======+=============+==========+===============+
	| Value | Description | TLV Used | Reference |		| Value | Description | TLV Used | Reference |
	+-------+-------------+----------+---------------+		+=======+=============+==========+===============+
	| TBA2 | HMAC | Any | This document |		| TBA2 | HMAC | Any | This document |
	+-------+-------------+----------+---------------+		+-------+-------------+----------+---------------+
	Table 4: HTS sub-TLV Types		Table 4: HTS sub-TLV Types
	6.4. HMAC Type Sub-registry		6.4. HMAC Type Sub-registry
	IANA is requested to create the HMAC Type sub-registry as part of the		IANA is requested to create the HMAC Type sub-registry as part of the
	HTS TLV Type registry. All code points in the range 1 through 127 in		HTS 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 specified in [RFC8126]. Code points in the range 128		procedure 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 specified in [RFC8126]. The		"First Come First Served" procedure specified in [RFC8126]. The
	remaining code points are allocated according to Table 5:		remaining code points are allocated according to Table 5:
	+-----------+--------------+---------------+		+===========+==============+===============+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-----------+--------------+---------------+		+===========+==============+===============+
	| 0 | Reserved | This document |		| 0 | Reserved | This document |
			+-----------+--------------+---------------+
	| 1- 127 | Unassigned | This document |		| 1- 127 | Unassigned | This document |
			+-----------+--------------+---------------+
	| 128 - 239 | Unassigned | This document |		| 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 5: HMAC Type Sub-registry		Table 5: HMAC Type Sub-registry
	This document defines the following new values in the HMAC Type sub-		This document defines the following new values in the HMAC Type sub-
	registry:		registry:
	+-------+-----------------------------+---------------+		+=======+=============================+===============+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+-----------------------------+---------------+		+=======+=============================+===============+
	| 1 | HMAC-SHA-256 16 octets long | This document |		| 1 | HMAC-SHA-256 16 octets long | This document |
	+-------+-----------------------------+---------------+		+-------+-----------------------------+---------------+
	Table 6: HMAC Types		Table 6: HMAC Types
	7. Security Considerations		7. Security Considerations
	Nodes that practice the HTS method are presumed to share a trust		Nodes that practice the HTS method are presumed to share a trust
	model that depends on the existence of a trusted relationship among		model that depends on the existence of a trusted relationship among
	nodes. This is necessary as these nodes are expected to correctly		nodes. This is necessary as these nodes are expected to correctly
	skipping to change at page 15, line 32 ¶		skipping to change at page 16, line 18 ¶
	<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>.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-ippm-ioam-data]		[I-D.ietf-ippm-ioam-data]
	Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields		Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
	for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in		for In-situ OAM", Work in Progress, Internet-Draft, draft-
	progress), November 2020.		ietf-ippm-ioam-data-12, 21 February 2021,
			<https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-
			12>.
	[I-D.ietf-ippm-ioam-direct-export]		[I-D.ietf-ippm-ioam-direct-export]
	Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F.,		Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F.,
	Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ		Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ
	OAM Direct Exporting", draft-ietf-ippm-ioam-direct-		OAM Direct Exporting", Work in Progress, Internet-Draft,
	export-02 (work in progress), November 2020.		draft-ietf-ippm-ioam-direct-export-03, 17 February 2021,
			<https://tools.ietf.org/html/draft-ietf-ippm-ioam-direct-
			export-03>.
	[I-D.song-ippm-postcard-based-telemetry]		[I-D.song-ippm-postcard-based-telemetry]
	Song, H., Zhou, T., Li, Z., Mirsky, G., Shin, J., and K.		Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou,
	Lee, "Postcard-based On-Path Flow Data Telemetry using		T., Li, Z., Shin, J., and K. Lee, "Postcard-based On-Path
	Packet Marking", draft-song-ippm-postcard-based-		Flow Data Telemetry using Packet Marking", Work in
	telemetry-08 (work in progress), October 2020.		Progress, Internet-Draft, draft-song-ippm-postcard-based-
			telemetry-09, 19 February 2021,
			<https://tools.ietf.org/html/draft-song-ippm-postcard-
			based-telemetry-09>.
	[P4.INT] "In-band Network Telemetry (INT)", P4.org Specification,		[P4.INT] "In-band Network Telemetry (INT)", P4.org Specification,
	October 2017.		October 2017.
	[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>.
	[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with		[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
	skipping to change at page 16, line 36 ¶		skipping to change at page 17, line 27 ¶
	L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,		L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
	"Alternate-Marking Method for Passive and Hybrid		"Alternate-Marking Method for Passive and Hybrid
	Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,		Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
	January 2018, <https://www.rfc-editor.org/info/rfc8321>.		January 2018, <https://www.rfc-editor.org/info/rfc8321>.
	Authors' Addresses		Authors' Addresses
	Greg Mirsky		Greg Mirsky
	ZTE Corp.		ZTE Corp.
	Email: gregimirsky@gmail.com		Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com
	Wang Lingqiang		Wang Lingqiang
	ZTE Corporation		ZTE Corporation
	No 19 ,East Huayuan Road		No 19 ,East Huayuan Road
	Beijing 100191		Beijing
	P.R.China
	Phone: +86 10 82963945		Phone: +86 10 82963945
	Email: wang.lingqiang@zte.com.cn		Email: wang.lingqiang@zte.com.cn
	Guo Zhui		Guo Zhui
	ZTE Corporation		ZTE Corporation
	No 19 ,East Huayuan Road		No 19 ,East Huayuan Road
	Beijing 100191		Beijing
	P.R.China
	Phone: +86 10 82963945		Phone: +86 10 82963945
	Email: guo.zhui@zte.com.cn		Email: guo.zhui@zte.com.cn
	Haoyu Song		Haoyu Song
	Futurewei Technologies		Futurewei Technologies
	2330 Central Expressway		2330 Central Expressway
	Santa Clara		Santa Clara,
	USA		United States of America
	Email: hsong@futurewei.com		Email: hsong@futurewei.com
End of changes. 82 change blocks.
	116 lines changed or deleted		135 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/