 1/draftietfippmmultimetrics06.txt 20080626 17:12:21.000000000 +0200
+++ 2/draftietfippmmultimetrics07.txt 20080626 17:12:21.000000000 +0200
@@ 1,21 +1,21 @@
Network Working Group E. Stephan
InternetDraft France Telecom
Intended status: Informational L. Liang
Expires: August 17, 2008 University of Surrey
+Intended status: Standards Track L. Liang
+Expires: December 28, 2008 University of Surrey
A. Morton
AT&T Labs
 February 14, 2008
+ June 26, 2008
IP Performance Metrics (IPPM) for spatial and multicast
 draftietfippmmultimetrics06
+ draftietfippmmultimetrics07
Status of this Memo
By submitting this InternetDraft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
@@ 26,207 +26,224 @@
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use InternetDrafts as reference
material or to cite them other than as "work in progress."
The list of current InternetDrafts can be accessed at
http://www.ietf.org/ietf/1idabstracts.txt.
The list of InternetDraft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
 This InternetDraft will expire on August 17, 2008.

Copyright Notice

 Copyright (C) The IETF Trust (2008).
+ This InternetDraft will expire on December 28, 2008.
Abstract
The IETF IP Performance Metrics (IPPM) working group has standardized
metrics for measuring endtoend performance between two points.
This memo defines two new categories of metrics that extend the
coverage to multiple measurement points. It defines spatial metrics
for measuring the performance of segments of a source to destination
path, and metrics for measuring the performance between a source and
many destinations in multiparty communications (e.g., a multicast
tree).
+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 RFC 2119 [RFC2119].
+
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Path Digest Hosts . . . . . . . . . . . . . . . . . . . . 6
2.2. Multiparty metric . . . . . . . . . . . . . . . . . . . . 6
 2.3. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 6
 2.4. Onetogroup metric . . . . . . . . . . . . . . . . . . . 6
+ 2.3. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 7
+ 2.4. Onetogroup metric . . . . . . . . . . . . . . . . . . . 7
2.5. Points of interest . . . . . . . . . . . . . . . . . . . . 7
2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 8
2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Motivations for spatial metrics . . . . . . . . . . . . . 9
3.2. Motivations for Onetogroup metrics . . . . . . . . . . . 10
3.3. Discussion on Grouptoone and Grouptogroup metrics . . 11
4. Spatial vectors metrics definitions . . . . . . . . . . . . . 11
4.1. A Definition for Spatial Oneway Delay Vector . . . . . . 12
4.2. A Definition for Spatial Oneway Packet Loss Vector . . . 13
 4.3. A Definition for Spatial Oneway Ipdv Vector . . . . . . . 15
+ 4.3. A Definition for Spatial Oneway Ipdv Vector . . . . . . . 14
4.4. Spatial Methodology . . . . . . . . . . . . . . . . . . . 16
 5. Spatial Segments metrics definitions . . . . . . . . . . . . . 18
+ 5. Spatial Segments metrics definitions . . . . . . . . . . . . . 17
5.1. A Definition of a sample of Oneway Delay of a segment
of the path . . . . . . . . . . . . . . . . . . . . . . . 18
5.2. A Definition of a sample of Packet Loss of a segment
 of the path . . . . . . . . . . . . . . . . . . . . . . . 20
+ of the path . . . . . . . . . . . . . . . . . . . . . . . 19
5.3. A Definition of a sample of ipdv of a segment using
 the previous packet selection function . . . . . . . . . . 22
+ the previous packet selection function . . . . . . . . . . 20
5.4. A Definition of a sample of ipdv of a segment using
 the minimum delay selection function . . . . . . . . . . . 24
 6. Onetogroup metrics definitions . . . . . . . . . . . . . . . 25
 6.1. A Definition for Onetogroup Oneway Delay . . . . . . . 26
 6.2. A Definition for Onetogroup Oneway Packet Loss . . . . 26
 6.3. A Definition for Onetogroup Oneway Ipdv . . . . . . . . 27
 7. OnetoGroup Sample Statistics . . . . . . . . . . . . . . . . 28
 7.1. Discussion on the Impact of packet loss on statistics . . 31
 7.2. General Metric Parameters . . . . . . . . . . . . . . . . 32
 7.3. OnetoGroup oneway Delay Statistics . . . . . . . . . . 33
 7.4. OnetoGroup oneway Loss Statistics . . . . . . . . . . . 36
 7.5. OnetoGroup oneway Delay Variation Statistics . . . . . 38
 8. Measurement Methods: Scalability and Reporting . . . . . . . . 38
 8.1. Computation methods . . . . . . . . . . . . . . . . . . . 39
 8.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 40
 8.3. Effect of Time and Space Aggregation Order on Stats . . . 40
 9. Manageability Considerations . . . . . . . . . . . . . . . . . 42
 9.1. Reporting spatial metric . . . . . . . . . . . . . . . . . 42
 9.2. Reporting Onetogroup metric . . . . . . . . . . . . . . 43
 9.3. Metric identification . . . . . . . . . . . . . . . . . . 44
 9.4. Reporting data model . . . . . . . . . . . . . . . . . . . 44
 10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 47
 11. Security Considerations . . . . . . . . . . . . . . . . . . . 47
 11.1. Spatial metrics . . . . . . . . . . . . . . . . . . . . . 48
 11.2. onetogroup metric . . . . . . . . . . . . . . . . . . . 48
 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
 14.1. Normative References . . . . . . . . . . . . . . . . . . . 54
 14.2. Informative References . . . . . . . . . . . . . . . . . . 55
 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
 Intellectual Property and Copyright Statements . . . . . . . . . . 57
+ the minimum delay selection function . . . . . . . . . . . 22
+ 6. Onetogroup metrics definitions . . . . . . . . . . . . . . . 23
+ 6.1. A Definition for Onetogroup Oneway Delay . . . . . . . 23
+ 6.2. A Definition for Onetogroup Oneway Packet Loss . . . . 24
+ 6.3. A Definition for Onetogroup Oneway Ipdv . . . . . . . . 25
+ 7. OnetoGroup Sample Statistics . . . . . . . . . . . . . . . . 26
+ 7.1. Discussion on the Impact of packet loss on statistics . . 28
+ 7.2. General Metric Parameters . . . . . . . . . . . . . . . . 29
+ 7.3. OnetoGroup oneway Delay Statistics . . . . . . . . . . 30
+ 7.4. OnetoGroup oneway Loss Statistics . . . . . . . . . . . 32
+ 7.5. OnetoGroup oneway Delay Variation Statistics . . . . . 34
+ 8. Measurement Methods: Scalability and Reporting . . . . . . . . 35
+ 8.1. Computation methods . . . . . . . . . . . . . . . . . . . 36
+ 8.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 37
+ 8.3. Effect of Time and Space Aggregation Order on Stats . . . 37
+ 9. Manageability Considerations . . . . . . . . . . . . . . . . . 38
+ 9.1. Reporting spatial metric . . . . . . . . . . . . . . . . . 39
+ 9.2. Reporting Onetogroup metric . . . . . . . . . . . . . . 40
+ 9.3. Metric identification . . . . . . . . . . . . . . . . . . 40
+ 9.4. Information model . . . . . . . . . . . . . . . . . . . . 41
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 43
+ 10.1. Spatial metrics . . . . . . . . . . . . . . . . . . . . . 43
+ 10.2. onetogroup metric . . . . . . . . . . . . . . . . . . . 43
+ 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
+ 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
+ 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
+ 13.1. Normative References . . . . . . . . . . . . . . . . . . . 48
+ 13.2. Informative References . . . . . . . . . . . . . . . . . . 49
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
+ Intellectual Property and Copyright Statements . . . . . . . . . . 50
1. Introduction
 The IP Performance Metrics (IPPM) WG has defined a framework for
 metric definitions and endtoend, or source to destination
 measurements:

 o A general framework for defining performance metrics, described in
 the Framework for IP Performance Metrics [RFC2330];

 The Working Group has specified a set of endtoend metrics using the
 framework, and a registry for the metrics:

 o The IPPM Metrics for Measuring Connectivity [RFC2678];

 o The Oneway Delay Metric for IPPM [RFC2679];

 o The Oneway Packet Loss Metric for IPPM [RFC2680];

 o The Roundtrip Delay Metric for IPPM [RFC2681];

 o A Framework for Defining Empirical Bulk Transfer Capacity Metrics
 [RFC3148];

 o Oneway Loss Pattern Sample Metrics [RFC3357];

 o IP Packet Delay Variation Metric for IPPM [RFC3393];

 o Network performance measurement for periodic streams [RFC3432];

 o Packet Reordering Metrics [RFC4737];

 o An IP Performance Metrics Registry [RFC4148];
+ The IETF IP Performance Metrics (IPPM) working group has standardized
+ metrics for measuring endtoend performance between two points.
+ This memo defines two new categories of metrics that extend the
+ coverage to multiple measurement points. It defines spatial metrics
+ for measuring the performance of segments of a source to destination
+ path, and metrics for measuring the performance between a source and
+ many destinations in multiparty communications (e.g., a multicast
+ tree).
 IPPM has also developed a protocol for oneway source to destination
 measurements
+ The purpose of the memo is to define metrics to fulfill the new
+ requirements of measurement involving multiple measurement points.
+ Spatial metrics are defined to measure the performance of each
+ segments along a path while the onetogroup metrics are aiming to
+ provide a ruler to measure the performance of a group of users.
+ These metrics are derived from oneway endtoend metrics defined by
+ IETF and follow the criteria described in the IPPM framework
+ [RFC2330].
 o A Oneway Active Measurement Protocol Requirements [RFC3763];
+ New terms are introduced to extend the terminology of the IPPM
+ framework to spatial metrics and onetogroup metrics. Then a
+ section motivates the need of defining each category of metrics.
+ After, each category is defined in a separate section. Then the memo
+ discusses the impact of the measurement methods on the scalability
+ and proposes an information model for reporting the measurements.
+ Finally the document discusses security aspects related to
+ measurement and registers the metrics in the IANA IP Performance
+ Metrics Registry [RFC4148].
 o A Oneway Active Measurement Protocol (OWAMP) [RFC4656];
+ 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
+ memo.
 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:
+ Following is a summary of the metrics defined.
 o A 'vector', called TypePSpatialOnewayDelayVector, will be
+ This memo firstly defines metrics for spatial measurement based on
+ the decomposition of standard endtoend metrics defined by IETF in
+ [[RFC2679], [RFC2680], [RFC3393], [RFC3432]. Seven metrics are
+ defined including their names, parameters, units and measurement
+ methodologies. Each definion includes a specific section discussing
+ measurements constraints and issues, and proposing guidance to
+ increase results accucacy. These spatial metrics are:
+ o A 'Vector', called TypePSpatialOnewayDelayVector, will be
introduced to divide an endtoend TypePOnewayDelay [RFC2679]
into a spatial sequence of oneway delay metrics.
 o A 'vector', called TypePSpatialOnewayPacketLossVector, will
+ o A 'Vector', called TypePSpatialOnewayPacketLossVector, will
be introduced to divide an endtoend TypePOnewayPacketLoss
[RFC2680] in a spatial sequence of packet loss metrics.

o Using the TypePSpatialOnewayDelayVector metric, a 'vector',
called TypePSpatialOnewayipdvVector, will be introduced to
divide an endtoend TypePOnewayipdv in a spatial sequence of
ipdv metrics.

o Using the TypePSpatialOnewayDelayVector metric, a 'sample',
called TypePSegmentOnewayDelayStream, will be introduced to
collect oneway delay metrics over time between two points of
interest of the path;

o Using the TypePSpatialPacketLossVector metric, a 'sample',
called TypePSegmentPacketLossStream, will be introduced to
collect packet loss metrics over time between two points of
interest of the path;

o Using the TypePSpatialOnewayDelayVector metric, a 'sample',
called TypePSegmentipdvprevStream, will be introduced to
compute ipdv metrics over time between two points of interest of
the path using the previous packet selection function;

o Using the TypePSpatialOnewayDelayVector metric, a 'sample',
called TypePSegmentipdvminStream, will be introduced to
compute ipdv metrics over time between two points of interest of
the path using the shortest delay selection function;
 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.

 Next, this memo defines onetogroup metrics.

 o Using one test packet sent from one sender to a group of
 receivers, a metric called TypePonetogroupOnewayDelay
 Vector will be introduced to collect the set of TypePoneway
 delay [RFC2679] singletons between this sender and the group of
 receivers.
+ Then the memo defines onetogroup metrics and onetogroup
+ statistics.
 o Using one test packet sent from one sender to a group of
 receivers, a metric called TypePonetogroupOnewayPacket
 LossVector, will be introduced to collect the set of TypePOne
 wayPacketLoss [RFC2680] singletons between this sender and the
 group of receivers
 o Using one test packet sent from one sender to a group of
 receivers, a metric called TypePonetogroupOnewayipdv
 Vector, will be introduced to collect the set of TypePOneway
 ipdv singletons between this sender and the group of receivers
+ Three onetogroup metrics are defined to measure the oneway
+ performance between a source and a group of receivers. Definitions
+ derive from oneway metrics definitions of RFCs in [RFC2679],
+ [RFC2680], [RFC3393], [RFC3432]:
+ o A 'Vector', called TypePOnetoGroupOnewayDelayVector, will
+ be introduced to collect the set of TypePonewaydelay
+ singletons between one sender and N receivers;
+ o A 'Vector', called TypePOnetoGroupOnewayPacketLossVector,
+ will be introduced to collect the set of TypePOnewayPacket
+ Loss singletons between one sender and N receivers;
+ o A 'Vector', called TypePOnetoGroupOnewayipdvVector, will
+ be introduced to collect the set of TypePOnewayipdv singletons
+ between one sender and N 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. .
+ Then, based on the Onetogroup vector metrics listed above,
+ statistics are defined to capture single receiver performance, group
+ performance and relative performance situation inside a multiparty
+ communication for each packet sent during the test interval between
+ one sender and N receivers:
 Metric Reporting is defined in the "Manageability Considerations"
 section.
+ o Using the TypePOnetoGroupOnewayDelayVector, a metric
+ called TypePOnetoGroupReceivernMeanDelay will be
+ introduced to present the mean of delays between one sender and a
+ receiver 'n'. Then, based on this definition, 3 metrics will be
+ defined to characterize the mean delay over the entire group
+ during this interval:
+ * a metric called TypePOnetoGroupMeanDelay, will be
+ introduced to present the mean of delays;
+ * a metric called TypePOnetoGroupRangeMeanDelay will be
+ introduced to present the range of mean delays;
+ * a metric called TypePOnetoGroupMaxMeanDelay will be
+ introduced to present the maximum of mean delays;
+ o Using the TypePonetogroupOnewayPacketLossVector, a metric
+ called TypePOnetoGroupReceivernLossRatio will be
+ introduced to capture packet loss ratio between one sender and a
+ receiver 'n'. Then based on this definition, 2 metrics will be
+ defined to characterize packet loss over the entire group during
+ this interval:
+ * a metric called TypePOnetoGroupLossRatio will be
+ introduced to capture packet loss ratio overall over the entire
+ group or all receivers;
+ * a metric called TypePOnetoGroupRangeLossRatio will be
+ introduced to present comparative packet loss ratio for each
+ packet during the test interval between one sender and N
+ Receivers.
+ o Using TypePonetogroupOnewayipdvVector, a metric called
+ TypePOnetoGroupRangeDelayVariation will be introduced to
+ present the range of delay variation between one sender and a
+ group of receivers.
2. Terminology
2.1. Path Digest Hosts
The list of the hosts on a path from the source to the destination.
2.2. Multiparty metric
A metric is said to be multiparty if the topology involves more than
@@ 371,40 +388,35 @@
3. Motivations
All IPPM metrics are defined for endtoend (source to destination)
measurement of pointtopoint paths. It is a logical extension to
define metrics for multiparty measurements such as one to one
trajectory metrics and one to multipoint metrics.
3.1. Motivations for spatial metrics
Decomposition of instantaneous endtoend measures is needed:

o Decomposing the performance of interdomain path is desirable to
quantify the perAS contribution to the performance. It is
valuable to define standard spatial metrics before pursuing inter
domain path performance specifications.

o Traffic engineering and troubleshooting applications benefit from
spatial views of oneway delay and ipdv consumption, and
identification of the location of the lost of packets.

o Monitoring the performance of a multicast tree composed of MPLS
pointtomultipoint and interdomain communication require spatial
decomposition of the oneway delay, ipdv, and packet loss.

 o Composition of metrics [ID.ietfippmspatialcomposition] is
 needed to help measurement systems reach large scale coverage.
 Spatial measures typically give the individual performance of an
 intra domain segment and provide an elementary piece of
 information needed to estimate interdomain performance based on
 composition of metrics.
+ o Composition of metrics is needed to help measurement systems reach
+ large scale coverage. Spatial measures typically give the
+ individual performance of an intra domain segment and provide an
+ elementary piece of information needed to estimate interdomain
+ performance based on composition of metrics.
3.2. Motivations for Onetogroup metrics
While the nodetonode based spatial measures can provide very useful
data in the view of each connection, we also need measures to present
the performance of a multiparty communication topology. A simple
oneway metric cannot completely describe the multiparty situation.
New onetogroup metrics assess performance of all the paths for
further statistical analysis. The new metrics proposed in this stage
are named onetogroup performance metrics, and they are based on the
@@ 480,22 +488,22 @@
endtoend metrics defined by the IPPM WG in [RFC2679], [RFC2680],
[RFC3393] and [RFC3432].
Definitions are coupled with the corresponding endtoend metrics.
Methodology specificities are common to all the vectors defined and
are consequently discussed in a common section.
4.1. A Definition for Spatial Oneway Delay Vector
This section is coupled with the definition of TypePOnewayDelay
 of the section 3 of [RFC2679]. When a parameter of this definitionis
 first used in this section, it will be tagged with a trailing
+ of the section 3 of [RFC2679]. When a parameter of this definition
+ is first used in this section, it will be tagged with a trailing
asterisk.
Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability
statements for endtoend onewaydelay measurements. They are
applicable to each point of interest Hi involved in the measure.
Spatial onewaydelay measurement SHOULD be respectful of them,
especially those related to methodology, clock, uncertainties and
reporting.
4.1.1. Metric Name
@@ 1219,36 +1101,35 @@
6.3. A Definition for Onetogroup Oneway Ipdv
6.3.1. Metric Name
TypePOnetogroupOnewayipdvVector
6.3.2. Metric Parameters
o Src, the IP address of a host acting as the source.

o Recv1,..., RecvN, the IP addresses of the N hosts acting as
receivers.

o T1, a time.

o T2, a time.

o ddT1, ...,ddTn, a list of time.

o P, the specification of the packet type.

o F, a selection function defining unambiguously the two packets
from the stream selected for the metric.

 o Gr, the receiving group identifier.
+ o Gr, the receiving group identifier. The parameter Gr is the
+ multicast group address if the measured packets are transmitted
+ over IP multicast. This parameter is to differentiate the
+ measured traffic from other unicast and multicast traffic. It is
+ optional in the metric to avoid losing any generality, i.e. to
+ make the metric also applicable to unicast measurement where there
+ is only one receiver.
6.3.3. Metric Units
The value of a TypePOnetogroupOnewayipdvVector is a set of
TypePOnewayipdv singletons [RFC3393].
6.3.4. Definition
Given a Type P packet stream, TypePOnetogroupOnewayipdvVector
is defined for two packets from the source Src to the N hosts
@@ 1425,22 +1305,22 @@
Matrix and can not calculate the statistics. In an extreme
situation, no single packet arrives all users in the measurement and
the Matrix will be empty. One of the possible solutions is to
replace the infinite/undefined delay value by the average of the two
adjacent values. For example, if the result reported by user1 is {
R1dT1 R1dT2 R1dT3 ... R1dTK1 UNDEF R1dTK+1... R1DM } where "UNDEF"
is an undefined value, the reference point can replace it by R1dTK =
{(R1dTK1)+( R1dTK+1)}/2. Therefore, this result can be used to
build up the group Matrix with an estimated value R1dTK. There are
other possible solutions such as using the overall mean of the whole
 result to replace the infinite/undefined value, and so on. It is out
 of the scope of this memo.
+ result to replace the infinite/undefined value, and so on. However
+ this is out of the scope of this memo.
For the distributed calculation, the reported statistics might have
different "weight" to present the group performance, which is
especially true for delay and ipdv relevant metrics. For example,
User1 calculates the TypePFiniteOnewayDelayMean R1DM as shown
in Figure. 8 without any packet loss and User2 calculates the R2DM
with N2 packet loss. The R1DM and R2DM should not be treated with
equal weight because R2DM was calculated only based on 2 delay values
in the whole sample interval. One possible solution is to use a
weight factor to mark every statistic value sent by users and use
@@ 1442,302 +1322,308 @@
in Figure. 8 without any packet loss and User2 calculates the R2DM
with N2 packet loss. The R1DM and R2DM should not be treated with
equal weight because R2DM was calculated only based on 2 delay values
in the whole sample interval. One possible solution is to use a
weight factor to mark every statistic value sent by users and use
this factor for further statistic calculation.
7.2. General Metric Parameters
o Src, the IP address of a host;

o G, the receiving group identifier;

o N, the number of Receivers (Recv1, Recv2, ... RecvN);

o T, a time (start of test interval);

o Tf, a time (end of test interval);

o K, the number of packets sent from the source during the test
interval;
o J[n], the number of packets received at a particular Receiver, n,
where 1<=n<=N;

o lambda, a rate in reciprocal seconds (for Poisson Streams);

o incT, the nominal duration of interpacket interval, first bit to
first bit (for Periodic Streams);

o T0, a time that MUST be selected at random from the interval [T,
T+I] to start generating packets and taking measurements (for
Periodic Streams);

o TstampSrc, the wire time of the packet as measured at MP(Src) (the
Source Measurement Point);

o TstampRecv, the wire time of the packet as measured at MP(Recv),
assigned to packets that arrive within a "reasonable" time;

o Tmax, a maximum waiting time for packets at the destination, set
sufficiently long to disambiguate packets with long delays from
packets that are discarded (lost), thus the distribution of delay
is not truncated;

o dT, shorthand notation for a oneway delay singleton value;

o L, shorthand notation for a oneway loss singleton value, either
zero or one, where L=1 indicates loss and L=0 indicates arrival at
the destination within TstampSrc + Tmax, may be indexed over n
Receivers;

o DV, shorthand notation for a oneway delay variation singleton
value;
7.3. OnetoGroup oneway Delay Statistics
 This section defines the overall oneway delay statistics for an
 entire Group or receivers. For example, we can define the group mean
 delay, as illustrated below. This is a metric designed to summarize
 the whole matrix.
+ This section defines the overall oneway delay statistics for a
+ receiver and for an entire group as illustrated by the matrix below.
Recv / Sample \ Stats Group Stat
1 R1dT1 R1dT2 R1dT3 ... R1dTk R1DM \

2 R2dT1 R2dT2 R2dT3 ... R2dTk R2DM 

 3 R3dT1 R3dT2 R3dT3 ... R3dTk R2DM > GMD
+ 3 R3dT1 R3dT2 R3dT3 ... R3dTk R2DM > Group delay
. 
. 
. 
n RndT1 RndT2 RndT3 ... RndTk RnDM /
 Figure 5: OnetoGroup Mean Delay

 where:

 R1dT1 is the TypePFiniteOnewayDelay singleton evaluated at
 Receiver 1 for packet 1.

 R1DM is the TypePFiniteOnewayDelayMean evaluated at Receiver 1
 for the sample of packets (1,...K).

 GMD is the mean of the sample means over all Receivers (1, ...N).

7.3.1. Definition and Metric Units

 Using the parameters above, we obtain the value of TypePOneway
 Delay singleton for all packets sent during the test interval at each
 Receiver (Destination), as per [RFC2679]. For each packet that
 arrives within Tmax of its sending time, TstampSrc, the oneway delay
 singleton (dT) will be a finite value in units of seconds.
 Otherwise, the value of the singleton is Undefined.
+ Receivern
+ delay
 For each packet [i] that has a finite Oneway Delay at Receiver n (in
 other words, excluding packets which have undefined oneway delay):
+ Figure 5: OnetoGroup Mean Delay
 TypePFiniteOnewayDelayReceivern[i] =
+ Statistics are computed on the finite Oneway delays of the matrix
+ above.
 = TstampRecv[i]  TstampSrc[i]
+ All Onetogroup delay statistics are expressed in seconds with
+ sufficient resolution to convey 3 significant digits.
 The units of Finite oneway delay are seconds, with sufficient
 resolution to convey 3 significant digits.
+7.3.1. TypePOnetoGroupReceivernMeanDelay
7.3.2. Sample Mean Statistic
+ This section defines TypePOnetoGroupReceivernMeanDelay the
+ Delay Mean at each Receiver N, also named RnDM.
 This section defines the Sample Mean at each of N Receivers.
+ We obtain the value of TypePOnewayDelay singleton for all packets
+ sent during the test interval at each Receiver (Destination), as per
+ [RFC2679]. For each packet that arrives within Tmax of its sending
+ time, TstampSrc, the oneway delay singleton (dT) will be the finite
+ value TstampRecv[i]  TstampSrc[i] in units of seconds. Otherwise,
+ the value of the singleton is Undefined.
 TypePFiniteOnewayDelayMeanReceivern = RnDM =
J[n]

1 \
  * > TypePFiniteOnewayDelayReceivern[i]
+ RnDM =  * > TstampRecv[i]  TstampSrc[i]
J[n] /

i = 1
 Figure 6: TypePFiniteOnewayDelayMeanReceivern
+ Figure 6: TypePOnetoGroupReceiverMeanDelay
where all packets i= 1 through J[n] have finite singleton delays.
7.3.3. OnetoGroup Mean Delay Statistic
+7.3.2. TypePOnetoGroupMeanDelay
 This section defines the Mean Oneway Delay calculated over the
 entire Group (or Matrix).
+ This section defines TypePOnetoGroupMeanDelay, the Mean Oneway
+ delay calculated over the entire Group, also named GMD.
 TypePOnetoGroupMeanDelay = GMD =
N

1 \
  * > RnDM
+ GMD =  * > RnDM
N /

n = 1
Figure 7: TypePOnetoGroupMeanDelay
Note that the Group Mean Delay can also be calculated by summing the
Finite oneway Delay singletons in the Matrix, and dividing by the
number of Finite Oneway Delay singletons.
7.3.4. OnetoGroup Range of Mean Delays
+7.3.3. TypePOnetoGroupRangeMeanDelay
This section defines a metric for the range of mean delays over all N
receivers in the Group, (R1DM, R2DM,...RnDM).
TypePOnetoGroupRangeMeanDelay = GRMD = max(RnDM)  min(RnDM)
7.3.5. OnetoGroup Maximum of Mean Delays
+7.3.4. TypePOnetoGroupMaxMeanDelay
 This section defines a metrics for the maximum of mean delays over
 all N receivers in the Group, (R1DM, R2DM,...RnDM).
+ This section defines a metric for the maximum of mean delays over all
+ N receivers in the Group, (R1DM, R2DM,...RnDM).
TypePOnetoGroupMaxMeanDelay = GMMD = max(RnDM)
7.4. OnetoGroup oneway Loss Statistics
 This section defines the overall 1way loss statistics for an entire
 Group. For example, we can define the group loss ratio, as
 illustrated below. This is a metric designed to summarize the entire
 Matrix.
+ This section defines the overall oneway loss statistics for a
+ receiver and for an entire group as illustrated by the matrix below.
Recv / Sample \ Stats Group Stat
1 R1L1 R1L2 R1L3 ... R1Lk R1LR \

2 R2L1 R2L2 R2L3 ... R2Lk R2LR 

 3 R3L1 R3L2 R3L3 ... R3Lk R3LR > GLR
+ 3 R3L1 R3L2 R3L3 ... R3Lk R3LR > Group Loss Ratio
. 
. 
. 
n RnL1 RnL2 RnL3 ... RnLk RnLR /
 Figure 8: OnetoGroup Loss Ratio

 where:

 R1L1 is the TypePOnewayLoss singleton (L) evaluated at Receiver 1
 for packet 1.

 R1LR is the TypePOnewayLossRatio evaluated at Receiver 1 for the
 sample of packets (1,...K).

 GLR is the loss ratio over all Receivers (1, ..., N).

7.4.1. OnetoGroup Loss Ratio

 The overall Group loss ratio id defined as
+ Receivern
+ Loss Ratio
 TypePOnetoGroupLossRatio =
 K,N
 
 1 \
 =  * > L(k,n)
 K*N /
 
 k,n = 1
+ Figure 8: OnetoGroup Loss Ratio
 Figure 9
+ Statistics are computed on the sample of TypePOnewayPacketLoss
+ [RFC2680] of the matrix above.
 ALL Loss ratios are expressed in units of packets lost to total
+ All loss ratios are expressed in units of packets lost to total
packets sent.
7.4.2. OnetoGroup Loss Ratio Range
+7.4.1. TypePOnetoGroupReceivernLossRatio
Given a Matrix of loss singletons as illustrated above, determine the
TypePOnewayPacketLossAverage for the sample at each receiver,
according to the definitions and method of [RFC2680]. The TypeP
 OnewayPacketLossAverage, RnLR for receiver n, and the TypePOne
 wayLossRatio illustrated above are equivalent metrics. In terms of
 the parameters used here, these metrics definitions can be expressed
 as
+ OnewayPacketLossAverage and the TypePOnetoGroupReceivern
+ LossRatio, also named RnLR, are equivalent metrics. In terms of the
+ parameters used here, these metrics definitions can be expressed as
 TypePOnewayLossRatioReceivern = RnLR =
K

1 \
  * > RnLk
+ RnLR =  * > RnLk
K /

k = 1
 Figure 10: TypePOnewayLossRatioReceivern

 The OnetoGroup Loss Ratio Range is defined as

 TypePOnetoGroupLossRatioRange = max(RnLR)  min(RnLR)

 It is most effective to indicate the range by giving both the max and
 minimum loss ratios for the Group, rather than only reporting the
 difference between them.
+ Figure 9: TypePOnetoGroupReceivernLossRatio
7.4.3. Comparative Loss Ratio
+7.4.2. TypePOnetoGroupReceivernCompLossRatio
Usually, the number of packets sent is used in the denominator of
packet loss ratio metrics. For the comparative metrics defined here,
the denominator is the maximum number of packets received at any
receiver for the sample and test interval of interest.
 The Comparative Loss Ratio is defined as
+ The Comparative Loss Ratio, also named, RnCLR, is defined as
 TypePCompLossRatioReceivern = RnCLR =
K

\
> Ln(k)
/

k=1
 = 
+ RnCLR = 
/ K \
  
 \ 
K  Min  > Ln(k) 
 / 
  
\ k=1 / N
 Figure 11: TypePCompLossRatioReceivern
+ Figure 10: TypePOnetoGroupReceivernCompLossRatio
+
+7.4.3. TypePOnetoGroupLossRatio
+
+ TypePOnetoGroupLossRatio, the overall Group loss ratio, also
+ named GLR, is defined as
+ K,N
+ 
+ 1 \
+ GLR =  * > L(k,n)
+ K*N /
+ 
+ k,n = 1
+
+ Figure 11: TypePOnetoGroupLossRatio
+
+7.4.4. TypePOnetoGroupRangeLossRatio
+
+ The OnetoGroup Loss Ratio Range is defined as:
+
+ TypePOnetoGroupRangeLossRatio = max(RnLR)  min(RnLR)
+
+ It is most effective to indicate the range by giving both the max and
+ minimum loss ratios for the Group, rather than only reporting the
+ difference between them.
7.5. OnetoGroup oneway Delay Variation Statistics
 There are two delay variation (DV) statistics that summarize the
 performance over the Group: the maximum DV over all receivers and the
 minimum DV over all receivers (where DV is a pointtopoint metric).
+ This section defines oneway delay variation (DV) statistics for an
+ entire group as illustrated by the matrix below.
+
+ Recv / Sample \ Stats
+
+ 1 R1ddT1 R1ddT2 R1ddT3 ... R1ddTk R1DV \
+ 
+ 2 R2ddT1 R2ddT2 R2ddT3 ... R2ddTk R2DV 
+ 
+ 3 R3ddT1 R3ddT2 R3ddT3 ... R3ddTk R3DV > Group Stat
+ . 
+ . 
+ . 
+ n RnddT1 RnddT2 RnddT3 ... RnddTk RnDV /
+
+ Figure 12: OnetoGroup Delay Variation Matrix (DVMa)
+
+ Statistics are computed on the sample of TypePOnewayDelay
+ Variation singletons of the group delay variation matrix above where
+ RnddTk is the TypePOnewayDelayVariation singleton evaluated at
+ Receiver n for the packet k and where RnDV is the pointtopoint one
+ way packet delay variation for Receiver n.
+
+ All Onetogroup delay variation statistics are expressed in seconds
+ with sufficient resolution to convey 3 significant digits.
+
+7.5.1. TypePOnetoGroupDelayVariationRange
+
+ This section defines a metric for the range of delays variation over
+ all N receivers in the Group.
+
+ Maximum DV and minimum DV over all receivers summarize the
+ performance over the Group (where DV is a pointtopoint metric).
For each receiver, the DV is usually expressed as the 110^(3)
quantile of oneway delay minus the minimum oneway delay.
+ TypePOnetoGroupDelayVariationRange = GDVR =
+
+ = max(RnDV)  min(RnDV) for all n receivers
+
+ This range is determined from the minimum and maximum values of the
+ pointtopoint oneway IP Packet Delay Variation for the set of
+ Destinations in the group and a population of interest, using the
+ Packet Delay Variation expressed as the 110^3 quantile of oneway
+ delay minus the minimum oneway delay. If a more demanding service
+ is considered, one alternative is to use the 110^5 quantile, and in
+ either case the quantile used should be recorded with the results.
+ Both the minimum and the maximum delay variation are recorded, and
+ both values are given to indicate the location of the range.
+
8. Measurement Methods: Scalability and Reporting
Virtually all the guidance on measurement processes supplied by the
earlier IPPM RFCs (such as [RFC2679] and [RFC2680]) for onetoone
scenarios is applicable here in the spatial and multiparty
measurement scenario. The main difference is that the spatial and
 multiparty configurations require multiple measurement points where a
+ multiparty configurations require multiple points of interest where a
stream of singletons will be collected. The amount of information
requiring storage grows with both the number of metrics and the
 number of measurement points, so the scale of the measurement
 architecture multiplies the number of singleton results that must be
 collected and processed.
+ points of interest, so the scale of the measurement architecture
+ multiplies the number of singleton results that must be collected and
+ processed.
It is possible that the architecture for results collection involves
 a single aggregation point with connectivity to all the measurement
 points. In this case, the number of measurement points determines
+ a single reference point with connectivity to all the points of
+ interest. In this case, the number of points of interest determines
both storage capacity and packet transfer capacity of the host acting
 as the aggregation point. However, both the storage and transfer
 capacity can be reduced if the measurement points are capable of
+ as the reference point. However, both the storage and transfer
+ capacity can be reduced if the points of interest are capable of
computing the summary statistics that describe each measurement
interval. This is consistent with many operational monitoring
architectures today, where even the individual singletons may not be
 stored at each measurement point.
+ stored at each point of interest.
In recognition of the likely need to minimize form of the results for
storage and communication, the Group metrics above have been
constructed to allow some computations on a perReceiver basis. This
means that each Receiver's statistics would normally have an equal
weight with all other Receivers in the Group (regardless of the
number of packets received).
8.1. Computation methods
@@ 1771,21 +1657,21 @@
measurement campaign to optimize the measurement results delivery.
The possible solution could be to transit the statistic parameters to
the reference point first to obtain the general information of the
group performance. If the detail results are required, the reference
point should send the requests to the points of interest, which could
be particular ones or the whole group. This procedure can happen in
the off peak time and can be well scheduled to avoid delivery of too
many points of interest at the same time. Compression techniques can
also be used to minimize the bandwidth required by the transmission.
This could be a measurement protocol to report the measurement
 results. It is out of the scope of this memo.
+ results. However, this is out of the scope of this memo.
8.2. Measurement
To prevent any bias in the result, the configuration of a onetomany
measure must take in consideration that implicitly more packets will
to be routed than send and selects a test packets rate that will not
impact the network performance.
8.3. Effect of Time and Space Aggregation Order on Stats
@@ 1806,25 +1692,24 @@
. 
. 
n RnS1 RnS2 RnS3 ... RnSk /
S1M S2M S3M ... SnM Stats over space
\ /
\/
Stat over space and time
 Figure 12: Impact of space aggregation on multimetrics Stat
+ Figure 13: Impact of space aggregation on multimetrics Stat
2 methods are available to compute statistics on the resulting
matrix:

o metric is computed over time and then over space;
o metric is computed over space and then over time.
They differ only by the order of the time and of the space
aggregation. View as a matrix this order is neutral as does not
impact the result, but the impact on a measurement deployment is
critical.
In both cases the volume of data to report is proportional to the
number of probes. But there is a major difference between these 2
@@ 1852,72 +1734,70 @@
control of various collecting aspects such as bandwidth and
computation and storage capacities. So this draft defines metrics
based on method 1.
Note: In some specific cases one may need sample of singletons over
space. To address this need it is suggested firstly to limit the
number of test and the number of test packets per seconds. Then
reducing the size of the sample over time to one packet give sample
of singleton over space..
8.3.1. Impact on group stats

 2 methods are available to compute group statistics:

 o method1: Figure 5 andFigure 8 illustrate the method chosen: the
 onetoone statistic is computed per interval of time before the
 computation of the mean over the group of receivers;
 o method2: Figure 12 presents the second one, metric is computed
 over space and then over time.

8.3.2. Impact on spatial stats
+8.3.1. Impact on spatial statistics
2 methods are available to compute spatial statistics:

o method 1: spatial segment metrics and statistics are preferably
computed over time by each points of interest;

o method 2: Vectors metrics are intrinsically instantaneous space
metrics which must be reported using method2 whenever
instantaneous metrics information is needed.
+8.3.2. Impact on onetogroup statistics
+
+ 2 methods are available to compute group statistics:
+ o method1: Figure 5 andFigure 8 illustrate the method chosen: the
+ onetoone statistic is computed per interval of time before the
+ computation of the mean over the group of receivers;
+ o method2: Figure 13 presents the second one, metric is computed
+ over space and then over time.
+
9. Manageability Considerations
Usually IPPM WG documents defines each metric reporting within its
definition. This document defines the reporting of all the metrics
 introduced in a single section to provide consistent information
 while avoiding repetitions. The aim is to contribute to the work of
 the WG on the reporting and to satisfy IESG recommendation of
 gathering manageability considerations in a dedicated section.
+ introduced in a single section to provide consistent information, to
+ avoid repetitions and to conform to IESG recommendation of gathering
+ manageability considerations in a dedicated section.
 Data models of spatial and onetogroup metrics are similar excepted
 that points of interests of spatial vectors must be ordered.
+ Information models of spatial metrics and of onetogroup metrics are
+ similar excepted that points of interests of spatial vectors must be
+ ordered.
The complexity of the reporting relies on the number of points of
interests.
9.1. Reporting spatial metric
The reporting of spatial metrics shares a lot of aspects with
RFC267980. New ones are common to all the definitions and are
mostly related to the reporting of the path and of methodology
parameters that may bias raw results analysis. This section presents
these specific parameters and then lists exhaustively the parameters
that shall be reported.
9.1.1. Path
Endtoend metrics can't determine the path of the measure despite
 IPPM RFCs recommend it to be reported (Section 3.8.4 of [RFC2679]).
 Spatial metrics vectors provide this path. The report of a spatial
 vector must include the points of interests involved: the sub set of
 the hosts of the path participating to the instantaneous measure.
+ IPPM RFCs recommend it to be reported (See Section 3.8.4 of
+ [RFC2679]). Spatial metrics vectors provide this path. The report
+ of a spatial vector must include the points of interests involved:
+ the sub set of the hosts of the path participating to the
+ instantaneous measure.
9.1.2. Host order
A spatial vector must order the points of interest according to their
order in the path. It is highly suggested to use the TTL in IPv4,
the Hop Limit in IPv6 or the corresponding information in MPLS.
The report of a spatial vector must include the ordered list of the
hosts involved in the instantaneous measure.
@@ 1933,38 +1813,33 @@
timestamping compared to wire time.
9.1.4. Reporting spatial Oneway Delay
The reporting includes information to report for onewaydelay as the
Section 3.6 of [RFC2679]. The same apply for packet loss and ipdv.
9.2. Reporting Onetogroup metric
All reporting rules described in RFC267980 apply to the
 corresponding Onetogroup metrics RFC267980. In addition, several
 new parameters are needed to report which are common to all the
 metrics and are presented here.
+ corresponding Onetogroup metrics. Following are specific
+ parameters that should be reported.
9.2.1. Path
As suggested by the RFC267980, the path traversed by the packet
SHOULD be reported, if possible. For Onetogroup 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 onetoone 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 PIMSM 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.
@@ 1977,546 +1852,398 @@
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
IANA assigns each metric defined by the IPPM WG with a unique
identifier as per [RFC4148] in the IANAIPPMMETRICSREGISTRYMIB.
9.4. Reporting data model
+9.4. Information model
 This section presents the elements of the datamodel and the usage of
 the information reported for real network performance analysis. It
 is out of the scope of this section to define how the information is
+ This section presents the elements of information and the usage of
+ the information reported for network performance analysis. It is out
+ of the scope of this section to define how the information is
reported.
 The data model is build with pieces of information introduced and
 explained in oneway delay definitions [RFC2679], in packet loss
 definitions [RFC2680] and in IPDV definitions[RFC3393][RFC3432]. It
 includes not only information given by "Reporting the metric"
 sections but by sections "Methodology" and "Errors and Uncertainties"
 sections.
+ The information model is build with pieces of information introduced
+ and explained in oneway delay definitions [RFC2679], in packet loss
+ definitions [RFC2680] and in IPDV definitions of [RFC3393] and
+ [RFC3432]. It includes not only information given by "Reporting the
+ metric" sections but by sections "Methodology" and "Errors and
+ Uncertainties" sections.
 Following are the elements of the datamodel taken from endtoend
+ Following are the elements of information taken from endtoend
definitions referred in this memo and from spatial and multicast
metrics it defines:
o Packet_type, The TypeP of test packets (TypeP);

o Packet_length, a packet length in bits (L);
o Src_host, the IP address of the sender;

o Dst_host, the IP address of the receiver;

o Hosts_serie: , a list of points of interest;

o Loss_threshold: The threshold of infinite delay;

o Systematic_error: constant delay between wire time and
timestamping;

o Calibration_error: maximal uncertainty;

o Src_time, the sending time for a measured packet;

o Dst_time, the receiving time for a measured packet;

o Result_status : an indicator of usability of a result 'Resource
exhaustion' 'infinite', 'lost';

o Delays_serie: a list of delays;

o Losses_serie: , a list of Boolean values
(spatial) or a set of Boolean values (onetogroup);

o Result_status_serie: a list of results status;

o dT: a delay;

o Singleton_number: a number of singletons;

o Observation_duration: An observation duration;

o metric_identifier.
Following is the information of each vector that should be available
to compute samples:
o Packet_type;

o Packet_length;

o Src_host, the sender of the packet;

o Dst_host, the receiver of the packet, apply only for spatial
vectors;
o Hosts_serie: not ordered for onetogroup;

o Src_time, the sending time for the measured packet;

o dT, the endtoend oneway delay for the measured packet, apply
only for spatial vectors;

o Delays_serie: apply only for delays and ipdv vector, not ordered
for onetogroup;

o Losses_serie: apply only for packets loss vector, not ordered for
onetogroup;

o Result_status_serie;

o Observation_duration: the difference between the time of the last
singleton and the time of the first singleton.

o Following is the context information (measure, points of
interests) that should be available to compute samples :

* Loss threshold;

* Systematic error: constant delay between wire time and
timestamping;

* Calibration error: maximal uncertainty;
A spatial or a onetogroup sample is a collection of singletons
giving the performance from the sender to a single point of interest.
Following is the information that should be available for each sample
to compute statistics:
o Packet_type;

o Packet_length;

o Src_host, the sender of the packet;

o Dst_host, the receiver of the packet;

o Start_time, the sending time of the first packet;

o Delays_serie: apply only for delays and ipdv samples;

o Losses_serie: apply only for packets loss samples;
o Result_status_serie;

o Observation_duration: the difference between the time of the last
singleton of the last sample and the time of the first singleton
of the first sample.

o Following is the context information (measure, points of
interests) that should be available to compute statistics :

* Loss threshold;

* Systematic error: constant delay between wire time and
timestamping;

* Calibration error: maximal uncertainty;
Following is the information of each statistic that should be
reported:
o Result;

o Start_time;

o Duration;

o Result_status;

o Singleton_number, the number of singletons the statistic is
computed on;
10. Open issues

 Do we define min, max, avg of for each segment metrics ?

 having the maximum loss metric value could be interesting. Say,
 the segment between router A and B always contributes loss metric
 value of "1" means it could be the potential problem segment.

 Uploading dTi of each Hi consume a lot of bandwidth. Computing
 statistics (min, max and avg) of dTi locally in each Hi reduce the
 bandwidth consumption.

11. Security Considerations
+10. Security Considerations
Spatial and onetogroup metrics are defined on the top of endtoend
metrics. Security considerations discussed in Oneway delay metrics
 definitions of [RFC2679] , in packet loss metrics definitions
 of[RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432]
 apply to multimetrics.
+ definitions of [RFC2679] , in packet loss metrics definitions of
+ [RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432]
+ apply to metrics defined in this memo.
11.1. Spatial metrics
+10.1. Spatial metrics
Malicious generation of packets with spoofing addresses may corrupt
the results without any possibility to detect the spoofing.
Malicious generation of packets which match systematically the hash
function used to detect the packets may lead to a DoS attack toward
the point of reference.
11.2. onetogroup metric
+10.2. onetogroup metric
 The reporting of measurement results from a huge number of probes may
 overload the network the reference point is attach to, the reference
 point network interfaces and the reference point computation
 capacities.
+ Reporting of measurement results from a huge number of probes may
+ overload reference point ressources (network, network interfaces,
+ computation capacities ...).
 The configuration of a measure must take in consideration that
+ The configuration of a measurement must take in consideration that
implicitly more packets will to be routed than send and selects a
test packets rate accordingly. Collecting statistics from a huge
number of probes may overload any combination of the network where
 the measurement controller is attach to, measurement controller
+ the measurement controller is attached to, measurement controller
network interfaces and measurement controller computation capacities.
 onetogroup metrics measurement should consider using source
+ Onetogroup metrics measurement should consider using source
authentication protocols, standardized in the MSEC group, to avoid
fraud packet in the sampling interval. The test packet rate could be
negotiated before any measurement session to avoid deny of service
attacks.
12. Acknowledgments
+11. Acknowledgments
Lei would like to acknowledge Prof. Zhili Sun from CCSR, University
of Surrey, for his instruction and helpful comments on this work.
13. IANA Considerations
+12. IANA Considerations
Metrics defined in this memo Metrics defined in this memo are
designed to be registered in the IANA IPPM METRICS REGISTRY as
described in initial version of the registry [RFC4148] :
IANA is asked to register the following metrics in the IANAIPPM
METRICSREGISTRYMIB :
ietfSpatialOneWayDelayVector OBJECTIDENTITY

STATUS current

DESCRIPTION

"TypePSpatialOnewayDelayVector"

REFERENCE

"Reference "RFCyyyy, section 4.1."

 RFC Ed.: replace yyyy with actual RFC number & remove this
note

:= { ianaIppmMetrics nn }  IANA assigns nn
ietfSpatialPacketLossVector OBJECTIDENTITY

STATUS current

DESCRIPTION

"TypePSpatialPacketLossVector"

REFERENCE

"Reference "RFCyyyy, section 4.2."

 RFC Ed.: replace yyyy with actual RFC number & remove this
note

:= { ianaIppmMetrics nn }  IANA assigns nn
ietfSpatialOneWayIpdvVector OBJECTIDENTITY

STATUS current

DESCRIPTION

"TypePSpatialOnewayipdvVector"

REFERENCE

"Reference "RFCyyyy, section 4.3."
 RFC Ed.: replace yyyy with actual RFC number & remove this
note

:= { ianaIppmMetrics nn }  IANA assigns nn
 ietfSpatialSegmentOnewayDelayStream OBJECTIDENTITY

+ ietfSegmentOneWayDelayStream OBJECTIDENTITY
STATUS current

DESCRIPTION

 "TypePSpatialSegmentOnewayDelayStream"

+ "TypePSegmentOnewayDelayStream"
REFERENCE

"Reference "RFCyyyy, section 5.1."

 RFC Ed.: replace yyyy with actual RFC number & remove this
note

:= { ianaIppmMetrics nn }  IANA assigns nn
 ietfSpatialSegmentPacketLossStream OBJECTIDENTITY

+ ietfSegmentPacketLossStream OBJECTIDENTITY
STATUS current

DESCRIPTION

 "TypePSpatialSegmentPacketLossStream"

+ "TypePSegmentPacketLossStream"
REFERENCE

"Reference "RFCyyyy, section 5.2."

 RFC Ed.: replace yyyy with actual RFC number & remove this
note

:= { ianaIppmMetrics nn }  IANA assigns nn
 ietfSpatialSegmentOneWayIpdvPrevStream OBJECTIDENTITY

+ ietfSegmentOneWayIpdvPrevStream OBJECTIDENTITY
STATUS current

DESCRIPTION

 "TypePSpatialSegmentipdvprevStream"
+ "TypePSegmentOnewayipdvprevStream"
REFERENCE

"Reference "RFCyyyy, section 5.3."

 RFC Ed.: replace yyyy with actual RFC number & remove this
note

:= { ianaIppmMetrics nn }  IANA assigns nn
 ietfSpatialSegmentOneWayIpdvMinStream OBJECTIDENTITY

+ ietfSegmentOneWayIpdvMinStream OBJECTIDENTITY
STATUS current

DESCRIPTION

 "TypePSpatialSegmentipdvminStream"

+ "TypePSegmentOnewayipdvminStream"
REFERENCE

"Reference "RFCyyyy, section 5.4."

 RFC Ed.: replace yyyy with actual RFC number & remove this
note

:= { ianaIppmMetrics nn }  IANA assigns nn
 Onetogroup metrics
ietfOneToGroupOneWayDelayVector OBJECTIDENTITY

STATUS current

DESCRIPTION

 "TypePonetogroupOnewayDelayVector"

+ "TypePOnetogroupOnewayDelayVector"
REFERENCE

"Reference "RFCyyyy, section 6.1."

 RFC Ed.: replace yyyy with actual RFC number & remove this
note

:= { ianaIppmMetrics nn }  IANA assigns nn
ietfOneToGroupOneWayPktLossVector OBJECTIDENTITY
STATUS current

DESCRIPTION

 "TypePonetogroupOnewayPacketLossVector"

+ "TypePOnetoGroupOnewayPacketLossVector"
REFERENCE

"Reference "RFCyyyy, section 6.2."

 RFC Ed.: replace yyyy with actual RFC number & remove this
note

:= { ianaIppmMetrics nn }  IANA assigns nn
ietfOneToGroupOneWayIpdvVector OBJECTIDENTITY

STATUS current

DESCRIPTION

 "TypePonetogroupOnewayipdvVector"

+ "TypePOnetoGroupOnewayipdvVector"
REFERENCE

"Reference "RFCyyyy, section 6.3."

 RFC Ed.: replace yyyy with actual RFC number & remove this
note

:= { ianaIppmMetrics nn }  IANA assigns nn
 One to group statistics

 ietfOneToGroupMeanDelay OBJECTIDENTITY

+ ietfOnetoGroupReceiverNMeanDelay OBJECTIDENTITY
STATUS current

DESCRIPTION
+ "TypePOnetoGroupReceivernMeanDelay"
+ REFERENCE
+ "Reference "RFCyyyy, section 7.3.1."
+  RFC Ed.: replace yyyy with actual RFC number & remove this
+ note
+ := { ianaIppmMetrics nn }  IANA assigns nn
+ ietfOneToGroupMeanDelay OBJECTIDENTITY
+ STATUS current
+ DESCRIPTION
"TypePOnetoGroupMeanDelay"

REFERENCE

 "Reference "RFCyyyy, section 6.3.3."
+ "Reference "RFCyyyy, section 7.3.2."
 RFC Ed.: replace yyyy with actual RFC number & remove this
note

:= { ianaIppmMetrics nn }  IANA assigns nn

ietfOneToGroupRangeMeanDelay OBJECTIDENTITY

STATUS current

DESCRIPTION

"TypePOnetoGroupRangeMeanDelay"

REFERENCE

 "Reference "RFCyyyy, section 6.3.4."

+ "Reference "RFCyyyy, section 7.3.3."
 RFC Ed.: replace yyyy with actual RFC number & remove this
note

:= { ianaIppmMetrics nn }  IANA assigns nn
ietfOneToGroupMaxMeanDelay OBJECTIDENTITY

STATUS current

DESCRIPTION

"TypePOnetoGroupMaxMeanDelay"

REFERENCE
+ "Reference "RFCyyyy, section 7.3.4."
+  RFC Ed.: replace yyyy with actual RFC number & remove this
+ note
+ := { ianaIppmMetrics nn }  IANA assigns nn
 "Reference "RFCyyyy, section 6.3.5."

+ ietfOneToGroupReceiverNLossRatio OBJECTIDENTITY
+ STATUS current
+ DESCRIPTION
+ "TypePOnetoGroupReceivernLossRatio"
+ REFERENCE
+ "Reference "RFCyyyy, section 7.4.1."
 RFC Ed.: replace yyyy with actual RFC number & remove this
note
+ := { ianaIppmMetrics nn }  IANA assigns nn
+ 
+ ietfOneToGroupReceiverNCompLossRatio OBJECTIDENTITY
+ STATUS current
+ DESCRIPTION
+ "TypePOnetoGroupReceivernCompLossRatio"
+ REFERENCE
+ "Reference "RFCyyyy, section 7.4.2."
+  RFC Ed.: replace yyyy with actual RFC number & remove this
+ note
:= { ianaIppmMetrics nn }  IANA assigns nn
ietfOneToGroupLossRatio OBJECTIDENTITY

STATUS current

DESCRIPTION

"TypePOnetoGroupLossRatio"
REFERENCE

 "Reference "RFCyyyy, section 6.4.1."

+ "Reference "RFCyyyy, section 7.4.3."
 RFC Ed.: replace yyyy with actual RFC number & remove this
note

:= { ianaIppmMetrics nn }  IANA assigns nn


 ietfOneToGroupLossRatioRange OBJECTIDENTITY

+ ietfOneToGroupRangeLossRatio OBJECTIDENTITY
STATUS current

DESCRIPTION

 "TypePOnetoGroupLossRatioRange"

+ "TypePOnetoGroupRangeLossRatio"
REFERENCE

 "Reference "RFCyyyy, section 6.4.2."

+ "Reference "RFCyyyy, section 7.4.4."
 RFC Ed.: replace yyyy with actual RFC number & remove this
note
+ := { ianaIppmMetrics nn }  IANA assigns nn
+ ietfOneToGroupRangeDelayVariation OBJECTIDENTITY
+ STATUS current
+ DESCRIPTION
+ "TypePOnetoGroupRangeDelayVariation"
+ REFERENCE
+ "Reference "RFCyyyy, section 7.5.1."
+  RFC Ed.: replace yyyy with actual RFC number & remove this
+ note
:= { ianaIppmMetrics nn }  IANA assigns nn

14. References
+13. References
14.1. Normative References
+13.1. Normative References
 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
 "Framework for IP Performance Metrics", RFC 2330,
 May 1998.
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A Oneway
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A Oneway
Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002.
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics
Registry", BCP 108, RFC 4148, August 2005.
14.2. Informative References

 [ID.ietfippmspatialcomposition]
 Morton, A. and E. Stephan, "Spatial Composition of
 Metrics", draftietfippmspatialcomposition05 (work in
 progress), November 2007.

 [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
 Connectivity", RFC 2678, September 1999.

 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Roundtrip
 Delay Metric for IPPM", RFC 2681, September 1999.

 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining
 Empirical Bulk Transfer Capacity Metrics", RFC 3148,
 July 2001.
+13.2. Informative References
 [RFC3357] Koodli, R. and R. Ravikanth, "Oneway Loss Pattern Sample
 Metrics", RFC 3357, August 2002.
+ [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
+ "Framework for IP Performance Metrics", RFC 2330,
+ May 1998.
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432,
November 2002.
 [RFC3763] Shalunov, S. and B. Teitelbaum, "Oneway Active
 Measurement Protocol (OWAMP) Requirements", RFC 3763,
 April 2004.

 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
 Zekauskas, "A Oneway Active Measurement Protocol
 (OWAMP)", RFC 4656, September 2006.

 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
 S., and J. Perser, "Packet Reordering Metrics", RFC 4737,
 November 2006.

 [passive_metrics]
 "", 2005.

Authors' Addresses
Stephan Emile
France Telecom Division R&D
2 avenue Pierre Marzin
Lannion, F22307
Fax: +33 2 96 05 18 52
Email: emile.stephan@orangeftgroup.com
@@ 2568,15 +2295,10 @@
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF online IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietfipr@ietf.org.

Acknowledgment

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).