< draft-ietf-6man-ipv6-alt-mark-04.txt		draft-ietf-6man-ipv6-alt-mark-05.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: September 9, 2021 M. Cociglio		Expires: November 26, 2021 M. Cociglio
	Telecom Italia		Telecom Italia
	F. Qin		F. Qin
	China Mobile		China Mobile
	R. Pang		R. Pang
	China Unicom		China Unicom
	March 8, 2021		May 25, 2021
	IPv6 Application of the Alternate Marking Method		IPv6 Application of the Alternate Marking Method
	draft-ietf-6man-ipv6-alt-mark-04		draft-ietf-6man-ipv6-alt-mark-05
	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 a passive performance measurement tool in an IPv6 domain. It		as a passive performance measurement tool in an IPv6 domain. It
	defines a new Extension Header Option to encode alternate marking		defines a new Extension Header Option to encode alternate marking
	information in both the Hop-by-Hop Options Header and Destination		information in both the Hop-by-Hop Options Header and Destination
	Options Header.		Options Header.
	Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in BCP 14 [RFC2119]
	[RFC8174] when, and only when, they appear in all capitals, as shown
	here.
	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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 September 9, 2021.		This Internet-Draft will expire on November 26, 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/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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
			1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
			1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Alternate Marking application to IPv6 . . . . . . . . . . . . 3		2. Alternate Marking application to IPv6 . . . . . . . . . . . . 3
	2.1. Controlled Domain . . . . . . . . . . . . . . . . . . . . 4		2.1. Controlled Domain . . . . . . . . . . . . . . . . . . . . 4
	3. Definition of the AltMark Option . . . . . . . . . . . . . . 5		3. Definition of the AltMark Option . . . . . . . . . . . . . . 5
	3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 5		3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 5
	4. Use of the AltMark Option . . . . . . . . . . . . . . . . . . 6		4. Use of the AltMark Option . . . . . . . . . . . . . . . . . . 6
	5. Alternate Marking Method Operation . . . . . . . . . . . . . 8		5. Alternate Marking Method Operation . . . . . . . . . . . . . 8
	5.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 8		5.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 8
	5.2. Packet Delay Measurement . . . . . . . . . . . . . . . . 9		5.2. Packet Delay Measurement . . . . . . . . . . . . . . . . 9
	5.3. Flow Monitoring Identification . . . . . . . . . . . . . 10		5.3. Flow Monitoring Identification . . . . . . . . . . . . . 10
	5.3.1. Uniqueness of FlowMonID . . . . . . . . . . . . . . . 11		5.3.1. Uniqueness of FlowMonID . . . . . . . . . . . . . . . 11
	skipping to change at page 3, line 19 ¶		skipping to change at page 3, line 15 ¶
	[I-D.fioccola-v6ops-ipv6-alt-mark] summarizes the possible		[I-D.fioccola-v6ops-ipv6-alt-mark] summarizes 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 (Hop-by-Hop or Destination) for the		be encoded in the Options Headers (Hop-by-Hop or Destination) for the
	purpose of the Alternate Marking Method application in an IPv6		purpose of the Alternate Marking Method application in an IPv6
	domain. While the case of Segment Routing Header (SRH), defined in		domain. While the case of Segment Routing Header (SRH), defined in
	[RFC8754], is also discussed, it is valid for all the types of		[RFC8754], is also discussed, it is valid for all the types of
	Routing Header (RH).		Routing Header (RH).
			1.1. Terminology
			This document uses the terms related to the the Alternate Marking
			Method as defined in [RFC8321] and [RFC8889].
			1.2. Requirements Language
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
			"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	2. Alternate Marking application to IPv6		2. Alternate Marking application to IPv6
	The Alternate Marking Method requires a marking field. As mentioned,		The Alternate Marking Method requires a marking field. As mentioned,
	several alternatives have been analysed in		several alternatives have been analysed in
	[I-D.fioccola-v6ops-ipv6-alt-mark] such as IPv6 Extension Headers,		[I-D.fioccola-v6ops-ipv6-alt-mark] such as IPv6 Extension Headers,
	IPv6 Address and Flow Label.		IPv6 Address and Flow Label.
	Consequently, a robust choice is to standardize a new Hop-by-Hop or		Consequently, a robust choice is to standardize a new Hop-by-Hop or
	Destination Option.		Destination Option.
	skipping to change at page 7, line 33 ¶		skipping to change at page 7, line 38 ¶
	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
	a new Hop-by-Hop Option is that it is needed for OAM. An		a new Hop-by-Hop Option is that it is needed for OAM. An
	intermediate node can read it or not but this does not affect the		intermediate node can read it or not but this does not affect the
	packet behavior. The source node is the only one that writes the		packet behavior. The source node is the only one that writes the
	Hop-by-Hop Option to mark alternately the flow, so, the performance		Hop-by-Hop Option to mark alternately the flow, so, the performance
	measurement can be done for those nodes configured to read this		measurement can be done for those nodes configured to read this
	Option, while the others are simply not considered for the metrics.		Option, while the others are simply not considered for the metrics.
	It is important to highlight that the definition of the Hop-by-Hop		It is important to highlight that the definition of the Hop-by-Hop
	Options in this document SHOULD not affect the throughput on nodes		Options in this document SHOULD NOT affect the throughput on nodes
	that do not recognize the Option. Indeed, the three high-order bits		that do not recognize the Option. Indeed, the three high-order bits
	of the Options Header defined in this draft are 000 and, in theory,		of the Options Header defined in this draft are 000 and, in theory,
	as per [RFC8200] and [I-D.hinden-6man-hbh-processing], this means		as per [RFC8200] and [I-D.hinden-6man-hbh-processing], this means
	"skip if do not recognize and data do not change en route".		"skip if do not recognize and data do not change en route".
	[RFC8200] also mentions that the nodes only examine and process the		[RFC8200] also mentions that the nodes only examine and process the
	Hop-by-Hop Options header if explicitly configured to do so. For		Hop-by-Hop Options header if explicitly configured to do so. For
	these reasons, this HbH Option should not affect the throughput.		these reasons, this HbH Option should not affect the throughput.
	Anyway, in practice, it is important to be aware for the		Anyway, in practice, it is important to be aware for the
	implementation that the things may be different and it can happen		implementation that the things may be different and it can happen
	that packets with Hop-by-Hop are forced onto the slow path, but this		that packets with Hop-by-Hop are forced onto the slow path, but this
	skipping to change at page 14, line 37 ¶		skipping to change at page 14, line 37 ¶
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,		(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017,		DOI 10.17487/RFC8200, July 2017,
	<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. V. D., Cociglio, M., and P. Muley,
	Performance Measurement with Alternate Marking Method",		"IPv6 Performance Measurement with Alternate Marking
	draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress),		Method", draft-fioccola-v6ops-ipv6-alt-mark-01 (work in
	June 2018.		progress), June 2018.
	[I-D.hinden-6man-hbh-processing]		[I-D.hinden-6man-hbh-processing]
	Hinden, R. and G. Fairhurst, "IPv6 Hop-by-Hop Options		Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
	Processing Procedures", draft-hinden-6man-hbh-		Processing Procedures", draft-hinden-6man-hbh-
	processing-00 (work in progress), December 2020.		processing-00 (work in progress), December 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,
End of changes. 10 change blocks.
	18 lines changed or deleted		25 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/