draft-ietf-ippm-multimetrics-04.txt		draft-ietf-ippm-multimetrics-05.txt
	Network Working Group E. Stephan		Network Working Group E. Stephan
	Internet-Draft France Telecom		Internet-Draft France Telecom
	Intended status: Informational L. Liang		Intended status: Informational L. Liang
	Expires: January 7, 2008 University of Surrey		Expires: May 21, 2008 University of Surrey
	A. Morton		A. Morton
	AT&T Labs		AT&T Labs
	July 6, 2007		November 18, 2007
	IP Performance Metrics (IPPM) for spatial and multicast		IP Performance Metrics (IPPM) for spatial and multicast
	draft-ietf-ippm-multimetrics-04		draft-ietf-ippm-multimetrics-05
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 37		skipping to change at page 1, line 37
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 7, 2008.		This Internet-Draft will expire on May 21, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The IETF IP Performance Metrics (IPPM) working group has standardized		The IETF IP Performance Metrics (IPPM) working group has standardized
	metrics for measuring end-to-end performance between 2 points. This		metrics for measuring end-to-end performance between two points.
	memo defines 2 sets of metrics to extend these end-to-end ones. It		This memo defines two new categories of metrics that extend the
	defines spatial metrics for measuring the performance of segments		coverage to multiple measurement points. It defines spatial metrics
	along a path and metrics for measuring the performance of a group of		for measuring the performance of segments of a source to destination
	users in multiparty communications.		path, and metrics for measuring the performance between a source and
			many destinations in multiparty communications (e.g., a multicast
			tree).
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. Path Digest Hosts . . . . . . . . . . . . . . . . . . . . 6		2.1. Path Digest Hosts . . . . . . . . . . . . . . . . . . . . 6
	2.2. Multiparty metric . . . . . . . . . . . . . . . . . . . . 6		2.2. Multiparty metric . . . . . . . . . . . . . . . . . . . . 6
	2.3. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 6		2.3. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 6
	2.4. One-to-group metric . . . . . . . . . . . . . . . . . . . 6		2.4. One-to-group metric . . . . . . . . . . . . . . . . . . . 6
	2.5. Points of interest . . . . . . . . . . . . . . . . . . . . 6		2.5. Points of interest . . . . . . . . . . . . . . . . . . . . 6
	2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 8		2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 8
	2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 8		2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 8		2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9		3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.1. Motivations for spatial metrics . . . . . . . . . . . . . 9		3.1. Motivations for spatial metrics . . . . . . . . . . . . . 9
	3.2. Motivations for One-to-group metrics . . . . . . . . . . . 10		3.2. Motivations for One-to-group metrics . . . . . . . . . . . 10
	3.3. Discussion on Group-to-one and Group-to-group metrics . . 11		3.3. Discussion on Group-to-one and Group-to-group metrics . . 11
	4. Spatial vectors metrics definitions . . . . . . . . . . . . . 11		4. Spatial vectors metrics definitions . . . . . . . . . . . . . 11
	4.1. A Definition for Spatial One-way Delay Vector . . . . . . 12		4.1. A Definition for Spatial One-way Delay Vector . . . . . . 12
	4.2. A Definition for Spatial One-way Packet Loss Vector . . . 13		4.2. A Definition for Spatial One-way Packet Loss Vector . . . 13
	4.3. A Definition for Spatial One-way Ipdv Vector . . . . . . . 15		4.3. A Definition for Spatial One-way Ipdv Vector . . . . . . . 15
	4.4. Spatial Methodology . . . . . . . . . . . . . . . . . . . 17		4.4. Spatial Methodology . . . . . . . . . . . . . . . . . . . 17
	5. Spatial Segments metrics definitions . . . . . . . . . . . . . 19		5. Spatial Segments metrics definitions . . . . . . . . . . . . . 19
	5.1. A Definition of a sample of One-way Delay of a segment		5.1. A Definition of a sample of One-way Delay of a segment
	of the path . . . . . . . . . . . . . . . . . . . . . . . 19		of the path . . . . . . . . . . . . . . . . . . . . . . . 19
	5.2. A Definition of a sample of Packet Loss of a segment		5.2. A Definition of a sample of Packet Loss of a segment
	of the path . . . . . . . . . . . . . . . . . . . . . . . 21		of the path . . . . . . . . . . . . . . . . . . . . . . . 20
	5.3. A Definition of a sample of One-way Ipdv of a segment		5.3. A Definition of a sample of One-way Ipdv of a segment
	of the path . . . . . . . . . . . . . . . . . . . . . . . 24		of the path . . . . . . . . . . . . . . . . . . . . . . . 23
	5.4. Discussion on Passive Segment Metrics . . . . . . . . . . 24		6. One-to-group metrics definitions . . . . . . . . . . . . . . . 23
	6. One-to-group metrics definitions . . . . . . . . . . . . . . . 27		6.1. A Definition for one-to-group One-way Delay . . . . . . . 23
	6.1. A Definition for one-to-group One-way Delay . . . . . . . 27		6.2. A Definition for one-to-group One-way Packet Loss . . . . 24
	6.2. A Definition for one-to-group One-way Packet Loss . . . . 28		6.3. A Definition for one-to-group One-way Ipdv . . . . . . . . 25
	6.3. A Definition for one-to-group One-way Ipdv . . . . . . . . 28		7. One-to-Group Sample Statistics . . . . . . . . . . . . . . . . 26
	7. One-to-Group Sample Statistics . . . . . . . . . . . . . . . . 30		7.1. Discussion on the Impact of packet loss on statistics . . 29
	7.1. Discussion on the Impact of packet loss on statistics . . 32		7.2. General Metric Parameters . . . . . . . . . . . . . . . . 30
	7.2. General Metric Parameters . . . . . . . . . . . . . . . . 33		7.3. One-to-Group one-way Delay Statistics . . . . . . . . . . 31
	7.3. One-to-Group one-way Delay Statistics . . . . . . . . . . 34		7.4. One-to-Group one-way Loss Statistics . . . . . . . . . . . 33
	7.4. One-to-Group one-way Loss Statistics . . . . . . . . . . . 37		7.5. One-to-Group one-way Delay Variation Statistics . . . . . 35
	7.5. One-to-Group one-way Delay Variation Statistics . . . . . 39		8. Measurement Methods: Scaleability and Reporting . . . . . . . 35
	8. Measurement Methods: Scaleability and Reporting . . . . . . . 39		8.1. Computation methods . . . . . . . . . . . . . . . . . . . 36
	8.1. Computation methods . . . . . . . . . . . . . . . . . . . 40		8.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 37
	8.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 41		8.3. Effect of Time and Space Aggregation Order on Stats . . . 37
	8.3. Effect of Time and Space Aggregation Order on Stats . . . 41		9. Manageability Considerations . . . . . . . . . . . . . . . . . 39
	9. Manageability Considerations . . . . . . . . . . . . . . . . . 43		9.1. Reporting spatial metric . . . . . . . . . . . . . . . . . 39
	9.1. Reporting spatial metric . . . . . . . . . . . . . . . . . 43		9.2. Reporting One-to-group metric . . . . . . . . . . . . . . 40
	9.2. Reporting One-to-group metric . . . . . . . . . . . . . . 44		9.3. Metric identification . . . . . . . . . . . . . . . . . . 41
	9.3. Metric identification . . . . . . . . . . . . . . . . . . 44		9.4. Reporting data model . . . . . . . . . . . . . . . . . . . 41
	9.4. Reporting data model . . . . . . . . . . . . . . . . . . . 44		10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 44
	10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 48		11. Security Considerations . . . . . . . . . . . . . . . . . . . 45
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 48		11.1. Spatial metrics . . . . . . . . . . . . . . . . . . . . . 45
	11.1. Spatial metrics . . . . . . . . . . . . . . . . . . . . . 48		11.2. one-to-group metric . . . . . . . . . . . . . . . . . . . 45
	11.2. one-to-group metric . . . . . . . . . . . . . . . . . . . 48		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49		14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55		14.1. Normative References . . . . . . . . . . . . . . . . . . . 51
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 55		14.2. Informative References . . . . . . . . . . . . . . . . . . 51
	14.2. Informative References . . . . . . . . . . . . . . . . . . 56		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56		Intellectual Property and Copyright Statements . . . . . . . . . . 54
	Intellectual Property and Copyright Statements . . . . . . . . . . 58
	1. Introduction		1. Introduction
	The IPPM WG defined a framework for metric definitions and end-to-end		The IP Performance Metrics (IPPM) WG has defined a framework for
			metric definitions and end-to-end, or source to destination
	measurements:		measurements:
	o A general framework for defining performance metrics, described in		o A general framework for defining performance metrics, described in
	the Framework for IP Performance Metrics [RFC2330];		the Framework for IP Performance Metrics [RFC2330];
	o A One-way Active Measurement Protocol Requirements [RFC3763];		The Working Group has specified a set of end-to-end metrics using the
			framework, and a registry for the metrics:
	o A One-way Active Measurement Protocol (OWAMP) [RFC4656];
	o An IP Performance Metrics Registry [RFC4148];
	It specified a set of end-to-end metrics, which conform to this
	framework:
	o The IPPM Metrics for Measuring Connectivity [RFC2678];		o The IPPM Metrics for Measuring Connectivity [RFC2678];
	o The One-way Delay Metric for IPPM [RFC2679];		o The One-way Delay Metric for IPPM [RFC2679];
	o The One-way Packet Loss Metric for IPPM [RFC2680];		o The One-way Packet Loss Metric for IPPM [RFC2680];
	o The Round-trip Delay Metric for IPPM [RFC2681];		o The Round-trip Delay Metric for IPPM [RFC2681];
	o A Framework for Defining Empirical Bulk Transfer Capacity Metrics		o A Framework for Defining Empirical Bulk Transfer Capacity Metrics
	[RFC3148];		[RFC3148];
	o One-way Loss Pattern Sample Metrics [RFC3357];		o One-way Loss Pattern Sample Metrics [RFC3357];
	o IP Packet Delay Variation Metric for IPPM [RFC3393];		o IP Packet Delay Variation Metric for IPPM [RFC3393];
	o Network performance measurement for periodic streams [RFC3432];		o Network performance measurement for periodic streams [RFC3432];
	o Packet Reordering Metric for IPPM [RFC4737];		o Packet Reordering Metrics [RFC4737];
	This memo defines spatial and one-to-group metrics based on the		o An IP Performance Metrics Registry [RFC4148];
	framework and on the end-to-end metrics defined in these documents.
	Firstly it defines spatial metrics:		IPPM has also developed a protocol for one-way source to destination
			measurements
			o A One-way Active Measurement Protocol Requirements [RFC3763];
			o A One-way Active Measurement Protocol (OWAMP) [RFC4656];
			This memo defines two new categories of metrics that extend the
			coverage to multiple measurement points. It first defines spatial
			metrics for measuring the performance of segments of a source to
			destination path:
	o A 'vector', called Type-P-Spatial-One-way-Delay-Vector, will be		o A 'vector', called Type-P-Spatial-One-way-Delay-Vector, will be
	introduced to divide an end-to-end Type-P-One-way-Delay [RFC2679]		introduced to divide an end-to-end Type-P-One-way-Delay [RFC2679]
	in a spatial sequence of one-way delays.		into a spatial sequence of one-way delay metrics.
	o A 'vector', called Type-P-Spatial-One-way-Packet-Loss-Vector, will		o A 'vector', called Type-P-Spatial-One-way-Packet-Loss-Vector, will
	be introduced to divide an end-to-end Type-P-One-way-Packet-Loss		be introduced to divide an end-to-end Type-P-One-way-Packet-Loss
	[RFC2680] in a spatial sequence of packet loss.		[RFC2680] in a spatial sequence of packet loss metrics.
	o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'vector',		o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'vector',
	called Type-P-Spatial-One-way-ipdv-Vector, will be introduced to		called Type-P-Spatial-One-way-ipdv-Vector, will be introduced to
	divide an end-to-end Type-P-One-way-ipdv in a spatial sequence of		divide an end-to-end Type-P-One-way-ipdv in a spatial sequence of
	ipdv.		ipdv metrics.
	o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample',		o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample',
	called Type-P-Segment-One-way-Delay-Stream, will be introduced to		called Type-P-Segment-One-way-Delay-Stream, will be introduced to
	define a set of one-way delays between a pair of host of the path;		collect a nested set of one-way delay metrics between the source,
			intermediate points of interest, and the destination;
	o Using the Type-P-Spatial-Packet-Loss-Vector metric, a 'sample',		o Using the Type-P-Spatial-Packet-Loss-Vector metric, a 'sample',
	called Type-P-Segment-Packet-Loss-Stream, will be introduced to		called Type-P-Segment-Packet-Loss-Stream, will be introduced to
	define a set of packet losses between a pair of host of the path;		collect a nested set of packet loss metrics between the source,
			intermediate points of interest, and the destination;
	o Using the Type-P-Spatial-ipdv-Vector metric, a 'sample', called		o Using the Type-P-Spatial-ipdv-Vector metric, a 'sample', called
	Type-P-Segment-ipdv-Stream, will be introduced to define a set of		Type-P-Segment-ipdv-Stream, will be introduced to collect a nested
	ipdvs between a pair of host of the path;		set of ipdv metrics between the source, intermediate points of
			interest, and the destination;
	Then it defines one-to-group metrics.		Note that all these metrics are based on observations of packets
			dedicated to testing, a process which is called Active measurement.
			Purely passive spatial measurement (for example, a spatial metric
			based on the observation of user traffic) is beyond the scope of this
			document and the current IPPM charter.
	o Using one test packet sent from one sender to a group of		Next, this memo defines one-to-group metrics.
	receivers, a 'sample', called Type-P-one-to-group-One-way-Delay-
	Vector, will be introduced to define the list of Type-P-one-way-
	delay [RFC2679] between this sender and the group of receivers.
	o Using one test packet sent from one sender to a group of		o Using one test packet sent from one sender to a group of
	receivers, a 'sample', called Type-P-one-to-group-One-way-Packet-		receivers, a metric called Type-P-one-to-group-One-way-Delay-
	Loss-Vector, will be introduced to define the list of Type-P-One-		Vector will be introduced to collect the set of Type-P-one-way-
	way-Packet-Loss [RFC2680] between this sender and the group of		delay [RFC2679] singletons between this sender and the group of
	receivers		receivers.
	o Using one test packet sent from one sender to a group of		o Using one test packet sent from one sender to a group of
	receivers, a 'sample', called Type-P-one-to-group-One-way-ipdv-		receivers, a metric called Type-P-one-to-group-One-way-Packet-
	Vector, will be introduced to define the list of Type-P-One-way-		Loss-Vector, will be introduced to collect the set of Type-P-One-
	ipdv between this sender and the group of receivers		way-Packet-Loss [RFC2680] singletons between this sender and the
			group of receivers
	o Then a discussion section presents the set of statistics that may		o Using one test packet sent from one sender to a group of
	be computed using these metrics to present the network performance		receivers, a metric called Type-P-one-to-group-One-way-ipdv-
	in the view of a group of users. The statistics may be the basis		Vector, will be introduced to collect the set of Type-P-One-way-
	for requirements (e.g. fairness) on multiparty communications. .		ipdv singletons between this sender and the group of receivers
			o A discussion section presents the set of statistics that may be
			computed using these metrics to present the network performance in
			the view of a group of users. The statistics may be the basis for
			requirements (e.g. fairness) on multiparty communications. .
	Reporting of metrics is defined in the section "Manageability		Metric Reporting is defined in the "Manageability Considerations"
	Consideration".		section.
	2. Terminology		2. Terminology
	2.1. Path Digest Hosts		2.1. Path Digest Hosts
	The list of the hosts of a path from a source to a destination.		The list of the hosts on a path from the source to the destination.
	2.2. Multiparty metric		2.2. Multiparty metric
	A metric is said to be multiparty if the topology involves more than		A metric is said to be multiparty if the topology involves more than
	one source or destination in the measurements. All multiparty		one measurement collection point. All multiparty metrics define a
	metrics define a set of hosts called "points of interest", where one		set of hosts called "points of interest", where one host is the
	host is the source and other hosts are the measurement collection		source and other hosts are the measurement collection points. For
	points. For example, if the set of points of interest is < ha, hb,		example, if the set of points of interest is < ha, hb, hc, ..., hn >,
	hc, ..., hn >, where ha is the source and < hb, hc, ..., hn > are the		where ha is the source and < hb, hc, ..., hn > are the destinations,
	destinations, then measurements may be conducted between < ha, hb>, <		then measurements may be conducted between < ha, hb>, < ha, hc>, ...,
	ha, hc>, ..., <ha, hn >.		<ha, hn >.
	For the purposes of this memo (reflecting the scope of a single		For the purposes of this memo (reflecting the scope of a single
	source), the only multiparty metrics are one-to-group metrics.		source), the only multiparty metrics are one-to-group metrics.
	2.3. Spatial metric		2.3. Spatial metric
	A metric is said to be spatial if one of the hosts involved is		A metric is said to be spatial if one of the hosts (measurement
	neither the source nor the destination of the measured packet.		collection points) involved is neither the source nor the destination
			of the measured packet.
	2.4. One-to-group metric		2.4. One-to-group metric
	A metric is said to be one-to-group if the measured packet is sent by		A metric is said to be one-to-group if the measured packet is sent by
	one source and (potentially) received by several destinations. Thus,		one source and (potentially) received by several destinations. Thus,
	the topology of the communication group can be viewed as a centre-		the topology of the communication group can be viewed as a centre-
	distributed or server-client topology with the source as the centre/		distributed or server-client topology with the source as the centre/
	server in the topology.		server in the topology.
	2.5. Points of interest		2.5. Points of interest
	Points of interest are the set of hosts* (as per RFC2330 definition,		Points of interest are the hosts* (as per RFC2330 definition, that
	that is including nodes) of the set of hosts involved in the delivery		includes routing nodes) that are measurement collection points, a
	of the packets (in addition to the source itself). Note that the set		sub-set of the set of hosts involved in the delivery of the packets
	of the points of interest are (a possibly arbitrary) subset of all		(in addition to the source itself). Note that the points of interest
	the hosts involved in the path. Points of interest of One-to-group		are a possibly arbitrary sub-set of all the hosts involved in the
	metrics are the hosts receiving packets from the source (in addition		path.
	to the source itself).
			Points of interest of One-to-group metrics are the intended
			destination hosts for packets from the source (in addition to the
			source itself).
	Src Recv		Src Recv
	`. ,-.		`. ,-.
	`. ,' `...... 1		`. ,' `...... 1
	`. ; :		`. ; :
	`. ; :		`. ; :
	; :... 2		; :... 2
	| |		| |
	: ;		: ;
	: ;.... 3		: ;.... 3
	: ;		: ;
	`. ,'		`. ,'
	`-'....... N		`-'....... N
	Figure 1: One-to-group points of interest		Figure 1: One-to-group points of interest
	A points of interest of spatial metrics is a host of the set of hosts		A candidate point of interest for spatial metrics is a host from the
	involved in the delivery of the packets from the source.		set of hosts involved in the delivery of the packets from the source.
	Src ------. Hosts		Src ------. Hosts
	\		\
	`---X ... 1		`---X ... 1
	\		\
	x		x
	/		/
	.---------X .... 2		.---------X .... 2
	/		/
	x		x
	skipping to change at page 8, line 7		skipping to change at page 8, line 31
	\		\
	\		\
	`---- Dst		`---- Dst
	Note: 'x' are nodes which are not points of interest		Note: 'x' are nodes which are not points of interest
	Figure 2: Spatial points of interest		Figure 2: Spatial points of interest
	2.6. Reference point		2.6. Reference point
	The centre/server in the multimetrics measurement that is controlled		A reference point is defined as the server where the statistical
	by network operators can be a very good reference point where		calculations will be carried out. A centre/server in the
	measurement data can be collected for further processing although the		multimetrics measurement that is controlled by a network operator is
	actual measurements have to be carried out at all points of interest.		a good example of a reference point, where measurement data can be
	Thus, we can define the reference point as the server where the		collected for further processing. However, the actual measurements
	statistic calculation will be carried out.		have to be carried out at all points of interest.
	2.7. Vector		2.7. Vector
	A Vector is a set of singletons, which are a set of results of the		A Vector is a set of singletons, which are a set of results of the
	observation of the behaviour of the same packet at different places		observation of the behaviour of the same packet at different places
	of a network at different time. For instance, if One-way delay		of a network at different times. For instance, if One-way delay
	singletons observed at N receivers for Packet P sent by the source		singletons observed at N receivers for Packet P sent by the source
	Src are dT1, dT2,..., dTN, it can be say that a vector V with N		Src are dT1, dT2,..., dTN, it can be say that a vector V with N
	elements can be organized as {dT1, dT2,..., dTN}. The elements in		elements can be organized as {dT1, dT2,..., dTN}. The elements in
	one vector are singletons distinct with each other in terms of both		one vector are singletons distinct with each other in terms of both
	measurement point and time. Given the vector V as an example, the		measurement point and sending time. Given the vector V as an
	element dT1 is distinct from the rest by measured at receiver 1 at		example, the element dT1 is distinct from all others as the singleton
	time T1. Additional to a singleton, Vector gives information over a		at receiver 1 in response to a packet sent from the source at time
	space dimension.		T1. The complete Vector gives information over the dimension of
			space.
	2.8. Matrix		2.8. Matrix
	Several vectors can form up a Matrix, which contains results observed		Several vectors form a Matrix, which contains results observed in a
	in a sampling interval at different place of a network at different		sampling interval at different places in a network at different time.
	time. For instance, given One-way delay vectors V1={dT11, dT12,...,		For instance, given One-way delay vectors V1={dT11, dT12,..., dT1N},
	dT1N}, V2={dT21, dT22,..., dT2N},..., Vm={dTm1, dTm2,..., dTmN} for		V2={dT21, dT22,..., dT2N},..., Vm={dTm1, dTm2,..., dTmN} for Packet
	Packet P1, P2,...,Pm, we can have a One-way delay Matrix {V1,		P1, P2,...,Pm, we can have a One-way delay Matrix {V1, V2,...,Vm}.
	V2,...,Vm}. Additional to the information given by a Vector, a		Additional to the information given by a Vector, a Matrix is more
	Matrix is more powerful to present network performance in both space		powerful to present network performance in both space and time
	and time dimensions. It normally corresponds to a sample.		dimensions. It normally corresponds to a sample in simple point-to-
			point measurement.
	The relation among Singleton, Vector and Matrix can be shown in the		The relation among Singleton, Vector and Matrix can be shown in the
	following Figure 3.		following Figure 3.
	Point of Singleton		Point of Singleton
	interest / Samples		interest / Samples
	,----. ^ /		,----. ^ /
	/ R1.....| / R1dT1 R1dT2 R1dT3 ... R3dTk \		/ R1.....| / R1dT1 R1dT2 R1dT3 ... R3dTk \
	/ \ | | |		/ \ | | |
	; R2........| | R2dT1 R2dT2 R2dT3 ... R3dTk |		; R2........| | R2dT1 R2dT2 R2dT3 ... R3dTk |
	skipping to change at page 9, line 26		skipping to change at page 9, line 41
	\ Rn......| \ RndT1 RndT2 RndT3 ... RndTk /		\ Rn......| \ RndT1 RndT2 RndT3 ... RndTk /
	`-----' +-------------------------------------> time		`-----' +-------------------------------------> time
	Vector Matrix		Vector Matrix
	(space) (time)		(space) (time)
	Figure 3: Relation beween Singletons, vectors and matrix		Figure 3: Relation beween Singletons, vectors and matrix
	3. Motivations		3. Motivations
	All IPPM metrics are defined for end-to-end measurement. These		All IPPM metrics are defined for end-to-end (source to destination)
	metrics provide very good guides for measurement in the pair		measurement of point-to-point paths. It is a logical extension to
	communications. However, further efforts should be put to define		define metrics for multiparty measurements such as one to one
	metrics for multiparty measurements such as one to one trajectory		trajectory metrics and one to multipoint metrics.
	metrics and one to multipoint metrics.
	3.1. Motivations for spatial metrics		3.1. Motivations for spatial metrics
	Decomposition of instantaneous end-to-end measures is needed:		Decomposition of instantaneous end-to-end measures is needed:
	o Decomposing the performance of interdomain path is desirable in		o Decomposing the performance of interdomain path is desirable to
	interdomain to qualify per AS contribution to the performance. So		quantify the per-AS contribution to the performance. It is
	it is necessary to define standard spatial metrics before going		valuable to define standard spatial metrics before pursuing inter-
	further in the computation of inter domain path with QoS		domain path performance specifications.
	constraint.
	o Traffic engineering and troubleshooting applications require
	spatial views of the one-way delay consumption, identification of
	the location of the lost of packets and the decomposition of the
	ipdv over the path.
	o Monitoring the QoS of a multicast tree, of MPLS point-to-		o Traffic engineering and troubleshooting applications benefit from
	multipoint and inter-domain communication require spatial		spatial views of one-way delay and ipdv consumption, and
	decomposition of the one-way delay, of the packet loss and of the		identification of the location of the lost of packets.
	ipdv.
	o Composition of metrics is a need to scale in the measurement		o Monitoring the performance of a multicast tree composed of MPLS
	plane. Spatial measure give typically the individual performance		point-to-multipoint and inter-domain communication require spatial
	of an intra domain segment. It is the elementary piece of		decomposition of the one-way delay, ipdv, and packet loss.
	information to exchange for measuring interdomain performance
	based on composition of metrics.
	o The PSAMP WG defines capabilities to sample packets in a way to to		o Composition of metrics [I-D.ietf-ippm-spatial-composition] is
	support instantaneous measurement respecful of the IPPM framework		needed to help measurement systems reach large scale coverage.
	[RFC2330]. Consequently it is necessary to define a set of		Spatial measure typically give the individual performance of an
	spatial metrics for passive and active techniques.		intra domain segment and provide an elementary piece of
			information needed to estimate interdomain performance based on
			composition of metrics.
	3.2. Motivations for One-to-group metrics		3.2. Motivations for One-to-group metrics
	While the node-to-node based spatial measures can provide very useful		While the node-to-node based spatial measures can provide very useful
	data in the view of each connection, we also need measures to present		data in the view of each connection, we also need measures to present
	the performance of a multiparty communication in the view of a group		the performance of a multiparty communication topology. A simple
	with consideration that it involves a group of people rather than		one-way metric cannot completely describe the multiparty situation.
	two. As a consequence a simple one-way metric cannot describe the		New one-to-group metrics assess performance of all the paths for
	multi-connection situation. We need some new metrics to collect		further statistical analysis. The new metrics proposed in this stage
	performance of all the connections for further statistics analysis.		are named one-to-group performance metrics, and they are based on the
	A group of metrics are proposed in this stage named one-to-group		unicast metrics defined in IPPM WG. One-to-group metrics are one-way
	performance metrics based on the unicast metrics defined in IPPM WG.		metrics from one source to a group of destinations. The metrics are
	One-to-group metrics are trying to composite one-way metrics from one		helpful for judging the network performance of multiparty
	source to a group of destinations to make up new metrics. The		communications and can also be used to describe the variation of
	compositions are necessary for judging the network performance of		performance delivered to a group of destination hosts and their
	multiparty communications and can also be used to describe the		users.
	difference of the QoS served among a group of users.
	One-to-group performance metrics are needed for several reasons:		One-to-group performance metrics are needed for several reasons:
	o For designing and engineering multicast trees and MPLS point-to-		o For designing and engineering multicast trees and MPLS point-to-
	multipoint LSP;		multipoint LSP;
	o For evaluating and controlling of the quality of the multicast		o For evaluating and controlling of the quality of the multicast
	services;		services;
	o For controlling the performance of the inter domain multicast		o For controlling the performance of the inter domain multicast
	services;		services;
	o For presenting and evaluating the relative QoS requirements for		o For presenting and evaluating the performance requirements for
	the multiparty communications.		multiparty communications.
	To understand the connection situation between one source and any one		To understand the packet transfer performance between one source and
	receiver in the multiparty communication group, we need the		any one receiver in the multiparty communication group, we need to
	collection of instantaneous end-to-end measures. It will give us		collect instantaneous end-to-end metrics, or singletons. It will
	very detailed insight into each branch of the multicast tree in terms		give a very detailed insight into each branch of the multicast tree
	of end-to-end absolute QoS. It can provide clear and helpful		in terms of end-to-end absolute performance. This detail can provide
	information for engineers to identify the connection with problems in		clear and helpful information for engineers to identify the sub-path
	a complex multiparty routing tree.		with problems in a complex multiparty routing tree.
	The one-to-group metrics described in this memo introduce one-to-many		The one-to-group metrics described in this memo introduce the
	concerns to the IPPM working group to measure the performance of a		multiparty topology to the IPPM working group; the goal is to measure
	group of users who receiving data from the same source. The concept		the performance delivered to a group of users who are receiving
	extends the "path" in the one-way measurement to "path tree" to cover		packets from the same source. The concept extends the "path" in the
	both one-to-one and one-to-many communications. Nevertheless,		one-way measurement to "path tree" to cover both one-to-one and one-
	applied to one-to-one communications they provide exactly the same		to-many communications. If applied to one-to-one communications, the
	results as the corresponding one-to-one metrics.		one-to-group metrics provide exactly the same results as the
			corresponding one-to-one metrics.
	3.3. Discussion on Group-to-one and Group-to-group metrics		3.3. Discussion on Group-to-one and Group-to-group metrics
	We note that points of interest can also be selected to define		We note that points of interest can also be selected to define
	measurements on Group-to-one and Group-to-group topologies. These		measurements on Group-to-one and Group-to-group topologies. These
	topologies are currently beyond the scope of this memo, because they		topologies are currently beyond the scope of this memo, because they
	would involve multiple packets launched from different sources.		would involve multiple packets launched from different sources.
	However, we can give some clues here on these two cases.		However, we can give some clues here on these two cases.
	The measurements for group-to-one topology can be easily derived from		The measurements for group-to-one topology can be easily derived from
	the one-to-group measurement. The measurement point is the reference		the one-to-group measurement. The measurement point is the reference
	point that is acting as a receiver while all of clients/receivers		point that is acting as a receiver while all of clients/receivers
	defined for one-to-group measurement act as sources in this case.		defined for one-to-group measurement act as sources in this case.
	For the group-to-group connection topology, we can hardly define the		For the group-to-group connection topology, it is difficult to define
	reference point and, therefore, have difficulty to define the		the reference point and therefore it is difficult to define the
	measurement points. However, we can always avoid this confusion by		measurement points. However, we can always avoid this confusion by
	treating the connections as one-to-group or group-to-one in our		treating the connections as one-to-group or group-to-one in our
	measurements without consideration on how the real communication will		measurements without consideration on how the real communication will
	be carried out. For example, if one group of hosts < ha, hb, hc,		be carried out. For example, if one group of hosts < ha, hb, hc,
	..., hn > are acting as sources to send data to another group of		..., hn > are acting as sources to send data to another group of
	hosts < Ha, Hb, Hc, ..., Hm >, we can always decompose them into n		hosts < Ha, Hb, Hc, ..., Hm >, we can always decompose them into n
	one-to-group communications as < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha,		one-to-group communications as < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha,
	Hb, Hc, ..., Hm >, <hc, Ha, Hb, Hc, ..., Hm >, ..., < hn, Ha, Hb, Hc,		Hb, Hc, ..., Hm >, <hc, Ha, Hb, Hc, ..., Hm >, ..., < hn, Ha, Hb, Hc,
	..., Hm >.		..., Hm >.
	skipping to change at page 17, line 35		skipping to change at page 17, line 35
	Methodology, reporting and uncertainties points specified in section		Methodology, reporting and uncertainties points specified in section
	2 of [RFC2680][RFC2680] applies to each point of interest Hi		2 of [RFC2680][RFC2680] applies to each point of interest Hi
	measuring a element of a spatial packet loss vector.		measuring a element of a spatial packet loss vector.
	Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability		Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability
	statements for end-to-end One-way ipdv measurements. They are		statements for end-to-end One-way ipdv measurements. They are
	applicable to each point of interest Hi involved in the measure.		applicable to each point of interest Hi involved in the measure.
	Spatial One-way ipdv measurement SHOULD be respectful of methodology,		Spatial One-way ipdv measurement SHOULD be respectful of methodology,
	clock, uncertainties and reporting aspects given in this section.		clock, uncertainties and reporting aspects given in this section.
	Passive and active measurement approaches of the metrology are
	considered as orthogonal. Active measure differs mainly from passive
	measure by the knowledge of the time the packet was send by the
	source and received by the destination, making the RFC2330 framework
	difficults to apply to passive measurement. On the other hand,
	spatial metrics rely on passive observation of the packets involved
	in the measure.
	In fact each approach compliments the other setting the base of
	spatial measurement methodology: Active points of interest provide
	information observed at the source and at the destination while
	Passive points of interests provide information observed at
	intermediary hosts of the path.
	Generally, for a given Type-P of length L, in a given Hi, the		Generally, for a given Type-P of length L, in a given Hi, the
	methodology for spatial vector metrics would proceed as follows:		methodology for spatial vector metrics would proceed as follows:
	o At each Hi, points of interest prepare to capture the packet sent		o At each Hi, points of interest prepare to capture the packet sent
	a time T, take a timestamp Ti', determine the internal delay		a time T, take a timestamp Ti', determine the internal delay
	correction dTi' (See section 3.7.1. "Errors or uncertainties		correction dTi' (See section 3.7.1. "Errors or uncertainties
	related to Clocks" of [RFC2679]),		related to Clocks" of [RFC2679]),
	o Each Hi extracts the path ordering information from the packet		o Each Hi extracts the path ordering information from the packet
	(e.g. time-to-live);		(e.g. time-to-live);
	o Each Hi compute the wiretime from Src to Hi: Ti = Ti' - dTi'.		o Each Hi compute the wiretime from Src to Hi: Ti = Ti' - dTi'.
	This arrival time is undefined (infinite) if the packet is not		This arrival time is undefined (infinite) if the packet is not
	detected after the 'loss threshold' duration;		detected after the 'loss threshold' duration;
	o Each Hi extracts the timestamp T from the packet,		o Each Hi extracts the timestamp T from the packet;
	o Each Hi computes the one-way-delay from Src to Hi: dTi = Ti - T;		o Each Hi computes the one-way-delay from Src to Hi: dTi = Ti - T;
	o The reference point gathers the result and time-to-live of each Hi		o The reference point gathers the result and time-to-live of each Hi
	and order them according to the path to build the Type-P-Spatial-		and order them according to the path to build the Type-P-Spatial-
	One-way-Delay-Vector metric <T,dT1,dT2,...,dTn,dT> over the path		One-way-Delay-Vector metric <T,dT1,dT2,...,dTn,dT> over the path
	<Src,H1, H2,..., Hn, Dst>.		<Src,H1, H2,..., Hn, Dst>.
	4.4.1. Loss threshold		4.4.1. Loss threshold
	Loss threshold is the centrality of any methodology because it		Loss threshold is the centrality of any methodology because it
	skipping to change at page 21, line 32		skipping to change at page 20, line 48
	with one probe synchronized using NTP having a clock resolution		with one probe synchronized using NTP having a clock resolution
	of 8ms.		of 8ms.
	o The location of the point of interest in the device influences the		o The location of the point of interest in the device influences the
	result. If the packet is not observed on the input interface the		result. If the packet is not observed on the input interface the
	delay includes buffering time and consequently an uncertainty due		delay includes buffering time and consequently an uncertainty due
	to the difference between 'wire time' and 'host time';		to the difference between 'wire time' and 'host time';
	o dTk.b may be observed and not dTk.a.		o dTk.b may be observed and not dTk.a.
	o Tk is unknown if the flow is made of end user packets, that is
	pure passive measure. In this case Tk may be forced to Tk+dTk.a.
	This motivate separate metrics names for pure passive measurement
	or specific reporting information.
	o Pure passive measure should consider packets of the same size and
	of the same Type-P.
	5.2. A Definition of a sample of Packet Loss of a segment of the path		5.2. A Definition of a sample of Packet Loss of a segment of the path
	This metric defines a sample of Packet lost between a pair of hosts		This metric defines a sample of Packet lost between a pair of hosts
	of a path.		of a path.
	5.2.1. Metric Name		5.2.1. Metric Name
	Type-P-segment-Packet-loss-Stream		Type-P-segment-Packet-loss-Stream
	5.2.2. Metric Parameters		5.2.2. Metric Parameters
	skipping to change at page 24, line 24		skipping to change at page 23, line 29
	Type-P-Segment-Ipdv-Stream		Type-P-Segment-Ipdv-Stream
	5.3.2. Metric Parameters		5.3.2. Metric Parameters
	5.3.3. Metric Units		5.3.3. Metric Units
	5.3.4. Definition		5.3.4. Definition
	5.3.5. Discussion		5.3.5. Discussion
	5.4. Discussion on Passive Segment Metrics
	A pure passive spatial measure is the measure of a spatial metric
	based on the observation of user traffic instead of packets dedicated
	to the measure.
	This section discusses the applicability of pure passive measurement
	methodology (e.g. without injecting test traffic as described by
	PSAMP documents [draft-ietf-psamp-sample-tech-10.txt]) to measure
	spatial metrics.
	To permit comparison and discussion, we firstly define pure passive
	measurement methodology following the spirit of IPPM framework
	[RFC2330] and the methodology of [RFC2679]. Then we propose several
	passive metrics complying to this framework.
	5.4.1. A methodololy for passive segment metrics
	The following starts from the point that the time a packet is sent is
	not needed to measure the delay from one host Ha of the path to
	another host Hb.
	Generally, for the packets of Type-P and length L sent a time <T1,
	T2,..., Tn> by the source Src pure passive methodology might proceed
	as follows:
	o Each point of interest Ha and Hb prepares to capture these
	packets;
	o Each point of interest Ha and Hb takes a timestamp Ti', determines
	the internal delay correction dTi' (See section 3.7.1. "Errors or
	uncertainties related to Clocks" of [RFC2679]),
	o Each points of interest Ha and Hb extracts the path ordering
	information from the packet (e.g. time-to-live)
	o Each points of interest Ha and Hb computes the wiretime fSrom Src
	to Hi: Ti = Ti' - dTi'. ;
	o The reference point gathers individual information for the packets
	sent a time <T1, T2,..., Tn> from each point of interest Ha and Hb
	and proceeds as follow:
	* Orders them according to the path ordering information;
	* Extracts the timestamps Ti.a and Ti+1.b. This arrival time is
	undefined (infinite) if the packet is not detected;
	* Computes the one-way-delay from Ha to Hb as (Ti+1.b - Ti.a).
	The delay is undefined (infinite) if the packet is not detected
	in Ha or Hb;
	o The reference point builds the segment sample <T1.b - T1.a, T2.b -
	T2.a,..., Tn.b - Tn.a> from Ha to Hb;
	5.4.2. Discussion on passive methodololy
	Intrinsically passive methodololy does not known (neither in the
	points of interest nor in the point of reference) the time each
	packet is sent <T1, T2,..., Tn> and the time each packet it received.
	Section 5.4.1 shows that a passive segment one-way delay measure does
	not rely on the time T the packet is sent to compute the delay from a
	host Ha to a host Hb.
	Intuitively, packets loss measurement does not require any time
	information and only expects the packet was sent. Passive packet
	loss methodology relies on the detection of the packet by one point
	of interest and not by another. This relies on asumptions similar to
	spatial methodology:
	o The knowledge of the path and the order of the points of interest
	over the path;
	o The packet is observed by one point of interest and not by
	another;
	Nevertheless, passive packet loss measure is limited by the fact that
	information that neither a packet has be sent nor that the packet was
	received is never available:
	when the path changes and the packet is not observed it is not
	deterministic to state that the packet is lost because the measure
	does not known that the packet is received by Dst.
	when the measure does not observe any packets it is not possible
	to state that all packets are lost because the measure does not
	known that any packets were sent.
	The drawback is that monitoring finely these events is crucial for
	troubleshooting workflow.
	IPPM framework relies on the mesure of the behavior of packets of the
	same size. Consequently a passive metric sample MUST not mix
	information of packets of different sizes.
	Segment metrics may be measured using pure passive technics. Passive
	segment metrics definitions are very closed to spatial segment
	metrics definitions. Therefore below we just name passive segment
	metrics to distinguish the methodology used. Having distinct metrics
	identifiers for spatial metrics and passive spatial metrics in the
	[RFC4148] will avoid interoperability issues especially during
	composition of metrics the IPPM WG is currently defining.
	5.4.3. Passive Segment metrics
	5.4.3.1. Passive Segment One way Delay metric
	This metric definition is based on the top of the Type-P-spatial-
	segment-One-way-Delay-Stream metric definition.
	name: Type-P-Passive-Segment-One-way-Delay-Stream
	5.4.3.2. Passive Segment Packet Loss metric
	This metric definition is based on the top of the Type-P-spatial-
	segment-Packet-Loss-Stream metric definition.
	name: Type-P-Passive-Segment-Packet-Loss-Stream
	5.4.3.3. Passive Segment One-way Ipdv metric
	This metric definition is based on the top of the Type-P-Segment-
	Ipdv-Stream metric definition.
	name: Type-P-Passive-Segment-One-way-Ipdv-Stream
	6. One-to-group metrics definitions		6. One-to-group metrics definitions
	6.1. A Definition for one-to-group One-way Delay		6.1. A Definition for one-to-group One-way Delay
	6.1.1. Metric Name		6.1.1. Metric Name
	Type-P-one-to-group-One-way-Delay-Vector		Type-P-one-to-group-One-way-Delay-Vector
	6.1.2. Metric Parameters		6.1.2. Metric Parameters
	skipping to change at page 43, line 9		skipping to change at page 39, line 9
	2 methods are available to compute group statistics:		2 methods are available to compute group statistics:
	o method1: Figure 10 andFigure 13 illustrate the method chosen: the		o method1: Figure 10 andFigure 13 illustrate the method chosen: the
	one-to-one statistic is computed per interval of time before the		one-to-one statistic is computed per interval of time before the
	computation of the mean over the group of receivers;		computation of the mean over the group of receivers;
	o method2: Figure 17 presents the second one, metric is computed		o method2: Figure 17 presents the second one, metric is computed
	over space and then over time.		over space and then over time.
	8.3.2. Impact on spatial stats		8.3.2. Impact on spatial stats
	2 methods are available to compute group statistics:		2 methods are available to compute spatial statistics:
	o method 1: spatial segment metrics and statistics are preferably		o method 1: spatial segment metrics and statistics are preferably
	computed over time by each points of interest;		computed over time by each points of interest;
	o method 2: Vectors metrics are intrinsecally instantaneous space		o method 2: Vectors metrics are intrinsically instantaneous space
	metrics which must be reported using method2 whenever		metrics which must be reported using method2 whenever
	instantaneous metrics information is needed. Pure passive		instantaneous metrics information is needed.
	measurement approach has no choice but to use this method because
	delay and losses may not be computed in each point of interest.
	9. Manageability Considerations		9. Manageability Considerations
	Usually IPPM WG documents defines each metric reporting within its		Usually IPPM WG documents defines each metric reporting within its
	definition. This document defines the reporting of all the metrics		definition. This document defines the reporting of all the metrics
	introduced in a single section to provide consistent information		introduced in a single section to provide consistent information
	while avoiding repetitions. the aim is to contribute to the work of		while avoiding repetitions. The aim is to contribute to the work of
	the WG on the reporting and to satisfy IESG recommendation of		the WG on the reporting and to satisfy IESG recommendation of
	gathering manageability considerations in a dedicated section.		gathering manageability considerations in a dedicated section.
	Data models of spatial and one-to-group metrics are similar excepted		Data models of spatial and one-to-group metrics are similar excepted
	that points of interests of spatial vectors must be ordered.		that points of interests of spatial vectors must be ordered.
	The complexity of the reporting relies on the number of points of		The complexity of the reporting relies on the number of points of
	interests.		interests.
	9.1. Reporting spatial metric		9.1. Reporting spatial metric
	skipping to change at page 44, line 27		skipping to change at page 40, line 27
	timestamping skew and accuracy. As an example, consider that some		timestamping skew and accuracy. As an example, consider that some
	internal machinery delays the timestamping up to 3 milliseconds then		internal machinery delays the timestamping up to 3 milliseconds then
	the minimal uncertainty reported be 3 ms if the internal delay is		the minimal uncertainty reported be 3 ms if the internal delay is
	unknown at the time of the timestamping.		unknown at the time of the timestamping.
	The report of a spatial vector must include the uncertainty of the		The report of a spatial vector must include the uncertainty of the
	timestamping compared to wire time.		timestamping compared to wire time.
	9.1.4. Reporting spatial One-way Delay		9.1.4. Reporting spatial One-way Delay
	The reporting includes information to report for one-way-delay as		The reporting includes information to report for one-way-delay as the
	perthe Section 3.6 of [RFC2679].the same apply for packet loss and		Section 3.6 of [RFC2679]. The same apply for packet loss and ipdv.
	ipdv
	9.2. Reporting One-to-group metric		9.2. Reporting One-to-group metric
			All reporting rules described in RFC2679-80 apply to the
			corresponding One-to-group metrics RFC2679-80. In addition, several
			new parameters are needed to report which are common to all the
			metrics and are presented here.
			9.2.1. Path
			As suggested by the RFC2679-80, the path traversed by the packet
			SHOULD be reported, if possible. For One-to-group metrics, there is
			a path tree SHOULD be reported rather than A path. This is even more
			impractical. If, by anyway, partial information is available to
			report, it might not be as valuable as it is in the one-to-one case
			because the incomplete path might be difficult to identify its
			position in the path tree. For example, how many points of interest
			are reached by the packet traveled through this incomplete path?
			However, the multicast path tree is normally more stable than
			unicast, which is dependant on multicast routing protocols. For
			example, the PIM-SM protocol [RFC4601] initializes the multicast
			route before any data packets are sent to the receivers.
			9.2.2. Group size
			The group size should be reported as one of the critical management
			parameters. Unlike the spatial metrics, there is no need of order of
			points of interests.
			9.2.3. Timestamping bias
			It is the same as described in section 9.1.3.
			9.2.4. Reporting One-to-group One-way Delay
			It is the same as described in section 9.1.4.
			9.2.5. Measurement method
			As explained in section 8, the measurement method will have impact on
			the analysis of the measurement result. Therefore, it should be
			reported.
	9.3. Metric identification		9.3. Metric identification
	IANA assigns each metric defined by the IPPM WG with a unique		IANA assigns each metric defined by the IPPM WG with a unique
	identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB.		identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB.
	To avoid misunderstanding and to address specific reporting		To avoid misunderstanding and to address specific reporting
	constraints, section Section 5.4.3 of this memo gives distinct names		constraints, section [passive_metrics] of this memo gives distinct
	to passive metrics and Section 13 requests a distinct metric		names to passive metrics and Section 13 requests a distinct metric
	identifier for each metrics the memo defines.		identifier for each metrics the memo defines.
	As it is crucial for composition of metrics to know the methodology		As it is crucial for composition of metrics to know the methodology
	used (e.g. generation method, detection method...), the report of a		used (e.g. generation method, detection method...), the report of a
	metric result used in composition of metrics MUST alway include its		metric result used in composition of metrics MUST always include its
	metric identifier.		metric identifier.
	9.4. Reporting data model		9.4. Reporting data model
	This section presents the elements of the datamodel and the usage of		This section presents the elements of the datamodel and the usage of
	the information reported for real network performance analysis. It		the information reported for real network performance analysis. It
	is out of the scope of this section to define how the information is		is out of the scope of this section to define how the information is
	reported.		reported.
	The data model is build with pieces of information introduced and		The data model is build with pieces of information introduced and
	skipping to change at page 51, line 32		skipping to change at page 48, line 21
	REFERENCE		REFERENCE
	"Reference "RFCyyyy, section 5.3."		"Reference "RFCyyyy, section 5.3."
	-- RFC Ed.: replace yyyy with actual RFC number & remove this		-- RFC Ed.: replace yyyy with actual RFC number & remove this
	note		note
	:= { ianaIppmMetrics nn } -- IANA assigns nn		:= { ianaIppmMetrics nn } -- IANA assigns nn
	Passive-Segment-One-way-Delay-Stream OBJECT-IDENTITY
	STATUS current
	DESCRIPTION
	"Type-P-Passive-Segment-One-way-Delay-Stream"
	REFERENCE
	"Reference "RFCyyyy, section 5.4.1."
	-- RFC Ed.: replace yyyy with actual RFC number & remove this
	note
	:= { ianaIppmMetrics nn } -- IANA assigns nn
	Passive-Segment-Packet-Loss-Stream OBJECT-IDENTITY
	STATUS current
	DESCRIPTION
	"Type-P-Passive-Segment-Packet-Loss-Stream"
	REFERENCE
	"Reference "RFCyyyy, section 5.4.2."
	-- RFC Ed.: replace yyyy with actual RFC number & remove this
	note
	:= { ianaIppmMetrics nn } -- IANA assigns nn
	Passive-Segment-One-way-ipdv-Stream OBJECT-IDENTITY
	STATUS current
	DESCRIPTION
	"Type-P-Passive-Segment-One-way-ipdv-Stream"
	REFERENCE
	"Reference "RFCyyyy, section 5.4.3."
	-- RFC Ed.: replace yyyy with actual RFC number & remove this
	note
	:= { ianaIppmMetrics nn } -- IANA assigns nn
	-- One-to-group metrics		-- One-to-group metrics
	one-to-group-One-way-Delay-Vector OBJECT-IDENTITY		one-to-group-One-way-Delay-Vector OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"Type-P-one-to-group-One-way-Delay-Vector"		"Type-P-one-to-group-One-way-Delay-Vector"
	skipping to change at page 56, line 10		skipping to change at page 51, line 44
	[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation		[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
	Metric for IP Performance Metrics (IPPM)", RFC 3393,		Metric for IP Performance Metrics (IPPM)", RFC 3393,
	November 2002.		November 2002.
	[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics		[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics
	Registry", BCP 108, RFC 4148, August 2005.		Registry", BCP 108, RFC 4148, August 2005.
	14.2. Informative References		14.2. Informative References
			[I-D.ietf-ippm-spatial-composition]
			Morton, A. and E. Stephan, "Spatial Composition of
			Metrics", draft-ietf-ippm-spatial-composition-05 (work in
			progress), November 2007.
	[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring		[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
	Connectivity", RFC 2678, September 1999.		Connectivity", RFC 2678, September 1999.
	[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip		[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
	Delay Metric for IPPM", RFC 2681, September 1999.		Delay Metric for IPPM", RFC 2681, September 1999.
	[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining		[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining
	Empirical Bulk Transfer Capacity Metrics", RFC 3148,		Empirical Bulk Transfer Capacity Metrics", RFC 3148,
	July 2001.		July 2001.
	skipping to change at page 56, line 39		skipping to change at page 52, line 31
	April 2004.		April 2004.
	[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.		[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
	Zekauskas, "A One-way Active Measurement Protocol		Zekauskas, "A One-way Active Measurement Protocol
	(OWAMP)", RFC 4656, September 2006.		(OWAMP)", RFC 4656, September 2006.
	[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,		[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
	S., and J. Perser, "Packet Reordering Metrics", RFC 4737,		S., and J. Perser, "Packet Reordering Metrics", RFC 4737,
	November 2006.		November 2006.
			[passive_metrics]
			"", 2005.
	Authors' Addresses		Authors' Addresses
	Stephan Emile		Stephan Emile
	France Telecom Division R&D		France Telecom Division R&D
	2 avenue Pierre Marzin		2 avenue Pierre Marzin
	Lannion, F-22307		Lannion, F-22307
	Fax: +33 2 96 05 18 52		Fax: +33 2 96 05 18 52
	Email: emile.stephan@orange-ftgroup.com		Email: emile.stephan@orange-ftgroup.com
	Lei Liang		Lei Liang
End of changes. 60 change blocks.
	389 lines changed or deleted		248 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/