< draft-ietf-ippm-stamp-09.txt		draft-ietf-ippm-stamp-10.txt >
	Network Working Group G. Mirsky		Network Working Group G. Mirsky
	Internet-Draft ZTE Corp.		Internet-Draft ZTE Corp.
	Intended status: Standards Track G. Jun		Intended status: Standards Track G. Jun
	Expires: April 20, 2020 ZTE Corporation		Expires: April 30, 2020 ZTE Corporation
	H. Nydell		H. Nydell
	Accedian Networks		Accedian Networks
	R. Foote		R. Foote
	Nokia		Nokia
	October 18, 2019		October 28, 2019
	Simple Two-way Active Measurement Protocol		Simple Two-way Active Measurement Protocol
	draft-ietf-ippm-stamp-09		draft-ietf-ippm-stamp-10
	Abstract		Abstract
	This document describes a Simple Two-way Active Measurement Protocol		This document describes a Simple Two-way Active Measurement Protocol
	which enables the measurement of both one-way and round-trip		which enables the measurement of both one-way and round-trip
	performance metrics like delay, delay variation, and packet loss.		performance metrics like delay, delay variation, and packet loss.
	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 37 ¶		skipping to change at page 1, line 37 ¶
	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 April 20, 2020.		This Internet-Draft will expire on April 30, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 5, line 37 ¶		skipping to change at page 5, line 37 ¶
	Reflector that supports this specification MUST be able to define the		Reflector that supports this specification MUST be able to define the
	port number to receive STAMP test packets from User Ports and Dynamic		port number to receive STAMP test packets from User Ports and Dynamic
	Ports ranges that are defined in [RFC6335]. STAMP defines two		Ports ranges that are defined in [RFC6335]. STAMP defines two
	different test packet formats, one for packets transmitted by the		different test packet formats, one for packets transmitted by the
	STAMP-Session-Sender and one for packets transmitted by the STAMP-		STAMP-Session-Sender and one for packets transmitted by the STAMP-
	Session-Reflector.		Session-Reflector.
	4.2. Session-Sender Behavior and Packet Format		4.2. Session-Sender Behavior and Packet Format
	A STAMP Session-Reflector supports the symmetrical size of test		A STAMP Session-Reflector supports the symmetrical size of test
	packets [RFC6038] as the default behavior. A reflected test packet		packets, as defined in Section 3 [RFC6038], as the default behavior.
	includes more information and thus is larger. Because of that, the		A reflected test packet includes more information and thus is larger.
	base STAMP Session-Sender packet is padded to match the size of a		Because of that, the base STAMP Session-Sender packet is padded to
	reflected STAMP test packet. Hence, the base STAMP Session-Sender		match the size of a reflected STAMP test packet. Hence, the base
	packet has a minimum size of 44 octets in unauthenticated mode, see		STAMP Session-Sender packet has a minimum size of 44 octets in
	Figure 2, and 112 octets in the authenticated mode, see Figure 4.		unauthenticated mode, see Figure 2, and 112 octets in the
	The variable length of a test packet in STAMP is supported by using		authenticated mode, see Figure 4. The variable length of a test
	Extra Padding TLV defined in [I-D.ietf-ippm-stamp-option-tlv].		packet in STAMP is supported by using Extra Padding TLV defined in
			[I-D.ietf-ippm-stamp-option-tlv].
	4.2.1. Session-Sender Packet Format in Unauthenticated Mode		4.2.1. Session-Sender Packet Format in Unauthenticated Mode
	STAMP Session-Sender packet format in unauthenticated mode:		STAMP Session-Sender packet format in unauthenticated mode:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number |		| Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 12, line 50 ¶		skipping to change at page 12, line 50 ¶
	Sender to use alternative ports. If any of STAMP extensions are		Sender to use alternative ports. If any of STAMP extensions are
	used, the TWAMP Light Session-Reflector will view them as Packet		used, the TWAMP Light Session-Reflector will view them as Packet
	Padding field.		Padding field.
	In the latter scenario, if a TWAMP Light Session-Sender does not		In the latter scenario, if a TWAMP Light Session-Sender does not
	support the use of UDP port 862, the test management system MUST set		support the use of UDP port 862, the test management system MUST set
	STAMP Session-Reflector to use UDP port number, as permitted by		STAMP Session-Reflector to use UDP port number, as permitted by
	Section 4. The Session-Reflector MUST be set to use the default		Section 4. The Session-Reflector MUST be set to use the default
	format for its timestamps, NTP.		format for its timestamps, NTP.
	A STAMP Session-Reflector that supports this specification would		A STAMP Session-Reflector that supports this specification will
	transmit the base packet (Figure 5) regardless of the size of the		transmit the base packet (Figure 5) if it receives a packet smaller
	Padding field in the packet received from TWAMP Session-Sender.		than the STAMP base packet. If the packet received from TWAMP
	Also, STAMP does not support the Reflect Octets capability defined in		Session-Sender is larger than the STAMP base packet, the STAMP
	[RFC6038]. If the Server Octets field is present in the TWAMP		Session-Reflector that supports this specification will copy the
	Session-Sender packet, STAMP Session-Reflector will not copy the		content of the remainder of the received packet to transmit reflected
	content starting from the Server Octets field and will transmit the		packet of symmetrical size.
	reflected packet, as displayed in Figure 5.
	5. Operational Considerations		5. Operational Considerations
	STAMP is intended to be used on production networks to enable the		STAMP is intended to be used on production networks to enable the
	operator to assess service level agreements based on packet delay,		operator to assess service level agreements based on packet delay,
	delay variation, and loss. When using STAMP over the Internet,		delay variation, and loss. When using STAMP over the Internet,
	especially when STAMP test packets are transmitted with the		especially when STAMP test packets are transmitted with the
	destination UDP port number from the User Ports range, the possible		destination UDP port number from the User Ports range, the possible
	impact of the STAMP test packets MUST be thoroughly analyzed. The		impact of the STAMP test packets MUST be thoroughly analyzed. The
	use of STAMP for each case MUST be agreed by users of nodes hosting		use of STAMP for each case MUST be agreed by users of nodes hosting
	skipping to change at page 15, line 51 ¶		skipping to change at page 15, line 51 ¶
	9.2. Informative References		9.2. Informative References
	[BBF.TR-390]		[BBF.TR-390]
	"Performance Measurement from IP Edge to Customer		"Performance Measurement from IP Edge to Customer
	Equipment using TWAMP Light", BBF TR-390, May 2017.		Equipment using TWAMP Light", BBF TR-390, May 2017.
	[I-D.ietf-ippm-stamp-yang]		[I-D.ietf-ippm-stamp-yang]
	Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active		Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active
	Measurement Protocol (STAMP) Data Model", draft-ietf-ippm-		Measurement Protocol (STAMP) Data Model", draft-ietf-ippm-
	stamp-yang-04 (work in progress), September 2019.		stamp-yang-05 (work in progress), October 2019.
	[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>.
	[RFC7750] Hedin, J., Mirsky, G., and S. Baillargeon, "Differentiated		[RFC7750] Hedin, J., Mirsky, G., and S. Baillargeon, "Differentiated
	Service Code Point and Explicit Congestion Notification		Service Code Point and Explicit Congestion Notification
	Monitoring in the Two-Way Active Measurement Protocol		Monitoring in the Two-Way Active Measurement Protocol
	(TWAMP)", RFC 7750, DOI 10.17487/RFC7750, February 2016,		(TWAMP)", RFC 7750, DOI 10.17487/RFC7750, February 2016,
End of changes. 7 change blocks.
	21 lines changed or deleted		21 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/