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/