--- 1/draft-ietf-ippm-multipoint-alt-mark-05.txt 2020-02-24 09:13:47.580419885 -0800 +++ 2/draft-ietf-ippm-multipoint-alt-mark-06.txt 2020-02-24 09:13:47.624420999 -0800 @@ -1,79 +1,72 @@ IPPM Working Group G. Fioccola, Ed. Internet-Draft Huawei Technologies Intended status: Experimental M. Cociglio -Expires: August 3, 2020 Telecom Italia +Expires: August 27, 2020 Telecom Italia A. Sapio R. Sisto Politecnico di Torino - January 31, 2020 + February 24, 2020 Multipoint Alternate Marking method for passive and hybrid performance monitoring - draft-ietf-ippm-multipoint-alt-mark-05 + draft-ietf-ippm-multipoint-alt-mark-06 Abstract - The Alternate Marking method, as presented in RFC 8321 [RFC8321], can - 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 Alternate Marking method, as presented in RFC 8321, can 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 single second node. This document aims to generalize and expand this methodology to measure any kind of unicast flows, whose packets can follow several different paths in the network, in wider terms a multipoint-to-multipoint network. For this reason the technique here - described is called Multipoint Alternate Marking. Some definitions - 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]. + described is called Multipoint Alternate Marking. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Correlation with RFC5644 . . . . . . . . . . . . . . . . . . 4 - 3. Flow classification . . . . . . . . . . . . . . . . . . . . . 5 + 3. Flow classification . . . . . . . . . . . . . . . . . . . . . 4 4. Multipoint Performance Measurement . . . . . . . . . . . . . 7 4.1. Monitoring Network . . . . . . . . . . . . . . . . . . . 7 5. Multipoint Packet Loss . . . . . . . . . . . . . . . . . . . 8 6. Network Clustering . . . . . . . . . . . . . . . . . . . . . 9 6.1. Algorithm for Cluster partition . . . . . . . . . . . . . 10 7. Timing Aspects . . . . . . . . . . . . . . . . . . . . . . . 13 8. Multipoint Delay and Delay Variation . . . . . . . . . . . . 15 8.1. Delay measurements on multipoint paths basis . . . . . . 15 8.1.1. Single Marking measurement . . . . . . . . . . . . . 15 8.2. Delay measurements on single packets basis . . . . . . . 15 @@ -84,47 +77,47 @@ 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 14.1. Normative References . . . . . . . . . . . . . . . . . . 20 14.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction - The alternate marking method, as presented until now, is applicable - to a point-to-point path; so the extension proposed in this document - explains the most general case of multipoint-to-multipoint path and - enables flexible and adaptive performance measurements in a managed - network. + The alternate marking method, as described in RFC 8321 [RFC8321], is + applicable to a point-to-point path; so the extension proposed in + this document explains the most general case of multipoint-to- + multipoint path and enables flexible and adaptive performance + measurements in a managed network. The Alternate Marking methodology described in RFC 8321 [RFC8321] has the property to synchronize measurements in different points maintaining the coherence of the counters. So it is possible to show what is happening in every marking period for each monitored flow. The monitoring parameters are the packet counter and timestamps of a flow for each marking period. Note that additional details about the - Alternate Marking methodology are described in the paper - [IEEE-Network-PNPM] + applicability of the Alternate Marking methodology are described in + the paper [IEEE-Network-PNPM]. There are some applications of the alternate marking method where there are a lot of monitored flows and nodes. Multipoint Alternate Marking aims to reduce these values and makes the performance monitoring more flexible in case a detailed analysis is not needed. For instance, by considering n measurement points and m monitored 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 packet counters increase a lot and Multipoint Alternate Marking offers a tool to control these parameters. 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 replication is not covered by the Multipoint Alternate Marking method. Furthermore it can be applicable to anycast flows and ECMP (Equal-Cost Multi-Path) paths can also be easily monitored with this technique. In short, RFC 8321 [RFC8321] applies to point-to-point unicast flows and BUM traffic and the Multipoint alternate marking and its Clustering approach is valid for multipoint-to-multipoint unicast flows, anycast and ECMP flows. @@ -702,21 +695,21 @@ Double marking or multiplexed marking would work, but each measurement would only give information about the delay of a single path. However, by repeating the measurement multiple times, it is possible to get information about all the paths in 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-to-multipoint path because of the multiple source 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 delay measurements on multipoint-to-multipoint basis, both single and double marking method are not useful in the Multipoint scenario, since they would not be representative of the entire flow. The packets can follow different paths with various delays and in general it can be very difficult to recognize marked packets in a multipoint- to-multipoint path especially in case they are more than one per period. A desirable option is to monitor simultaneously all the paths of a @@ -749,21 +742,21 @@ allowing to anchor the selected samples to their period. Moreover in the dynamic hash-based sampling, by dynamically adapting the length of the hash value, the number of samples is bounded in each marking period. This can be realized by choosing the maximum number of samples (NMAX) to be caught in a marking period. The algorithm 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 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 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. It is assumed that each sample includes the timestamp (used for delay measurement) and the hash value, allowing the management system to match the samples received from the two measurement points. The dynamic process statistically converges at the end of a marking period and the final number of selected samples is between NMAX/2 and NMAX. Therefore, the dynamic approach paces the sampling rate, allowing to bound the number of sampled packets per sampling period. In a multipoint environment the behaviour is similar to point-to @@ -795,23 +788,24 @@ path, where we cannot couple the picked packets in a multipoint paths. So, in general, if we want to get delay measurements on multipoint-to-multipoint path basis and want to select more than one packet per period, double marking cannot be used because we could not be able to couple the picked packets between input and output nodes. On the other hand we can do that by using hashing selection. 9. An Intelligent Performance Management approach The Multipoint Alternate Marking framework that is introduced in this - document adds flexibility to PM because it can reduce the order of - magnitude of the packet counters. This allows an SDN Orchestrator to - supervise, control and manage PM in large networks. + document adds flexibility to Performance Management (PM) because it + can reduce the order of magnitude of the packet counters. This + 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 in Clusters, that are the smallest subnetworks (group-to-group segments), maintaining the packet loss property for each subnetwork. They can also be combined in new connected subnetworks at different levels depending on the detail we want to achieve. An SDN Controller can calibrate Performance Measurements since it is aware of the network topology. It can start without examining in depth. In case of necessity (packet loss is measured or the delay is @@ -905,25 +898,20 @@ for the precious contribution. 13. IANA Considerations This memo makes no requests of IANA. 14. 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, - . - [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance Metrics (IPPM): Spatial and Multicast", RFC 5644, DOI 10.17487/RFC5644, October 2009, . [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, "Alternate-Marking Method for Passive and Hybrid Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, January 2018, .