draft-ietf-ippm-multipoint-alt-mark-04.txt   draft-ietf-ippm-multipoint-alt-mark-05.txt 
IPPM Working Group G. Fioccola, Ed. IPPM Working Group G. Fioccola, Ed.
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Experimental M. Cociglio Intended status: Experimental M. Cociglio
Expires: July 10, 2020 Telecom Italia Expires: August 3, 2020 Telecom Italia
A. Sapio A. Sapio
R. Sisto R. Sisto
Politecnico di Torino Politecnico di Torino
January 7, 2020 January 31, 2020
Multipoint Alternate Marking method for passive and hybrid performance Multipoint Alternate Marking method for passive and hybrid performance
monitoring monitoring
draft-ietf-ippm-multipoint-alt-mark-04 draft-ietf-ippm-multipoint-alt-mark-05
Abstract Abstract
The Alternate Marking method, as presented in RFC 8321 [RFC8321], can The Alternate Marking method, as presented in RFC 8321 [RFC8321], can
be applied only to point-to-point flows because it assumes that all be applied only to point-to-point flows because it assumes that all
the packets of the flow measured on one node are measured again by a the packets of the flow measured on one node are measured again by a
single second node. This document aims to generalize and expand this single second node. This document aims to generalize and expand this
methodology to measure any kind of unicast flows, whose packets can methodology to measure any kind of unicast flows, whose packets can
follow several different paths in the network, in wider terms a follow several different paths in the network, in wider terms a
multipoint-to-multipoint network. For this reason the technique here multipoint-to-multipoint network. For this reason the technique here
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 10, 2020. This Internet-Draft will expire on August 3, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Correlation with RFC5644 . . . . . . . . . . . . . . . . . . 4 2. Correlation with RFC5644 . . . . . . . . . . . . . . . . . . 4
3. Flow classification . . . . . . . . . . . . . . . . . . . . . 5 3. Flow classification . . . . . . . . . . . . . . . . . . . . . 5
4. Multipoint Performance Measurement . . . . . . . . . . . . . 7 4. Multipoint Performance Measurement . . . . . . . . . . . . . 7
4.1. Monitoring Network . . . . . . . . . . . . . . . . . . . 7 4.1. Monitoring Network . . . . . . . . . . . . . . . . . . . 7
5. Multipoint Packet Loss . . . . . . . . . . . . . . . . . . . 9 5. Multipoint Packet Loss . . . . . . . . . . . . . . . . . . . 8
6. Network Clustering . . . . . . . . . . . . . . . . . . . . . 9 6. Network Clustering . . . . . . . . . . . . . . . . . . . . . 9
6.1. Algorithm for Cluster partition . . . . . . . . . . . . . 10 6.1. Algorithm for Cluster partition . . . . . . . . . . . . . 10
7. Timing Aspects . . . . . . . . . . . . . . . . . . . . . . . 13 7. Timing Aspects . . . . . . . . . . . . . . . . . . . . . . . 13
8. Multipoint Delay and Delay Variation . . . . . . . . . . . . 15 8. Multipoint Delay and Delay Variation . . . . . . . . . . . . 15
8.1. Delay measurements on multipoint paths basis . . . . . . 15 8.1. Delay measurements on multipoint paths basis . . . . . . 15
8.1.1. Single Marking measurement . . . . . . . . . . . . . 15 8.1.1. Single Marking measurement . . . . . . . . . . . . . 15
8.2. Delay measurements on single packets basis . . . . . . . 16 8.2. Delay measurements on single packets basis . . . . . . . 15
8.2.1. Single and Double Marking measurement . . . . . . . . 16 8.2.1. Single and Double Marking measurement . . . . . . . . 15
8.2.2. Hashing selection method . . . . . . . . . . . . . . 16 8.2.2. Hashing selection method . . . . . . . . . . . . . . 16
9. An Intelligent Performance Management approach . . . . . . . 18 9. An Intelligent Performance Management approach . . . . . . . 18
10. Examples of application . . . . . . . . . . . . . . . . . . . 19 10. Examples of application . . . . . . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Normative References . . . . . . . . . . . . . . . . . . 20 14.1. Normative References . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . 21 14.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The alternate marking method, as presented until now, is applicable The alternate marking method, as presented until now, is applicable
to a point-to-point path; so the extension proposed in this document to a point-to-point path; so the extension proposed in this document
explains the most general case of multipoint-to-multipoint path and explains the most general case of multipoint-to-multipoint path and
enables flexible and adaptive performance measurements in a managed enables flexible and adaptive performance measurements in a managed
network. network.
The Alternate Marking methodology described in RFC 8321 [RFC8321] has The Alternate Marking methodology described in RFC 8321 [RFC8321] has
skipping to change at page 9, line 20 skipping to change at page 9, line 15
counted by all the output nodes. counted by all the output nodes.
And in case of no packet loss occurring in the marking period, if all And in case of no packet loss occurring in the marking period, if all
the input and output points of the network domain to be monitored are the input and output points of the network domain to be monitored are
measurement points, the sum of the number of packets on all the measurement points, the sum of the number of packets on all the
ingress interfaces equals the number on egress interfaces for the ingress interfaces equals the number on egress interfaces for the
monitored flow. In this circumstance, if no packet loss occurs, the monitored flow. In this circumstance, if no packet loss occurs, the
intermediate measurement points have only the task to split the intermediate measurement points have only the task to split the
measurement. measurement.
It is possible to define the Network Packet Loss (for 1 monitored It is possible to define the Network Packet Loss of one monitored
flow, for 1 period): <<In a packet network, the number of lost flow for a single period: <<In a packet network, the number of lost
packets is the number of packets counted by the input nodes minus the packets is the number of packets counted by the input nodes minus the
number of packets counted by the output nodes>>. This is true for number of packets counted by the output nodes>>. This is true for
every packet flow in each marking period. every packet flow in each marking period.
The Monitored Network Packet Loss with n input nodes and m output The Monitored Network Packet Loss with n input nodes and m output
nodes is given by: nodes is given by:
PL = (PI1 + PI2 +...+ PIn) - (PO1 + PO2 +...+ POm) PL = (PI1 + PI2 +...+ PIn) - (PO1 + PO2 +...+ POm)
where: where:
PL is the Network Packet Loss (number of lost packets) PL is the Network Packet Loss (number of lost packets)
PIi is the Number of packets flowed through the i-th Input node in PIi is the Number of packets flowed through the i-th Input node in
this period this period
POj is the Number of packets flowed through the j-th Output node in POj is the Number of packets flowed through the j-th Output node in
this period this period
The equation is applied on a per-time-interval basis. The equation is applied on a per-time-interval basis and on an per-
flow basis:
The reference interval is the alternate marking period as defined
in RFC 8321 [RFC8321].
The flow definition is generalized here, indeed, as described
before, a multipoint packet flow is considered and the
identification fields of the 5-tuple can be selected without any
constraints.
6. Network Clustering 6. Network Clustering
The previous Equation can determine the number of packets lost The previous Equation can determine the number of packets lost
globally in the monitored network, exploiting only the data provided globally in the monitored network, exploiting only the data provided
by the counters in the input and output nodes. by the counters in the input and output nodes.
In addition it is also possible to leverage the data provided by the In addition it is also possible to leverage the data provided by the
other counters in the network to converge on the smallest other counters in the network to converge on the smallest
identifiable subnetworks where the losses occur. These subnetworks identifiable subnetworks where the losses occur. These subnetworks
are named Clusters. are named Clusters.
A Cluster graph is a subnetwork of the entire Monitoring Network A Cluster graph is a subnetwork of the entire Monitoring Network
graph that still satisfies the packet loss equation where PL in this graph that still satisfies the packet loss equation (introduced in
case is the number of packets lost in the Cluster. the previous section) where PL in this case is the number of packets
lost in the Cluster. As for the entire Monitoring Network graph, the
Cluster is defined on a per-flow basis.
For this reason a Cluster should contain all the arcs emanating from For this reason a Cluster should contain all the arcs emanating from
its input nodes and all the arcs terminating at its output nodes. its input nodes and all the arcs terminating at its output nodes.
This ensures that we can count all the packets (and only those) This ensures that we can count all the packets (and only those)
exiting an input node again at the output node, whatever path they exiting an input node again at the output node, whatever path they
follow. follow.
In a completely monitored network (a network where every network In a completely monitored network (a network where every network
interface is monitored), each network device corresponds to a Cluster interface is monitored), each network device corresponds to a Cluster
and each physical link corresponds to two Clusters (one for each and each physical link corresponds to two Clusters (one for each
skipping to change at page 14, line 12 skipping to change at page 14, line 5
Note that the mark switching approach based on a fixed timer is Note that the mark switching approach based on a fixed timer is
considered in this document. considered in this document.
time -> start stop time -> start stop
T(R1) |-------------| T(R1) |-------------|
T(R2) |-------------| T(R2) |-------------|
T(R3) |------------| T(R3) |------------|
Figure 4: Measurement Interval Figure 4: Measurement Interval
T(R1) is the measurement interval and this is essential in order to In the figure it is assumed that the node with the earliest clock
be compatible and make comparison with other active/passive/hybrid (R1) identifies the right starting and ending time of the
Packet Loss metrics. measurement, but it is just an assumption and other possibilities
could occurr. So, in this case, T(R1) is the measurement interval
and its recognition is essential in order to be compatible and make
comparison with other active/passive/hybrid Packet Loss metrics.
That is why, when we expand to multipoint-to-multipoint flows, we Therefore, when we expand to multipoint-to-multipoint flows, we have
have to consider that all source nodes mark the traffic. to consider that all source nodes mark the traffic and this adds more
complexity.
Regarding the timing aspects of the methodology, RFC 8321 [RFC8321] Regarding the timing aspects of the methodology, RFC 8321 [RFC8321]
already describes two contributions that are taken into account: the already describes two contributions that are taken into account: the
clock error between network devices and the network delay between clock error between network devices and the network delay between
measurement points. measurement points.
But we should now consider an additional contribution. Since all But we should now consider an additional contribution. Since all
source nodes mark the traffic, the source measurement intervals can source nodes mark the traffic, the source measurement intervals can
be of different lengths and with different offsets and this mismatch be of different lengths and with different offsets and this mismatch
m can be added to d, as shown in figure. m can be added to d, as shown in figure.
skipping to change at page 14, line 45 skipping to change at page 14, line 42
m d | | d m m d | | d m
|<====================>| |<====================>|
available counting interval available counting interval
Figure 5: Timing Aspects for Multipoint paths Figure 5: Timing Aspects for Multipoint paths
So the misalignment between the marking source routers gives an So the misalignment between the marking source routers gives an
additional constraint and the value of m is added to d (that already additional constraint and the value of m is added to d (that already
includes clock error and network delay). includes clock error and network delay).
Therefore, three different possible constraints are considered: clock Thus, three different possible constraints are considered: clock
error between network devices, network delay between measurement error between network devices, network delay between measurement
points and the misalignment between the marking source routers. points and the misalignment between the marking source routers.
In the end, the condition that must be satisfied to enable the method In the end, the condition that must be satisfied to enable the method
to function properly is that the available counting interval must be to function properly is that the available counting interval must be
> 0, and that means: L - 2m - 2d > 0 for each measurement point on > 0, and that means: L - 2m - 2d > 0 for each measurement point on
the multipoint path. Therefore, the mismatch between measurement the multipoint path. Therefore, the mismatch between measurement
intervals must satisfy this condition. intervals must satisfy this condition.
The timing considerations are valid for both packet loss and delay Note that the timing considerations are valid for both packet loss
measurements. and delay measurements.
8. Multipoint Delay and Delay Variation 8. Multipoint Delay and Delay Variation
The same line of reasoning can be applied to Delay and Delay The same line of reasoning can be applied to Delay and Delay
Variation. Similarly to the delay measurements defined in RFC 8321 Variation. Similarly to the delay measurements defined in RFC 8321
[RFC8321], the marking batches anchor the samples to a particular [RFC8321], the marking batches anchor the samples to a particular
period and this is the time reference that can be used. It is period and this is the time reference that can be used. It is
important to highlight that both delay and delay variation important to highlight that both delay and delay variation
measurements make sense in a multipoint path. The Delay Variation is measurements make sense in a multipoint path. The Delay Variation is
calculated by considering the same packets selected for measuring the calculated by considering the same packets selected for measuring the
 End of changes. 14 change blocks. 
22 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/