draft-ietf-ippm-multipoint-alt-mark-03.txt   draft-ietf-ippm-multipoint-alt-mark-04.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: May 7, 2020 Telecom Italia Expires: July 10, 2020 Telecom Italia
A. Sapio A. Sapio
R. Sisto R. Sisto
Politecnico di Torino Politecnico di Torino
November 4, 2019 January 7, 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-03 draft-ietf-ippm-multipoint-alt-mark-04
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 May 7, 2020. This Internet-Draft will expire on July 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 32 skipping to change at page 2, line 32
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 . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . 14 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 . . . . . . . 15 8.2. Delay measurements on single packets basis . . . . . . . 16
8.2.1. Single and Double Marking measurement . . . . . . . . 15 8.2.1. Single and Double Marking measurement . . . . . . . . 16
8.2.2. Hashing selection method . . . . . . . . . . . . . . 16 8.2.2. Hashing selection method . . . . . . . . . . . . . . 16
9. An Intelligent Performance Management approach . . . . . . . 17 9. An Intelligent Performance Management approach . . . . . . . 18
10. Examples of application . . . . . . . . . . . . . . . . . . . 18 10. Examples of application . . . . . . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Normative References . . . . . . . . . . . . . . . . . . 20 14.1. Normative References . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . 20 14.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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 6, line 43 skipping to change at page 6, line 43
+------+ +------+
multipoint-to-point multipoint-to-point
+------+ +------+
---<> R1 <> ---<> R1 <>
+------+ \ +------+ \
\ +------+ \ +------+
<> R4 <> <> R4 <>
/ +------+ \ / +------+ \
+------+ / \ +------+ +------+ / \ +------+
---<> R2 <> <> R4 <>--- ---<> R2 <> <> R6 <>---
+------+ / +------+ +------+ / +------+
+------+ / +------+ /
<> R5 <> <> R5 <>
/ +------+ / +------+
+------+ / +------+ /
---<> R3 <> ---<> R3 <>
+------+ +------+
multipoint-to-multipoint multipoint-to-multipoint
+------+ +------+ +------+ +------+
skipping to change at page 7, line 28 skipping to change at page 7, line 28
+------+ / \ +------+ +------+ / \ +------+
---<> R3 <> <> R8 <>--- ---<> R3 <> <> R8 <>---
+------+ +------+ +------+ +------+
Figure 1: Flow classification Figure 1: Flow classification
The case of unicast flow is considered in the previous figure. The case of unicast flow is considered in the previous figure.
Anyway the anycast flow is also in scope because there is no Anyway the anycast flow is also in scope because there is no
replication and only a single node from the anycast group receives replication and only a single node from the anycast group receives
the traffic, so it can be viewed as a special case of unicast flow. the traffic, so it can be viewed as a special case of unicast flow.
While ECMP flow is in scope by definition, since it is a point-to- Furthermore, an ECMP flow is in scope by definition, since it is a
multipoint unicast flow. point-to-multipoint unicast flow.
4. Multipoint Performance Measurement 4. Multipoint Performance Measurement
By Using the "traditional" alternate marking method only point-to- By Using the "traditional" alternate marking method only point-to-
point paths can be monitored. To have an IP (TCP/UDP) flow that point paths can be monitored. To have an IP (TCP/UDP) flow that
follows a point-to-point path we have to define, with a specific follows a point-to-point path we have to define, with a specific
value, 5 identification fields (IP Source, IP Destination, Transport value, 5 identification fields (IP Source, IP Destination, Transport
Protocol, Source Port, Destination Port). Protocol, Source Port, Destination Port).
Multipoint Alternate Marking enables the performance measurement for Multipoint Alternate Marking enables the performance measurement for
skipping to change at page 8, line 5 skipping to change at page 8, line 5
4.1. Monitoring Network 4.1. Monitoring Network
The Monitoring Network is deduced from the Production Network, by The Monitoring Network is deduced from the Production Network, by
identifying the nodes of the graph that are the measurement points, identifying the nodes of the graph that are the measurement points,
and the links that are the connections between measurement points. and the links that are the connections between measurement points.
There are some techniques that can help with the building of the There are some techniques that can help with the building of the
monitoring network (as an example it is possible to mention monitoring network (as an example it is possible to mention
[I-D.amf-ippm-route]). In general there are different options: the [I-D.ietf-ippm-route]). In general there are different options: the
monitoring network can be obtained by considering all the possible monitoring network can be obtained by considering all the possible
paths for the traffic or also by checking the traffic sometimes and paths for the traffic or also by checking the traffic sometimes and
update the graph consequently. update the graph consequently.
So a graph model of the monitoring network can be built according to So a graph model of the monitoring network can be built according to
the alternate marking method: the monitored interfaces and links are the alternate marking method: the monitored interfaces and links are
identified. Only the measurement points and links where the traffic identified. Only the measurement points and links where the traffic
has flowed have to be represented in the graph. has flowed have to be represented in the graph.
The following figure shows a simple example of a Monitoring Network The following figure shows a simple example of a Monitoring Network
skipping to change at page 9, line 15 skipping to change at page 9, line 15
5. Multipoint Packet Loss 5. Multipoint Packet Loss
Since all the packets of the considered flow leaving the network have Since all the packets of the considered flow leaving the network have
previously entered the network, the number of packets counted by all previously entered the network, the number of packets counted by all
the input nodes is always greater or equal than the number of packets the input nodes is always greater or equal than the number of packets
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 and on all the egress interfaces is the same. In ingress interfaces equals the number on egress interfaces for the
this circumstance, if no packet loss occurs, the intermediate monitored flow. In this circumstance, if no packet loss occurs, the
measurement points have only the task to split the measurement. intermediate measurement points have only the task to split the
measurement.
It is possible to define the Network Packet Loss (for 1 flow, for 1 It is possible to define the Network Packet Loss (for 1 monitored
period): <<In a packet network, the number of lost packets is the flow, for 1 period): <<In a packet network, the number of lost
number of packets counted by the input nodes minus the number of packets is the number of packets counted by the input nodes minus the
packets counted by the output nodes>>. This is true for every packet number of packets counted by the output nodes>>. This is true for
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)
skipping to change at page 10, line 40 skipping to change at page 10, line 40
6.1. Algorithm for Cluster partition 6.1. Algorithm for Cluster partition
A simple algorithm can be applied in order to split our monitoring A simple algorithm can be applied in order to split our monitoring
network into Clusters. It is a two-step algorithm: network into Clusters. It is a two-step algorithm:
o Group the links where there is the same starting node; o Group the links where there is the same starting node;
o Join the grouped links with at least one ending node in common. o Join the grouped links with at least one ending node in common.
After the application of the previous two steps, each one of the
composed sets of links together with the endpoint nodes constitutes a
Cluster.
In our monitoring network graph example it is possible to identify In our monitoring network graph example it is possible to identify
the Clusters partition by applying this two-step algorithm. the Clusters partition by applying this two-step algorithm.
The first step identifies the following groups: The first step identifies the following groups:
1. Group 1: (R1-R2), (R1-R3), (R1-R10) 1. Group 1: (R1-R2), (R1-R3), (R1-R10)
2. Group 2: (R2-R4), (R2-R5) 2. Group 2: (R2-R4), (R2-R5)
3. Group 3: (R3-R5), (R3-R9) 3. Group 3: (R3-R5), (R3-R9)
4. Group 4: (R4-R6), (R4-R7) 4. Group 4: (R4-R6), (R4-R7)
5. Group 5: (R5-R8) 5. Group 5: (R5-R8)
And then, the second step builds the Clusters partition (in And then, the second step builds the Clusters partition (in
particular we can underline that Group 2 and Group 3 connect particular we can underline that Group 2 and Group 3 connect
together, since R5 is in common): together, since R5 is in common):
1. Cluster 1: (R1-R2), (R1-R3), (R1-R10) 1. Cluster 1: (R1-R2), (R1-R3), (R1-R10)
2. Cluster 2: (R2-R4), (R2-R5), (R3-R5), (R3-R9) 2. Cluster 2: (R2-R4), (R2-R5), (R3-R5), (R3-R9)
skipping to change at page 13, line 5 skipping to change at page 13, line 20
Obviously, by combining some Clusters in a new connected subnetwork Obviously, by combining some Clusters in a new connected subnetwork
(called Super Cluster) the Packet Loss Rule is still true. (called Super Cluster) the Packet Loss Rule is still true.
In this way in a very large network there is no need to configure In this way in a very large network there is no need to configure
detailed filter criteria to inspect the traffic. You can check detailed filter criteria to inspect the traffic. You can check
multipoint network and only in case of problems you can go deep with multipoint network and only in case of problems you can go deep with
a step-by-step cluster analysis, but only for the cluster or a step-by-step cluster analysis, but only for the cluster or
combination of clusters where the problem happens. combination of clusters where the problem happens.
The algorithm described above is an Iterative clustering algorithm,
but it is also possible to apply a Recursive clustering algorithm by
using the node-node adjacency matrix representation.
The complete and mathematical analysis of the possible Algorithms for The complete and mathematical analysis of the possible Algorithms for
Cluster partition, including the considerations in terms of Cluster partition, including the considerations in terms of
efficiency and a comparison between the different methods, is in the efficiency and a comparison between the different methods, is in the
paper [IEEE-ACM-ToN-MPNPM]. paper [IEEE-ACM-ToN-MPNPM].
7. Timing Aspects 7. Timing Aspects
It is important to consider the timing aspects, since out of order It is important to consider the timing aspects, since out of order
packets happen and have to be handled as well as described in RFC packets happen and have to be handled as well as described in RFC
8321 [RFC8321]. But, in a multi-source situation an additional issue 8321 [RFC8321]. But, in a multi-source situation an additional issue
skipping to change at page 19, line 48 skipping to change at page 20, line 30
the Internet. However, implementation of this method must be mindful the Internet. However, implementation of this method must be mindful
of security and privacy concerns, as explained in RFC 8321 [RFC8321]. of security and privacy concerns, as explained in RFC 8321 [RFC8321].
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Al Morton, Tal Mizrahi, Rachel Huang The authors would like to thank Al Morton, Tal Mizrahi, Rachel Huang
for the precious contribution. for the precious contribution.
13. IANA Considerations 13. IANA Considerations
tbc This memo makes no requests of IANA.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 20, line 27 skipping to change at page 21, line 7
<https://www.rfc-editor.org/info/rfc5644>. <https://www.rfc-editor.org/info/rfc5644>.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid "Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>. January 2018, <https://www.rfc-editor.org/info/rfc8321>.
14.2. Informative References 14.2. Informative References
[I-D.amf-ippm-route] [I-D.ietf-ippm-route]
Alvarez-Hamelin, J., Morton, A., and J. Fabini, "Advanced Alvarez-Hamelin, J., Morton, A., Fabini, J., Pignataro,
Unidirectional Route Assessment", draft-amf-ippm-route-01 C., and R. Geib, "Advanced Unidirectional Route Assessment
(work in progress), October 2017. (AURA)", draft-ietf-ippm-route-07 (work in progress),
December 2019.
[I-D.mizrahi-ippm-compact-alternate-marking] [I-D.mizrahi-ippm-compact-alternate-marking]
Mizrahi, T., Arad, C., Fioccola, G., Cociglio, M., Chen, Mizrahi, T., Arad, C., Fioccola, G., Cociglio, M., Chen,
M., Zheng, L., and G. Mirsky, "Compact Alternate Marking M., Zheng, L., and G. Mirsky, "Compact Alternate Marking
Methods for Passive and Hybrid Performance Monitoring", Methods for Passive and Hybrid Performance Monitoring",
draft-mizrahi-ippm-compact-alternate-marking-05 (work in draft-mizrahi-ippm-compact-alternate-marking-05 (work in
progress), July 2019. progress), July 2019.
[I-D.song-opsawg-ifit-framework] [I-D.song-opsawg-ifit-framework]
Song, H., Li, Z., Zhou, T., Qin, F., Chen, H., Jin, J., Song, H., Qin, F., Chen, H., Jin, J., and J. Shin, "In-
and J. Shin, "In-situ Flow Information Telemetry", draft- situ Flow Information Telemetry", draft-song-opsawg-ifit-
song-opsawg-ifit-framework-06 (work in progress), October framework-10 (work in progress), December 2019.
2019.
[I-D.zhou-ippm-enhanced-alternate-marking] [I-D.zhou-ippm-enhanced-alternate-marking]
Zhou, T., Fioccola, G., Li, Z., Lee, S., and M. Cociglio, Zhou, T., Fioccola, G., Li, Z., Lee, S., and M. Cociglio,
"Enhanced Alternate Marking Method", draft-zhou-ippm- "Enhanced Alternate Marking Method", draft-zhou-ippm-
enhanced-alternate-marking-04 (work in progress), October enhanced-alternate-marking-04 (work in progress), October
2019. 2019.
[IEEE-ACM-ToN-MPNPM] [IEEE-ACM-ToN-MPNPM]
IEEE/ACM TRANSACTION ON NETWORKING, "Multipoint Passive IEEE/ACM TRANSACTION ON NETWORKING, "Multipoint Passive
Monitoring in Packet Networks", DOI to appear, 2019. Monitoring in Packet Networks",
DOI 10.1109/TNET.2019.2950157, 2019.
[IEEE-Network-PNPM] [IEEE-Network-PNPM]
IEEE Network, "AM-PM: Efficient Network Telemetry using IEEE Network, "AM-PM: Efficient Network Telemetry using
Alternate Marking", DOI 10.1109/MNET.2019.1800152, 2019. Alternate Marking", DOI 10.1109/MNET.2019.1800152, 2019.
[RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A.,
Grossglauser, M., and J. Rexford, "A Framework for Packet Grossglauser, M., and J. Rexford, "A Framework for Packet
Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474, Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474,
March 2009, <https://www.rfc-editor.org/info/rfc5474>. March 2009, <https://www.rfc-editor.org/info/rfc5474>.
 End of changes. 22 change blocks. 
38 lines changed or deleted 48 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/