< draft-wang-ippm-stamp-hbh-extensions-00.txt		draft-wang-ippm-stamp-hbh-extensions-01.txt >
	IP Performance Measurement Group Y. Wang		IP Performance Measurement Group Y. Wang
	Internet-Draft T. Zhou		Internet-Draft T. Zhou
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: January 11, 2021 July 10, 2020		Expires: April 30, 2021 October 27, 2020
	Simple Two-way Active Measurement Protocol Extensions for Hop-by-Hop OAM		Simple Two-way Active Measurement Protocol Extensions for Hop-by-Hop OAM
	Data Collection		Data Collection
	draft-wang-ippm-stamp-hbh-extensions-00		draft-wang-ippm-stamp-hbh-extensions-01
	Abstract		Abstract
	This document defines optional TLVs which are carried in Simple Two-		This document defines optional TLVs which are carried in Simple Two-
	way Active Measurement Protocol (STAMP) test packets to enhance the		way Active Measurement Protocol (STAMP) test packets to enhance the
	STAMP base functions. Such extensions to STAMP enable OAM data		STAMP base functions. Such extensions to STAMP enable OAM data
	collection at every node that STAMP test packets traverse.		measurement and collection at every node and link along a STAMP test
			packet's delivery path.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 40 ¶		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 January 11, 2021.		This Internet-Draft will expire on April 30, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 28 ¶		skipping to change at page 2, line 29 ¶
	3.3. Backward HbH Delay TLV . . . . . . . . . . . . . . . . . 7		3.3. Backward HbH Delay TLV . . . . . . . . . . . . . . . . . 7
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.1. Normative References . . . . . . . . . . . . . . . . . . 9		6.1. Normative References . . . . . . . . . . . . . . . . . . 9
	6.2. Informative References . . . . . . . . . . . . . . . . . 9		6.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	Simple Two-way Active Measurement Protocol (STAMP) enables the		Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] enables
	measurement of both one-way and round-trip performance metrics, such		the measurement of both one-way and round-trip performance metrics,
	as delay, delay variation, and packet loss [RFC8762]. In the STAMP		such as delay, delay variation, and packet loss. In the STAMP
	session, the bidirectional packet flow is transmited between STAMP		session, the bidirectional packet flow is transmited between STAMP
	Session-Sender and STAMP Session-Reflector. The STAMP Session-		Session-Sender and STAMP Session-Reflector. The STAMP Session-
	Reflector receives packets transmited from Session-Sender and acts		Reflector receives test packets transmited from Session-Sender and
	according to the configuration. However, the performance of		acts according to the configuration. However, the performance of
	intermediate nodes that STAMP test packets traverse are invisible.		intermediate nodes and links that STAMP test packets traverse are
	And the STAMP instance must be configured at every intermediate node		invisible. In additon, the STAMP instance must be configured at
	to measure the performance per node that test packets traverse, which		every intermediate node to measure the performance per node and link
	increases the complexity of OAM in large-scale networks.		that test packets traverse, which increases the complexity of OAM in
			large-scale networks.
	This document extents optional TLVs to STAMP which enable OAM data		STAMP Extensions have defined several optional TLVs to enhance the
	collection at every node that STAMP test packets traverse, such as		STAMP base functions. These optional TLVs are defined as updates of
	measurement of delay, packet loss, delay variation per hop, and		the STAMP Optional Extensions [I-D.ietf-ippm-stamp-option-tlv]. This
	record of route information. STAMP Extensions have defined several		document extents optional TLVs to STAMP, which enable performance
	optionnal TLVs to enhance the STAMP base functions. These optional		measurement at every intermediate node and link along a STAMP test
	TLVs are defined as updates of the STAMP Optional Extensions		packet's delivery path, such as measurement of delay, delay
	[I-D.ietf-ippm-stamp-option-tlv]. The following sections describe		variation, packet loss, and record of route information. The
	the use of TLVs for STAMP that extend STAMP capability beyond its		following sections describe the use of TLVs for STAMP that extend
	base specification.		STAMP capability beyond its base specification.
	2. Terminology		2. Terminology
	Following are abbreviations used in this document:		Following are abbreviations used in this document:
	STAMP: Simple Two-way Active Measurement Protocol.		STAMP: Simple Two-way Active Measurement Protocol.
	IOAM: In-situ OAM.		IOAM: In-situ OAM.
	HbH: Hop-by-Hop.		HbH: Hop-by-Hop.
	3. TLV Extensions to STAMP		3. TLV Extensions to STAMP
	3.1. IOAM Tracing Data TLV		3.1. IOAM Tracing Data TLV
	STAMP Session-Sender MAY place the IOAM Tracing Data TLV in STAMP		STAMP Session-Sender MAY place the IOAM Tracing Data TLV in Session-
	Session-Sender test packets to record the IOAM tracing data of every		Sender test packets to record the IOAM tracing data at every IOAM
	IOAM capable node that the STAMP Session-Sender test packet traverses		capable node along the Session-Sender test packet's forward-delivery
	in the forward path. As STAMP uses symmetrical packets, the Session-		path. As STAMP uses symmetrical packets, the Session-Sender MUST set
	Sender MUST set the Length value as a multiple of 4 octets according		the Length value as a multiple of 4 octets according to the number of
	to the number of intermediate nodes and the IOAM-Trace-Type (i.e. a		nodes and the IOAM-Trace-Type (i.e. a 24-bit identifier which
	24-bit identifier which specifies which data types are used in the		specifies which data types are used in the node data list
	node data list [I-D.ietf-ippm-ioam-data]). And the node-data-copied-		[I-D.ietf-ippm-ioam-data]). And the node-data-copied-list fields
	list fields MUST be set to zero upon Session-Sender test packets		MUST be set to zero upon Session-Sender test packets transmission and
	transmission and ignored upon receipt.		ignored upon receipt.
	The IOAM Tracing Data TLV has the following format:		The IOAM Tracing Data TLV has the following format:
	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
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| IOAM-Tracing-Data Type | Length |		| IOAM-Tracing-Data Type | Length |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	| node data copied list [0] |		| node data copied list [0] |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	skipping to change at page 3, line 50 ¶		skipping to change at page 3, line 50 ¶
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	~ ... ~		~ ... ~
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	| node data copied list [n] |		| node data copied list [n] |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Fig. 1 IOAM Tracing Data TLV Format		Fig. 1 IOAM Tracing Data TLV Format
	where fields are defined as the following:		where fields are defined as the following:
	IOAM-Tracing-Data Type: To be assigned by IANA.		o IOAM-Tracing-Data Type: To be assigned by IANA.
	Length: A 2-octet field that indicates the length of the value field		o Length: A 2-octet field that indicates the length of the value
	in octets and equal to a multiple of 4 octets dependent on the number		field in octets and equal to a multiple of 4 octets dependent on
	of nodes and IOAM-Trace-Type bits.		the number of nodes and IOAM-Trace-Type bits.
	node data copied list [0..n]: A variable-length field, which record		o node data copied list [0..n]: A variable-length field, which
	the copied content of each node data element determined by the IOAM-		record the copied content of each node data element determined by
	Trace-Type. The order of packing the data fields in each node data		the IOAM-Trace-Type. The order of packing the data fields in each
	element follows the bit order of the IOAM-Trace-Type field (see		node data element follows the bit order of the IOAM-Trace-Type
	section 4.4.1 of [I-D.ietf-ippm-ioam-data]). The last node data		field (see section 4.4.1 of [I-D.ietf-ippm-ioam-data]). The last
	element in this list is the node data of the first IOAM trace capable		node data element in this list is the node data of the first IOAM
	node in the path.		trace capable node in the path.
	In an IOAM domain, the STAMP Session-Sender and the STAMP Session-		In an IOAM domain, the STAMP Session-Sender and the STAMP Session-
	Reflector MAY be configured as the IOAM encapsulating node and the		Reflector MAY be configured as the IOAM encapsulating node and the
	IOAM decapsulating node. The STAMP Session-Sender (i.e. the IOAM		IOAM decapsulating node. The STAMP Session-Sender (i.e. the IOAM
	encapsulating node) generates the STAMP test packet with the IOAM		encapsulating node) generates the test packet with the IOAM Tracing
	Tracing Data TLV. For applying the IOAM Trace-Option functionalities		Data TLV. For applying the IOAM Trace-Option functionalities to the
	to the STAMP Session-Sender test packet, the STAMP Session-Sender		Session-Sender test packet, the Session-Sender must inserts the
	must inserts the "trace option header" and allocate an node-data-list		"trace option header" and allocate an node-data-list array
	array [I-D.ietf-ippm-ioam-data] into "option data" fields of Hop-by-		[I-D.ietf-ippm-ioam-data] into "option data" fields of Hop-by-Hop
	Hop Options header in IPv6 packets [I-D.ietf-ippm-ioam-ipv6-options],		Options header in IPv6 packets [I-D.ietf-ippm-ioam-ipv6-options], and
	and sets the corresponding bits in the IOAM-Trace-Type. Also, the		sets the corresponding bits in the IOAM-Trace-Type. Also, the STAMP
	STAMP Session-Sender allocates an node-data-list array which is used		Session-Sender allocates a node-data-copied-list array in the
	to store OAM data retrieved from every IOAM transit nodes while the		optional IOAM Tracing Data TLV to store OAM data retrieved from every
	Session-Sender test packets traverse the path.		IOAM transit node along the Session-Sender test packet's delivery
			path.
	When the STAMP Session-Reflector (i.e. the IOAM decapsulating node)		When the STAMP Session-Reflector (i.e. the IOAM decapsulating node)
	received the STAMP Session-Sender test packet with the IOAM-Tracing-		received the STAMP Session-Sender test packet with the IOAM-Tracing-
	Data TLV, it MUST copy the node-data-list array into the node-data-		Data TLV, it MUST copy the node-data-list array into the node-data-
	copied-list array carried in the reflected test packet before		copied-list array carried in the Session-Reflector test packet before
	transmission and MUST remove the IOAM-Data-Fields. Hence, using		transmission and MUST remove the IOAM-Data-Fields. Hence, carrying
	IOAM-Tracing-Data TLV in STAMP testing enables hop-by-hop OAM data		IOAM-Tracing-Data TLV in STAMP test packets enables OAM data
	collection.		collection and measurement at every node and link.
	Also the STAMP Session-Reflector MAY be configured as IOAM		Also the STAMP Session-Reflector MAY be configured as IOAM
	encapsulating node to apply the IOAM Trace-Option functionalities to		encapsulating node to apply the IOAM Trace-Option functionalities to
	the reflected test packet. Hence, hop-by-hop OAM data collection can		the Session-Reflector test packet. Hence, OAM data collection and
	be also enabled for the backward path that the reflected packets		measurement can be also enabled at every node and link along the
	traverse. When the reflected packet arrives at the Session-Sender		Session-Reflector test packet's backward delivery path. When the
	receives, it can be either locally processed or sent to the		reflected packet arrives at the Session-Sender, it can be either
	centralized controller.		locally processed or sent to the centralized controller.
	3.2. Forward HbH Delay TLV		3.2. Forward HbH Delay TLV
	STAMP Session-Sender MAY place the Forward HbH Delay TLV in Session-		STAMP Session-Sender MAY place the Forward HbH Delay TLV in Session-
	Sender test packets to record the ingress timestamp and engress		Sender test packets to record the ingress timestamp and the egress
	timestamp at every intermediate nodes in the forward path that STAMP		timestamp at every intermediate nodes along the Session-Sender test
	test packets traverse. The Session-Sender MUST set the Length value		packet's forward path. The Session-Sender MUST set the Length value
	according to the number of intermediate nodes in the forward path and		according to the number of explicitly listed intermediate nodes in
	the timestamp formats. There are several methods to synchronize the		the forward path and the timestamp formats. There are several
	clock, e.g., Network Time Protocol (NTP) [RFC5905]. For example, if		methods to synchronize the clock, e.g., Network Time Protocol (NTP)
	a 64-bit timestamp format defined in NTP is used, the Length value		[RFC5905]. For example, if a 64-bit timestamp format defined in NTP
	MUST be set as a multiple of 8 octets. The Timestamp Tuple list		is used, the Length value MUST be set as a multiple of 8 octets. The
	(Ingress Timestamp [0..n], Engress Timestamp [0..n]) fields MUST be		Timestamp Tuple list [1..n] fields MUST be set to zero upon Session-
	set to zero upon Session-Sender test packets transmission and ignored		Sender test packets transmission and ignored upon receipt.
	upon receipt.
	The Forward HbH Delay TLV has the following format:		The Forward HbH Delay TLV has the following format:
	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
	+-------------------------------+---------------+---------------+		+-------------------------------+---------------+---------------+
	| Forward HbH Delay Type | Length | Node Left |		| Forward HbH Delay Type | Length | Node Left |
	+-------------------------------+---------------+---------------+		+-------------------------------+---------------+---------------+
	| Ingress Timestamp [0] |
	| |		| |
	+---------------------------------------------------------------+		| Timestamp Tuple list [1] |
	| Engress Timestamp [0] |		| |
	| |		| |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	~ ... ~		~ ... ~
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	| Ingress Timestamp [n] |
	| |		| |
	+---------------------------------------------------------------+		| Timestamp Tuple list [n] |
	| Engress Timestamp [n] |		| |
	| |		| |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Fig. 2 Forward HbH Delay TLV Format		Fig. 2 Forward HbH Delay TLV Format
	where fields are defined as the following:		where fields are defined as the following:
	Forward HbH Delay Type: To be assigned by IANA.		o Forward HbH Delay Type: To be assigned by IANA.
	Length: A 8-bit field that indicates the length of the value portion		o Length: A 8-bit field that indicates the length of the value
	in octets and MUST be a multiple of 8 octets according to the number		portion in octets and MUST be a multiple of 8 octets according to
	of intermediate nodes in the forward path.		the number of explicitly listed intermediate nodes in the forward
			path.
	Node Left: A 8-bit unsigned integer, which indicates the number of		o Node Left: A 8-bit unsigned integer, which indicates the number of
	intermediate nodes remaining. That is, number of exlicitly listed		intermediate nodes remaining. That is, number of exlicitly listed
	intermediate nodes still to be visited before reaching the		intermediate nodes still to be visited before reaching the
	destination node in the forward path. The Node Left field is set to		destination node in the forward path. The Node Left field is set
	n-1, where n is the number of intermediate nodes.		to n-1, where n is the number of intermediate nodes.
	Timestamp Tuple list (Ingress Timestamp [0..n], Engress Timestamp		o Timestamp Tuple list [1..n]: A variable-length field, which record
	[0..n]): A variable-length field, which record the timestamp when the		the timestamp when the Session-Sender test packet is received at
	Session-Sender test packet is received at the ingress of the n-th		the ingress of the n-th intermediate node Ingress Timestamp [n]
	intermediate node and the timestamp when the Session-Sender test		and the timestamp when the Session-Sender test packet is sent at
	packet is sent at engress of the n-th intermediate node. For		egress of the n-th intermediate node Engress Timestamp [n]. For
	example, if a 64-bit timestamp format defined in NTP is used, the		example, if a 64-bit timestamp format defined in NTP is used, the
	length of each Timestamp tuple (Ingress Timestamp [n], Engress		length of each Timestamp tuple (Ingress Timestamp [n], Engress
	Timestamp [n]) must be 16 octets. The Timestamp Tuple list is		Timestamp [n]) must be 16 octets. The Timestamp Tuple list is
	encoded starting from the last intermediate node which is exlicitly		encoded starting from the last intermediate node which is
	listed. That is, the first element of the Timestamp Tuple (Ingress		exlicitly listed. That is, the first element of the Timestamp
	Timestamp [0], Engress Timestamp [0]) records the timestamps when the		Tuple list [1] records the timestamps when the Session-Sender test
	Session-Sender test packet received and forwarded at the last		packet received and forwarded at the last intermediate node of a
	intermediate node of a explicit path, the second element records the		explicit path, the second element records the penultimate
	penultimate Timestamp Tuple when the Session-Sender test packet		Timestamp Tuple when the Session-Sender test packet received and
	received and forwarded at the penultimate intermediate node of a		forwarded at the penultimate intermediate node of a explicit path,
	explicit path, and so on.		and so on.
	In the following reference topology, Node N1, N2, N3, N4 and N5 are		In the following reference topology, Node N1, N2, N3, N4 and N5 are
	SRv6 capable nodes. Node N1 is the STAMP Session-Sender and Node N5		SRv6 capable nodes. Node N1 is the STAMP Session-Sender and Node N5
	is the STAMP Session-Reflector. T1 is the Timestamp taken by the		is the STAMP Session-Reflector. T1 is the Timestamp taken by the
	Session-Sender (i.e. N1) at the start of transmitting the test		Session-Sender (i.e. N1) at the start of transmitting the test
	packet. T2 is the Receive Timestamp when the test packet was		packet. T2 is the Receive Timestamp when the test packet was
	received by the Session-Reflector (i.e. N5). T3 is the Timestamp		received by the Session-Reflector (i.e. N5). T3 is the Timestamp
	taken by the Session-Reflector at the start of transmitting the test		taken by the Session-Reflector at the start of transmitting the test
	packet. T4 is the Receive Timestamp when the test packet was		packet. T4 is the Receive Timestamp when the test packet was
	received by the Session-Sender. Timestamp tuples (t1,t2), (t3,t4)		received by the Session-Sender. Timestamp tuples (t1,t2), (t3,t4)
	skipping to change at page 6, line 47 ¶		skipping to change at page 6, line 44 ¶
	====== ====== ====== ====== ======		====== ====== ====== ====== ======
	| | T1--->t1 | | t2--->t3 | | t4--->t5 | | t6--->T2| |		| | T1--->t1 | | t2--->t3 | | t4--->t5 | | t6--->T2| |
	| N1 |==========| N2 |==========| N3 |==========| N4 |=========| N5 |		| N1 |==========| N2 |==========| N3 |==========| N4 |=========| N5 |
	| | T4<---t12| |t11<---t10| | t9<---t8 | | t7<---T3| |		| | T4<---t12| |t11<---t10| | t9<---t8 | | t7<---T3| |
	====== ====== ====== ====== ======		====== ====== ====== ====== ======
	Fig. 3 Reference Topology		Fig. 3 Reference Topology
	The STAMP Session-Sender (i.e. Node N1) generates the STAMP test		The STAMP Session-Sender (i.e. Node N1) generates the STAMP test
	packet with the Forward HbH Delay TLV. When an intermediate node		packet with the Forward HbH Delay TLV. When an intermediate node
	receives the STAMP test packet, the node sends the packet to control		receives the STAMP test packet, the node punts the packet to control
	plane and fills the Ingress Timestamp [n] filed in the Forward HbH		plane and fills the Ingress Timestamp [n] filed in the Timestamp
	Delay TLV. Then the time taken by the intermediate node transmitting		Tuple list [n]. Then the time taken by the intermediate node
	the test packet is recorded in to Engress Timestamp [n] field in the		transmitting the test packet is recorded in to Engress Timestamp [n]
	Forward HbH Delay TLV. The mechanism of timestamping and punting		field. The mechanism of timestamping and punting packet to control
	packet to control plane is outside the scope of this specification.		plane is outside the scope of this specification.
	When the STAMP Session-Reflector received the test packet with the		When the STAMP Session-Reflector received the test packet with the
	Forward HbH Delay TLV, it MUST copy the Forward HbH Delay TLV into		Forward HbH Delay TLV, it MUST copy the Forward HbH Delay TLV into
	the reflected test packet before its transmission. Using Forward HbH		the Session-Reflector test packet before its transmission. Using
	Delay TLV in STAMP testing enables hop-by-hop delay measurement in		Forward HbH Delay TLV in STAMP testing enables delay measurement per
	the forward path.		link in the forward path.
	3.3. Backward HbH Delay TLV		3.3. Backward HbH Delay TLV
	STAMP Session-Sender MAY place the Backward HbH Delay TLV in Session-		STAMP Session-Sender MAY place the Backward HbH Delay TLV in Session-
	Sender test packets to record the ingress timestamp and engress		Sender test packets to record the ingress timestamp and egress
	timestamp when Session-Reflector test packets are received and sent		timestamp when Session-Reflector test packets are received and sent
	at every intermediate nodes in the backward path. The Session-Sender		at every intermediate nodes in the backward path. The Session-Sender
	MUST set the Length value according to the number of intermediate		MUST set the Length value according to the number of explicitly
	nodes in the backward path and the timestamp formats. There are		listed intermediate nodes in the backward path and the timestamp
	several methods to synchronize the clock, e.g., Network Time Protocol		formats. There are several methods to synchronize the clock, e.g.,
	(NTP) [RFC5905]. For example, if a 64-bit timestamp format defined		Network Time Protocol (NTP) [RFC5905]. For example, if a 64-bit
	in NTP is used, the Length value MUST be set as a multiple of 8		timestamp format defined in NTP is used, the Length value MUST be set
	octets. The Timestamp Tuple list (Ingress Timestamp [0..n], Engress		as a multiple of 8 octets. The Timestamp Tuple list [1..n] fields
	Timestamp [0..n]) fields MUST be set to zero upon Session-Sender test		MUST be set to zero upon Session-Sender test packets transmission and
	packets transmission and ignored upon receipt.		ignored upon receipt.
	The Backward HbH Delay TLV has the following format:		The Backward HbH Delay TLV has the following format:
	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
	+-------------------------------+---------------+---------------+		+-------------------------------+---------------+---------------+
	| Backward HbH Delay Type | Length | Node Left |		| Backward HbH Delay Type | Length | Node Left |
	+-------------------------------+---------------+---------------+		+-------------------------------+---------------+---------------+
	| Ingress Timestamp [0] |
	| |		| |
	+---------------------------------------------------------------+		| Timestamp Tuple list [1] |
	| Engress Timestamp [0] |		| |
	| |		| |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	~ ... ~		~ ... ~
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	| Ingress Timestamp [n] |
	| |		| |
	+---------------------------------------------------------------+		| Timestamp Tuple list [n] |
	| Engress Timestamp [n] |		| |
	| |		| |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Fig. 4 Backward HbH Delay TLV Format		Fig. 4 Backward HbH Delay TLV Format
	where fields are defined as the following:		where fields are defined as the following:
	Backward HbH Delay Type: To be assigned by IANA.		o Backward HbH Delay Type: To be assigned by IANA.
	Length: A 8-bit field that indicates the length of the value portion		o Length: A 8-bit field that indicates the length of the value
	in octets and will be a multiple of 8 octets dependent on the number		portion in octets and will be a multiple of 8 octets dependent on
	of nodes in a path.		the number of explicitly listed intermediate nodes in the backward
			path.
	Node Left: A 8-bit unsigned integer, which indicates the number of		o Node Left: A 8-bit unsigned integer, which indicates the number of
	intermediate nodes remaining. That is, number of exlicitly listed		intermediate nodes remaining. That is, number of exlicitly listed
	intermediate nodes still to be visited before reaching the		intermediate nodes still to be visited before reaching the
	destination node in the backward path. The Node Left field is set to		destination node in the backward path. The Node Left field is set
	n-1, where n is the number of intermediate nodes.		to n-1, where n is the number of intermediate nodes.
	Timestamp Tuple list (Ingress Timestamp [0..n], Engress Timestamp		o Timestamp Tuple list [1..n]: A variable-length field, which record
	[0..n]): A variable-length field, which record the timestamp when the		the timestamp when the reflected test packet is received at the
	reflected test packet is received at the ingress of the n-th		ingress of the n-th intermediate node and the timestamp when the
	intermediate node and the timestamp when the reflected test packet is		reflected test packet is sent at egress of the n-th intermediate
	sent at engress of the n-th intermediate node. For example, if a		node. For example, if a 64-bit timestamp format defined in NTP is
	64-bit timestamp format defined in NTP is used, the length of each		used, the length of each Timestamp tuple (Ingress Timestamp [n],
	Timestamp tuple (Ingress Timestamp [n], Engress Timestamp [n]) must		Engress Timestamp [n]) must be 16 octets. The Timestamp Tuple
	be 16 octets. The Timestamp Tuple list is encoded starting from the		list is encoded starting from the last intermediate node which is
	last intermediate node which is exlicitly listed. That is, the first		exlicitly listed. That is, the first element of the Timestamp
	element of the Timestamp Tuple (Ingress Timestamp [0], Engress		Tuple list [1] records the timestamps when the reflected test
	Timestamp [0]) records the timestamps when the reflected test packet		packet received and forwarded at the last intermediate node of a
	received and forwarded at the last intermediate node of a explicit		explicit path, the second element records the penultimate
	path, the second element records the penultimate Timestamp Tuple when		Timestamp Tuple when the reflected test packet received and
	the reflected test packet received and forwarded at the penultimate		forwarded at the penultimate intermediate node of a explicit path,
	intermediate node of a explicit path, and so on.		and so on.
	When the STAMP Session-Reflector received the Session-Sender test		When the STAMP Session-Reflector received the Session-Sender test
	packet with the Backward HbH Delay TLV, it MUST copy the Backward HbH		packet with the Backward HbH Delay TLV, it MUST copy the Backward HbH
	Delay TLV into the reflected test packet.		Delay TLV into the Session-Reflector test packet.
	When an intermediate node receives the reflected test packet, the		When an intermediate node receives the reflected test packet, the
	node sends the packet to control plane and fills the Ingress		node sends the packet to control plane and fills the Ingress
	Timestamp [n] filed of Backward HbH Delay TLV. Then the time taken		Timestamp [n] filed of Backward HbH Delay TLV. Then the time taken
	by the intermediate node transmitting the test packet is recorded in		by the intermediate node transmitting the test packet is recorded in
	to Engress Timestamp [n] field of Backward HbH Delay TLV. Using		to Engress Timestamp [n] field of Backward HbH Delay TLV. Using
	Backward HbH Delay TLV in STAMP testing enables hop-by-hop delay		Backward HbH Delay TLV in STAMP testing enables delay measurement per
	measurement in the backward path.		link in the backward path.
	4. IANA Considerations		4. IANA Considerations
	IANA is requested to allocate values for the following TLV Type from		IANA is requested to allocate values for the following TLV Type from
	the "STAMP TLV Type" registry [I-D.ietf-ippm-stamp-option-tlv].		the "STAMP TLV Type" registry [I-D.ietf-ippm-stamp-option-tlv].
	+------------+------------------------+---------------+		+------------+------------------------+---------------+
	| Code Point | Description | Reference |		| Code Point | Description | Reference |
	+------------+------------------------+---------------+		+------------+------------------------+---------------+
	| TBA1 | IOAM Tracing Data TLV | This document |		| TBA1 | IOAM Tracing Data TLV | This document |
	| TBA2 | Forward HBH Delay TLV | This document |		| TBA2 | Forward HBH Delay TLV | This document |
	| TBA3 | Backward HBH Delay TLV | This document |		| TBA3 | Backward HBH Delay TLV | This document |
	+------------+------------------------+---------------+		+------------+------------------------+---------------+
	5. Security Considerations		5. Security Considerations
	This document introduces new TLV extensions to STAMP. It does not		This document extensions new optional TLVs to STAMP. It does not
	introduce any new security risks to STAMP.		introduce any new security risks to STAMP.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[I-D.ietf-ippm-ioam-data]		[I-D.ietf-ippm-ioam-data]
	"Data Fields for In-situ OAM",		"Data Fields for In-situ OAM",
	<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-		<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-
	data/>.		data/>.
End of changes. 38 change blocks.
	156 lines changed or deleted		156 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/