draft-ietf-ippm-multipoint-alt-mark-05.txt   draft-ietf-ippm-multipoint-alt-mark-06.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: August 3, 2020 Telecom Italia Expires: August 27, 2020 Telecom Italia
A. Sapio A. Sapio
R. Sisto R. Sisto
Politecnico di Torino Politecnico di Torino
January 31, 2020 February 24, 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-05 draft-ietf-ippm-multipoint-alt-mark-06
Abstract Abstract
The Alternate Marking method, as presented in RFC 8321 [RFC8321], can The Alternate Marking method, as presented in RFC 8321, can be
be applied only to point-to-point flows because it assumes that all applied only to point-to-point flows because it assumes that all the
the packets of the flow measured on one node are measured again by a 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
described is called Multipoint Alternate Marking. Some definitions described is called Multipoint Alternate Marking.
here introduced extend the scope of RFC 5644 [RFC5644] in the context
of alternate marking schema.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 3, 2020.
This Internet-Draft will expire on August 27, 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
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Correlation with RFC5644 . . . . . . . . . . . . . . . . . . 4 2. Correlation with RFC5644 . . . . . . . . . . . . . . . . . . 4
3. Flow classification . . . . . . . . . . . . . . . . . . . . . 5 3. Flow classification . . . . . . . . . . . . . . . . . . . . . 4
4. Multipoint Performance Measurement . . . . . . . . . . . . . 7 4. Multipoint Performance Measurement . . . . . . . . . . . . . 7
4.1. Monitoring Network . . . . . . . . . . . . . . . . . . . 7 4.1. Monitoring Network . . . . . . . . . . . . . . . . . . . 7
5. Multipoint Packet Loss . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . 15 8.2. Delay measurements on single packets basis . . . . . . . 15
skipping to change at page 3, line 7 skipping to change at page 2, line 44
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 . . . . . . . . . . . . . . . . . 20 14.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The alternate marking method, as presented until now, is applicable The alternate marking method, as described in RFC 8321 [RFC8321], is
to a point-to-point path; so the extension proposed in this document applicable to a point-to-point path; so the extension proposed in
explains the most general case of multipoint-to-multipoint path and this document explains the most general case of multipoint-to-
enables flexible and adaptive performance measurements in a managed multipoint path and enables flexible and adaptive performance
network. measurements in a managed network.
The Alternate Marking methodology described in RFC 8321 [RFC8321] has The Alternate Marking methodology described in RFC 8321 [RFC8321] has
the property to synchronize measurements in different points the property to synchronize measurements in different points
maintaining the coherence of the counters. So it is possible to show maintaining the coherence of the counters. So it is possible to show
what is happening in every marking period for each monitored flow. what is happening in every marking period for each monitored flow.
The monitoring parameters are the packet counter and timestamps of a The monitoring parameters are the packet counter and timestamps of a
flow for each marking period. Note that additional details about the flow for each marking period. Note that additional details about the
Alternate Marking methodology are described in the paper applicability of the Alternate Marking methodology are described in
[IEEE-Network-PNPM] the paper [IEEE-Network-PNPM].
There are some applications of the alternate marking method where There are some applications of the alternate marking method where
there are a lot of monitored flows and nodes. Multipoint Alternate there are a lot of monitored flows and nodes. Multipoint Alternate
Marking aims to reduce these values and makes the performance Marking aims to reduce these values and makes the performance
monitoring more flexible in case a detailed analysis is not needed. monitoring more flexible in case a detailed analysis is not needed.
For instance, by considering n measurement points and m monitored For instance, by considering n measurement points and m monitored
flows,the order of magnitude of the packet counters for each time flows,the order of magnitude of the packet counters for each time
interval is n*m*2 (1 per color). If both n and m are high values the interval is n*m*2 (1 per color). If both n and m are high values the
packet counters increase a lot and Multipoint Alternate Marking packet counters increase a lot and Multipoint Alternate Marking
offers a tool to control these parameters. offers a tool to control these parameters.
The approach presented in this document is applied only to unicast The approach presented in this document is applied only to unicast
flows and not to multicast. BUM (Broadcast Unknown Unicast flows and not to multicast. BUM (Broadcast, Unknown-unicast, and
Multicast) traffic is not considered here, because traffic Multicast) traffic is not considered here, because traffic
replication is not covered by the Multipoint Alternate Marking replication is not covered by the Multipoint Alternate Marking
method. Furthermore it can be applicable to anycast flows and ECMP method. Furthermore it can be applicable to anycast flows and ECMP
(Equal-Cost Multi-Path) paths can also be easily monitored with this (Equal-Cost Multi-Path) paths can also be easily monitored with this
technique. technique.
In short, RFC 8321 [RFC8321] applies to point-to-point unicast flows In short, RFC 8321 [RFC8321] applies to point-to-point unicast flows
and BUM traffic and the Multipoint alternate marking and its and BUM traffic and the Multipoint alternate marking and its
Clustering approach is valid for multipoint-to-multipoint unicast Clustering approach is valid for multipoint-to-multipoint unicast
flows, anycast and ECMP flows. flows, anycast and ECMP flows.
skipping to change at page 16, line 18 skipping to change at page 16, line 18
Double marking or multiplexed marking would work, but each Double marking or multiplexed marking would work, but each
measurement would only give information about the delay of a measurement would only give information about the delay of a
single path. However, by repeating the measurement multiple single path. However, by repeating the measurement multiple
times, it is possible to get information about all the paths in times, it is possible to get information about all the paths in
the multipoint flow. This can be done in case of point-to- the multipoint flow. This can be done in case of point-to-
multipoint path but it is more difficult to achieve in case of multipoint path but it is more difficult to achieve in case of
multipoint-to-multipoint path because of the multiple source multipoint-to-multipoint path because of the multiple source
routers. routers.
if we would perform a delay measurement for more than one picked If we would perform a delay measurement for more than one picked
packet in the same marking period and, especially, if we want to get packet in the same marking period and, especially, if we want to get
delay measurements on multipoint-to-multipoint basis, both single and delay measurements on multipoint-to-multipoint basis, both single and
double marking method are not useful in the Multipoint scenario, double marking method are not useful in the Multipoint scenario,
since they would not be representative of the entire flow. The since they would not be representative of the entire flow. The
packets can follow different paths with various delays and in general packets can follow different paths with various delays and in general
it can be very difficult to recognize marked packets in a multipoint- it can be very difficult to recognize marked packets in a multipoint-
to-multipoint path especially in case they are more than one per to-multipoint path especially in case they are more than one per
period. period.
A desirable option is to monitor simultaneously all the paths of a A desirable option is to monitor simultaneously all the paths of a
skipping to change at page 17, line 16 skipping to change at page 17, line 16
allowing to anchor the selected samples to their period. Moreover in allowing to anchor the selected samples to their period. Moreover in
the dynamic hash-based sampling, by dynamically adapting the length the dynamic hash-based sampling, by dynamically adapting the length
of the hash value, the number of samples is bounded in each marking of the hash value, the number of samples is bounded in each marking
period. This can be realized by choosing the maximum number of period. This can be realized by choosing the maximum number of
samples (NMAX) to be caught in a marking period. The algorithm samples (NMAX) to be caught in a marking period. The algorithm
starts with only few hash bits, that permit to select a greater starts with only few hash bits, that permit to select a greater
percentage of packets (e.g. with 0 bit of hash all the packets are percentage of packets (e.g. with 0 bit of hash all the packets are
sampled, with 1 bit of hash half of the packets are sampled, and so sampled, with 1 bit of hash half of the packets are sampled, and so
on). When the number of selected packets reaches NMAX, a hashing bit on). When the number of selected packets reaches NMAX, a hashing bit
is added. As a consequence, the sampling proceeds at half of the is added. As a consequence, the sampling proceeds at half of the
original rate and also the packets already selected that don't match original rate and also the packets already selected that do not match
the new hash are discarded. This step can be repeated iteratively. the new hash are discarded. This step can be repeated iteratively.
It is assumed that each sample includes the timestamp (used for delay It is assumed that each sample includes the timestamp (used for delay
measurement) and the hash value, allowing the management system to measurement) and the hash value, allowing the management system to
match the samples received from the two measurement points. The match the samples received from the two measurement points. The
dynamic process statistically converges at the end of a marking dynamic process statistically converges at the end of a marking
period and the final number of selected samples is between NMAX/2 and period and the final number of selected samples is between NMAX/2 and
NMAX. Therefore, the dynamic approach paces the sampling rate, NMAX. Therefore, the dynamic approach paces the sampling rate,
allowing to bound the number of sampled packets per sampling period. allowing to bound the number of sampled packets per sampling period.
In a multipoint environment the behaviour is similar to point-to In a multipoint environment the behaviour is similar to point-to
skipping to change at page 18, line 14 skipping to change at page 18, line 14
path, where we cannot couple the picked packets in a multipoint path, where we cannot couple the picked packets in a multipoint
paths. So, in general, if we want to get delay measurements on paths. So, in general, if we want to get delay measurements on
multipoint-to-multipoint path basis and want to select more than one multipoint-to-multipoint path basis and want to select more than one
packet per period, double marking cannot be used because we could not packet per period, double marking cannot be used because we could not
be able to couple the picked packets between input and output nodes. be able to couple the picked packets between input and output nodes.
On the other hand we can do that by using hashing selection. On the other hand we can do that by using hashing selection.
9. An Intelligent Performance Management approach 9. An Intelligent Performance Management approach
The Multipoint Alternate Marking framework that is introduced in this The Multipoint Alternate Marking framework that is introduced in this
document adds flexibility to PM because it can reduce the order of document adds flexibility to Performance Management (PM) because it
magnitude of the packet counters. This allows an SDN Orchestrator to can reduce the order of magnitude of the packet counters. This
supervise, control and manage PM in large networks. allows an SDN Orchestrator to supervise, control and manage PM in
large networks.
The monitoring network can be considered as a whole or can be split The monitoring network can be considered as a whole or can be split
in Clusters, that are the smallest subnetworks (group-to-group in Clusters, that are the smallest subnetworks (group-to-group
segments), maintaining the packet loss property for each subnetwork. segments), maintaining the packet loss property for each subnetwork.
They can also be combined in new connected subnetworks at different They can also be combined in new connected subnetworks at different
levels depending on the detail we want to achieve. levels depending on the detail we want to achieve.
An SDN Controller can calibrate Performance Measurements since it is An SDN Controller can calibrate Performance Measurements since it is
aware of the network topology. It can start without examining in aware of the network topology. It can start without examining in
depth. In case of necessity (packet loss is measured or the delay is depth. In case of necessity (packet loss is measured or the delay is
skipping to change at page 20, line 28 skipping to change at page 20, line 29
for the precious contribution. for the precious contribution.
13. IANA Considerations 13. IANA Considerations
This memo makes no requests of IANA. 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
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance
Metrics (IPPM): Spatial and Multicast", RFC 5644, Metrics (IPPM): Spatial and Multicast", RFC 5644,
DOI 10.17487/RFC5644, October 2009, DOI 10.17487/RFC5644, October 2009,
<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>.
 End of changes. 15 change blocks. 
36 lines changed or deleted 25 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/