< draft-ietf-6man-ipv6-alt-mark-01.txt		draft-ietf-6man-ipv6-alt-mark-02.txt >
	6MAN Working Group G. Fioccola		6MAN Working Group G. Fioccola
	Internet-Draft T. Zhou		Internet-Draft T. Zhou
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: December 24, 2020 M. Cociglio		Expires: April 16, 2021 M. Cociglio
	Telecom Italia		Telecom Italia
	F. Qin		F. Qin
	China Mobile		China Mobile
	R. Pang		R. Pang
	China Unicom		China Unicom
	June 22, 2020		October 13, 2020
	IPv6 Application of the Alternate Marking Method		IPv6 Application of the Alternate Marking Method
	draft-ietf-6man-ipv6-alt-mark-01		draft-ietf-6man-ipv6-alt-mark-02
	Abstract		Abstract
	This document describes how the Alternate Marking Method can be used		This document describes how the Alternate Marking Method can be used
	as the passive performance measurement tool in an IPv6 domain and		as the passive performance measurement tool in an IPv6 domain and
	reports implementation considerations. It proposes how to define a		reports implementation considerations. It proposes how to define a
	new Extension Header Option to encode alternate marking technique and		new Extension Header Option to encode alternate marking technique and
	both Hop-by-Hop Options Header and Destination Options Header are		both Hop-by-Hop Options Header and Destination Options Header are
	considered.		considered.
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 49 ¶
	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 December 24, 2020.		This Internet-Draft will expire on April 16, 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 30 ¶		skipping to change at page 2, line 30 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Alternate Marking application to IPv6 . . . . . . . . . . . . 3		2. Alternate Marking application to IPv6 . . . . . . . . . . . . 3
	3. Definition of the AltMark Option . . . . . . . . . . . . . . 4		3. Definition of the AltMark Option . . . . . . . . . . . . . . 4
	3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 4		3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 4
	4. Use of the AltMark Option . . . . . . . . . . . . . . . . . . 5		4. Use of the AltMark Option . . . . . . . . . . . . . . . . . . 5
	5. Alternate Marking Method Operation . . . . . . . . . . . . . 7		5. Alternate Marking Method Operation . . . . . . . . . . . . . 7
	5.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 7		5.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 7
	5.2. Packet Delay Measurement . . . . . . . . . . . . . . . . 8		5.2. Packet Delay Measurement . . . . . . . . . . . . . . . . 8
	5.3. Flow Monitoring Identification . . . . . . . . . . . . . 9		5.3. Flow Monitoring Identification . . . . . . . . . . . . . 10
	5.3.1. Uniqueness of FlowMonID . . . . . . . . . . . . . . . 10		5.3.1. Uniqueness of FlowMonID . . . . . . . . . . . . . . . 10
	5.4. Multipoint and Clustered Alternate Marking . . . . . . . 10		5.4. Multipoint and Clustered Alternate Marking . . . . . . . 11
	5.5. Data Collection and Calculation . . . . . . . . . . . . . 11		5.5. Data Collection and Calculation . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . 13		9.1. Normative References . . . . . . . . . . . . . . . . . . 13
	9.2. Informative References . . . . . . . . . . . . . . . . . 13		9.2. Informative References . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	[RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] describe a passive		[RFC8321] and [RFC8889] describe a passive performance measurement
	performance measurement method, which can be used to measure packet		method, which can be used to measure packet loss, latency and jitter
	loss, latency and jitter on live traffic. Since this method is based		on live traffic. Since this method is based on marking consecutive
	on marking consecutive batches of packets, the method is often		batches of packets, the method is often referred as Alternate Marking
	referred as Alternate Marking Method.		Method.
	The Alternate Marking Method has become mature to be implemented and		The Alternate Marking Method has become mature to be implemented and
	encoded in the IPv6 protocol and this document defines how it can be		encoded in the IPv6 protocol and this document defines how it can be
	used to measure packet loss and delay metrics in IPv6.		used to measure packet loss and delay metrics in IPv6.
	The format of the IPv6 addresses is defined in [RFC4291] while		The format of the IPv6 addresses is defined in [RFC4291] while
	[RFC8200] defines the IPv6 Header, including a 20-bit Flow Label and		[RFC8200] defines the IPv6 Header, including a 20-bit Flow Label and
	the IPv6 Extension Headers. The Segment Routing Header (SRH) is		the IPv6 Extension Headers. The Segment Routing Header (SRH) is
	defined in [RFC8754].		defined in [RFC8754] to apply Segment Routing over IPv6 dataplane
			(SRv6).
	[I-D.fioccola-v6ops-ipv6-alt-mark] reported a summary on the possible		[I-D.fioccola-v6ops-ipv6-alt-mark] reported a summary on the possible
	implementation options for the application of the Alternate Marking		implementation options for the application of the Alternate Marking
	Method in an IPv6 domain. This document, starting from the outcome		Method in an IPv6 domain. This document, starting from the outcome
	of [I-D.fioccola-v6ops-ipv6-alt-mark], introduces a new TLV that can		of [I-D.fioccola-v6ops-ipv6-alt-mark], introduces a new TLV that can
	be encoded in the Options Headers (both Hop-by-Hop or Destination)		be encoded in the Options Headers (both Hop-by-Hop or Destination)
	for the purpose of the Alternate Marking Method application in an		for the purpose of the Alternate Marking Method application in an
	IPv6 domain. The case of SRH ([RFC8754]) is also discussed, anyway		IPv6 domain. The case of SRH ([RFC8754]) is also discussed, anyway
	this is valid for all the types of Routing Header (RH).		this is valid for all the types of Routing Header (RH).
	skipping to change at page 6, line 35 ¶		skipping to change at page 6, line 35 ¶
	advantage of the property of how Hop-by-Hop options are processed.		advantage of the property of how Hop-by-Hop options are processed.
	Nodes that do not support this Option SHOULD ignore them. This can		Nodes that do not support this Option SHOULD ignore them. This can
	mean that, in this case, the performance measurement does not account		mean that, in this case, the performance measurement does not account
	for all links and nodes along a path.		for all links and nodes along a path.
	Another application that can be mentioned is the presence of a		Another application that can be mentioned is the presence of a
	Routing Header, in particular it is possible to consider SRv6. SRv6		Routing Header, in particular it is possible to consider SRv6. SRv6
	leverages the Segment Routing header which consists of a new type of		leverages the Segment Routing header which consists of a new type of
	routing header. Like any other use case of IPv6, Hop-by-Hop and		routing header. Like any other use case of IPv6, Hop-by-Hop and
	Destination Options are useable when SRv6 header is present. Because		Destination Options are useable when SRv6 header is present. Because
	SRv6 is a routing header, Destination Options before the routing		SRv6 is implemented through a Segment Routing Header (SRH),
	header are processed by each destination in the route list.		Destination Options before the Routing Header are processed by each
			destination in the route list, that means, in case of SRH, by every
			node that is an identity in the SR path.
	In summary, it is possible to list the alternative possibilities:		In summary, it is possible to list the alternative possibilities:
	o Destination Option => measurement only by node in Destination		o Destination Option => measurement only by node in Destination
	Address.		Address.
	o Hop-by-Hop Option => every router on the path with feature		o Hop-by-Hop Option => every router on the path with feature
	enabled.		enabled.
	o Destination Option + SRH => every node that is an identity in the		o Destination Option + any Routing Header => every destination node
	SR path.		in the route list.
	In general, Hop-by-Hop and Destination Options are the most suitable		In general, Hop-by-Hop and Destination Options are the most suitable
	ways to implement Alternate Marking.		ways to implement Alternate Marking.
	It is worth mentioning that new Hop-by-Hop Options are not strongly		It is worth mentioning that new Hop-by-Hop Options are not strongly
	recommended in [RFC7045] and [RFC8200], unless there is a clear		recommended in [RFC7045] and [RFC8200], unless there is a clear
	justification to standardize it, because nodes may be configured to		justification to standardize it, because nodes may be configured to
	ignore the Options Header, drop or assign packets containing an		ignore the Options Header, drop or assign packets containing an
	Options Header to a slow processing path. In case of the AltMark		Options Header to a slow processing path. In case of the AltMark
	data fields described in this document, the motivation to standardize		data fields described in this document, the motivation to standardize
	skipping to change at page 7, line 49 ¶		skipping to change at page 7, line 49 ¶
	within a batch are marked by setting the L bit (Loss flag) to a same		within a batch are marked by setting the L bit (Loss flag) to a same
	value. The source node can switch the value of the L bit between 0		value. The source node can switch the value of the L bit between 0
	and 1 after a fixed number of packets or according to a fixed timer,		and 1 after a fixed number of packets or according to a fixed timer,
	and this depends on the implementation. By counting the number of		and this depends on the implementation. By counting the number of
	packets in each batch and comparing the values measured by different		packets in each batch and comparing the values measured by different
	network nodes along the path, it is possible to measure the packet		network nodes along the path, it is possible to measure the packet
	loss occurred in any single batch between any two nodes. Each batch		loss occurred in any single batch between any two nodes. Each batch
	represents a measurable entity unambiguously recognizable by all		represents a measurable entity unambiguously recognizable by all
	network nodes along the path.		network nodes along the path.
	It is important to mention that for the application of this method		Packets with different L values may get swapped at batch boundaries,
	there are two elements to consider: the clock error between network		and in this case, it is required that each marked packet can be
	nodes and the network delay. These can create offsets between the		assigned to the right batch by each router. It is important to
	batches and out-of-order of the packets. The consequence is that it		mention that for the application of this method there are two
	is necessary to define a waiting interval where to get stable		elements to consider: the clock error between network nodes and the
	counters and to avoid these issues. In addition this implies that		network delay. These can create offsets between the batches and out-
	the length of the batches MUST be chosen large enough so that it is		of-order of the packets. There is the condition on timing aspects
	not affected by those factors.		explained in [RFC8321] that must be satisfied and it takes into
			considerations the different causes of reordering such as clock
			error, network delay. The consequence is that it is necessary to
			define a waiting interval where to get stable counters and to avoid
			these issues. Usually the counters can be taken in the middle of the
			batch period to be sure to take still counters. In a few words this
			implies that the length of the batches MUST be chosen large enough so
			that the method is not affected by those factors.
	L bit=1 ----------+ +-----------+ +----------		L bit=1 ----------+ +-----------+ +----------
	| | | |		| | | |
	L bit=0 +-----------+ +-----------+		L bit=0 +-----------+ +-----------+
	Batch n ... Batch 3 Batch 2 Batch 1		Batch n ... Batch 3 Batch 2 Batch 1
	<---------> <---------> <---------> <---------> <--------->		<---------> <---------> <---------> <---------> <--------->
	Traffic Flow		Traffic Flow
	===========================================================>		===========================================================>
	L bit ...1111111111 0000000000 11111111111 00000000000 111111111...		L bit ...1111111111 0000000000 11111111111 00000000000 111111111...
	skipping to change at page 10, line 51 ¶		skipping to change at page 11, line 10 ¶
	additional flow information to allow disambiguation. While, in case		additional flow information to allow disambiguation. While, in case
	of a centralized controller, the controller should set FlowMonID by		of a centralized controller, the controller should set FlowMonID by
	considering these aspects and instruct the nodes properly in order to		considering these aspects and instruct the nodes properly in order to
	guarantee its uniqueness.		guarantee its uniqueness.
	5.4. Multipoint and Clustered Alternate Marking		5.4. Multipoint and Clustered Alternate Marking
	The Alternate Marking method can also be extended to any kind of		The Alternate Marking method can also be extended to any kind of
	multipoint to multipoint paths, and the network clustering approach		multipoint to multipoint paths, and the network clustering approach
	allows a flexible and optimized performance measurement, as described		allows a flexible and optimized performance measurement, as described
	in [I-D.ietf-ippm-multipoint-alt-mark].		in [RFC8889].
	The Cluster is the smallest identifiable subnetwork of the entire		The Cluster is the smallest identifiable subnetwork of the entire
	Network graph that still satisfies the condition that the number of		Network graph that still satisfies the condition that the number of
	packets that goes in is the same that goes out. With network		packets that goes in is the same that goes out. With network
	clustering, it is possible to use the partition of the network into		clustering, it is possible to use the partition of the network into
	clusters at different levels in order to perform the needed degree of		clusters at different levels in order to perform the needed degree of
	detail. So, for Multipoint Alternate Marking, FlowMonID can identify		detail. So, for Multipoint Alternate Marking, FlowMonID can identify
	in general a multipoint-to-multipoint flow and not only a point-to-		in general a multipoint-to-multipoint flow and not only a point-to-
	point flow.		point flow.
	skipping to change at page 11, line 32 ¶		skipping to change at page 11, line 39 ¶
	This document aims to apply a method to perform measurements that		This document aims to apply a method to perform measurements that
	does not directly affect Internet security nor applications that run		does not directly affect Internet security nor applications that run
	on the Internet. However, implementation of this method must be		on the Internet. However, implementation of this method must be
	mindful of security and privacy concerns.		mindful of security and privacy concerns.
	There are two types of security concerns: potential harm caused by		There are two types of security concerns: potential harm caused by
	the measurements and potential harm to the measurements.		the measurements and potential harm to the measurements.
	Harm caused by the measurement: Alternate Marking implies		Harm caused by the measurement: Alternate Marking implies
	modifications on the fly to an Option Header of IPv6 packets but this		modifications on the fly to an Option Header of IPv6 packets by the
	must be performed in a way that does not alter the quality of service		source node but this must be performed in a way that does not alter
	experienced by the packets and that preserves stability and		the quality of service experienced by the packets and that preserves
	performance of routers doing the measurements. The advantage of the		stability and performance of routers doing the measurements. The
	Alternate Marking method is that the marking bits are the only		advantage of the Alternate Marking method is that the marking bits
	information that is exchanged between the network nodes. Therefore,		are the only information that is exchanged between the network nodes.
	network reconnaissance through passive eavesdropping on data-plane		Therefore, network reconnaissance through passive eavesdropping on
	traffic does not allow attackers to gain information about the		data-plane traffic does not allow attackers to gain information about
	network performance. Moreover, Alternate Marking should usually be		the network performance. Moreover, Alternate Marking should usually
	applied in a controlled domain and this also helps to limit the		be applied in a controlled domain and this also helps to limit the
	problem.		problem.
	Harm to the Measurement: Alternate Marking measurements could be		Harm to the Measurement: Alternate Marking measurements could be
	harmed by routers altering the marking of the packets or by an		harmed by routers altering the marking of the packets or by an
	attacker injecting artificial traffic. Since the measurement itself		attacker injecting artificial traffic. Since the measurement itself
	may be affected by network nodes along the path intentionally		may be affected by network nodes along the path intentionally
	altering the value of the marking bits of IPv6 packets, the Alternate		altering the value of the marking bits of IPv6 packets, the Alternate
	Marking should be applied in the context of a controlled domain,		Marking should be applied in the context of a controlled domain,
	where the network nodes are locally administered and this type of		where the network nodes are locally administered and this type of
	attack can be avoided. Indeed the source and destination addresses		attack can be avoided. Indeed the source and destination addresses
	skipping to change at page 13, line 28 ¶		skipping to change at page 13, line 37 ¶
	<https://www.rfc-editor.org/info/rfc8200>.		<https://www.rfc-editor.org/info/rfc8200>.
	9.2. Informative References		9.2. Informative References
	[I-D.fioccola-v6ops-ipv6-alt-mark]		[I-D.fioccola-v6ops-ipv6-alt-mark]
	Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6		Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6
	Performance Measurement with Alternate Marking Method",		Performance Measurement with Alternate Marking Method",
	draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress),		draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress),
	June 2018.		June 2018.
	[I-D.ietf-ippm-multipoint-alt-mark]
	Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto,
	"Multipoint Alternate Marking method for passive and
	hybrid performance monitoring", draft-ietf-ippm-
	multipoint-alt-mark-09 (work in progress), March 2020.
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, DOI 10.17487/RFC4291, February		Architecture", RFC 4291, DOI 10.17487/RFC4291, February
	2006, <https://www.rfc-editor.org/info/rfc4291>.		2006, <https://www.rfc-editor.org/info/rfc4291>.
	[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,		[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
	"IPv6 Flow Label Specification", RFC 6437,		"IPv6 Flow Label Specification", RFC 6437,
	DOI 10.17487/RFC6437, November 2011,		DOI 10.17487/RFC6437, November 2011,
	<https://www.rfc-editor.org/info/rfc6437>.		<https://www.rfc-editor.org/info/rfc6437>.
	[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing		[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
	skipping to change at page 14, line 16 ¶		skipping to change at page 14, line 20 ¶
	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>.
	[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,		[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
	Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header		Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
	(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,		(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
	<https://www.rfc-editor.org/info/rfc8754>.		<https://www.rfc-editor.org/info/rfc8754>.
			[RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto,
			"Multipoint Alternate-Marking Method for Passive and
			Hybrid Performance Monitoring", RFC 8889,
			DOI 10.17487/RFC8889, August 2020,
			<https://www.rfc-editor.org/info/rfc8889>.
	Authors' Addresses		Authors' Addresses
	Giuseppe Fioccola		Giuseppe Fioccola
	Huawei		Huawei
	Riesstrasse, 25		Riesstrasse, 25
	Munich 80992		Munich 80992
	Germany		Germany
	Email: giuseppe.fioccola@huawei.com		Email: giuseppe.fioccola@huawei.com
End of changes. 16 change blocks.
	43 lines changed or deleted		53 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/