< draft-mirsky-ippm-hybrid-two-step-07.txt		draft-mirsky-ippm-hybrid-two-step-08.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: June 7, 2021 G. Zhui		Expires: August 19, 2021 G. Zhui
	ZTE Corporation		ZTE Corporation
	H. Song		H. Song
	Futurewei Technologies		Futurewei Technologies
	December 4, 2020		February 15, 2021
	Hybrid Two-Step Performance Measurement Method		Hybrid Two-Step Performance Measurement Method
	draft-mirsky-ippm-hybrid-two-step-07		draft-mirsky-ippm-hybrid-two-step-08
	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 June 7, 2021.		This Internet-Draft will expire on August 19, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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/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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 8, line 29 ¶		skipping to change at page 8, line 29 ¶
	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;		o copy the transport information;
	o start the HTS Follow-up Timer for the obtained flow.		o start the HTS Follow-up Timer for the obtained flow;
			o 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:
	o verify that the matching transport information exists and the Full		1. verify that the matching transport information exists and the
	flag is cleared, then stop the associated HTS Follow-up timer;		Full flag is cleared, then stop the associated HTS Follow-up
			Timer;
	o collect telemetry data requested in the Telemetry Data Profile		2. otherwise, transmit the received packet. Proceed to Step 8;
	field or defined by the local HTS policy;
	o if adding the collected telemetry would not exceed MTU, then		3. collect telemetry data requested in the Telemetry Data Profile
	append data as a new Telemetry Data TLV and transmit the follow-up		field or defined by the local HTS policy;
	packet;
	o otherwise, set the value of the Full flag to one and transmit the		4. if adding the collected telemetry would not exceed MTU, then
	received a follow-up packet;		append data as a new Telemetry Data TLV and transmit the follow-
			up packet. Proceed to Step 8;
	o originate the new follow-up packet using the same transport		5. otherwise, set the value of the Full flag to one, copy the
	information. The value of the Sequence Number field in the HTS		transport information from the received follow-up packet and
	shim MUST be set to the value of the field in the received follow-		transmit it accordingly. Proceed to Step 8;
	up packet incremented by one;
	o copy collected telemetry data into the first Telemetry Data TLV's		6. originate the new follow-up packet using the transport
	Value field and then transmit the packet.		information copied from the received follow-up packet. The value
			of the Sequence Number field in the HTS shim MUST be set to the
			value of the field in the received follow-up packet incremented
			by one;
			7. copy collected telemetry data into the first Telemetry Data TLV's
			Value field and then transmit the packet;
			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		o 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 Version field to 0b00 and		o initialize the HTS shim by setting the Version field's value to
	Sequence Number field to 0. Values of HTS Shim Length and		0b00 and Sequence Number field to 0. Values of HTS Shim Length
	Telemetry Data Profile fields MAY be set according to the local		and Telemetry Data Profile fields MAY be set according to the
	policy.		local policy.
	o copy telemetry information into Telemetry Data TLV's Value field		o 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
End of changes. 13 change blocks.
	25 lines changed or deleted		34 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/