| rfc9342.original | rfc9342.txt | |||
|---|---|---|---|---|
| Network Working Group G. Fioccola, Ed. | Internet Engineering Task Force (IETF) G. Fioccola, Ed. | |||
| Internet-Draft Huawei Technologies | Request for Comments: 9342 Huawei Technologies | |||
| Obsoletes: 8889 (if approved) M. Cociglio | Obsoletes: 8889 M. Cociglio | |||
| Intended status: Standards Track Telecom Italia | Category: Standards Track Telecom Italia | |||
| Expires: 30 March 2023 A. Sapio | ISSN: 2070-1721 A. Sapio | |||
| Intel Corporation | Intel Corporation | |||
| R. Sisto | R. Sisto | |||
| Politecnico di Torino | Politecnico di Torino | |||
| T. Zhou | T. Zhou | |||
| Huawei Technologies | Huawei Technologies | |||
| 26 September 2022 | December 2022 | |||
| Clustered Alternate-Marking Method | Clustered Alternate-Marking Method | |||
| draft-ietf-ippm-rfc8889bis-04 | ||||
| Abstract | Abstract | |||
| This document generalizes and expands Alternate-Marking methodology | This document generalizes and expands the Alternate-Marking | |||
| to measure any kind of unicast flow whose packets can follow several | methodology to measure any kind of unicast flow whose packets can | |||
| different paths in the network that can result in a multipoint-to- | follow several different paths in the network; this can result in a | |||
| multipoint network. The network clustering approach is presented | multipoint-to-multipoint network. The network clustering approach is | |||
| and, for this reason, the technique here described is called | presented and, for this reason, the technique described here is | |||
| "Clustered Alternate-Marking". This document obsoletes RFC 8889. | called "Clustered Alternate Marking". This document obsoletes RFC | |||
| 8889. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||
| 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 | This document is a product of the Internet Engineering Task Force | |||
| and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
| time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
| material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
| Internet Standards is available in Section 2 of RFC 7841. | ||||
| This Internet-Draft will expire on 30 March 2023. | Information about the current status of this document, any errata, | |||
| and how to provide feedback on it may be obtained at | ||||
| https://www.rfc-editor.org/info/rfc9342. | ||||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
| license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
| and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
| extracted from this document must include Revised BSD License text as | to this document. Code Components extracted from this document must | |||
| described in Section 4.e of the Trust Legal Provisions and are | include Revised BSD License text as described in Section 4.e of the | |||
| provided without warranty as described in the Revised BSD License. | Trust Legal Provisions and are provided without warranty as described | |||
| in the Revised BSD License. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction | |||
| 1.1. Summary of Changes from RFC 8889 . . . . . . . . . . . . 4 | 1.1. Summary of Changes from RFC 8889 | |||
| 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 | 1.2. Requirements Language | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Terminology | |||
| 2.1. Correlation with RFC 5644 . . . . . . . . . . . . . . . . 6 | 2.1. Correlation with RFC 5644 | |||
| 3. Flow Classification . . . . . . . . . . . . . . . . . . . . . 6 | 3. Flow Classification | |||
| 4. Extension of the Method to Multipoint Flows . . . . . . . . . 9 | 4. Extension of the Method to Multipoint Flows | |||
| 4.1. Monitoring Network . . . . . . . . . . . . . . . . . . . 9 | 4.1. Monitoring Network | |||
| 4.2. Network Packet Loss . . . . . . . . . . . . . . . . . . . 10 | 4.2. Network Packet Loss | |||
| 5. Network Clustering . . . . . . . . . . . . . . . . . . . . . 11 | 5. Network Clustering | |||
| 5.1. Algorithm for Clusters Partition . . . . . . . . . . . . 12 | 5.1. Algorithm for Clusters Partition | |||
| 6. Multipoint Packet Loss Measurement . . . . . . . . . . . . . 14 | 6. Multipoint Packet-Loss Measurement | |||
| 7. Multipoint Delay and Delay Variation . . . . . . . . . . . . 14 | 7. Multipoint Delay and Delay Variation | |||
| 7.1. Delay Measurements on a Multipoint-Paths Basis . . . . . 15 | 7.1. Delay Measurements on a Multipoint-Paths Basis | |||
| 7.1.1. Single-Marking Measurement . . . . . . . . . . . . . 15 | 7.1.1. Single-Marking Measurement | |||
| 7.2. Delay Measurements on a Single-Packet Basis . . . . . . . 15 | 7.2. Delay Measurements on a Single-Packet Basis | |||
| 7.2.1. Single- and Double-Marking Measurement . . . . . . . 15 | 7.2.1. Single- and Double-Marking Measurement | |||
| 7.2.2. Hashing Selection Method . . . . . . . . . . . . . . 16 | 7.2.2. Hashing Selection Method | |||
| 8. Synchronization and Timing . . . . . . . . . . . . . . . . . 17 | 8. Synchronization and Timing | |||
| 9. Recommendations for Deployment . . . . . . . . . . . . . . . 19 | 9. Recommendations for Deployment | |||
| 10. A Closed-Loop Performance-Management Approach . . . . . . . . 21 | 10. A Closed-Loop Performance-Management Approach | |||
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 | 11. Security Considerations | |||
| 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 | 12. IANA Considerations | |||
| 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 | 13. References | |||
| 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 | 13.1. Normative References | |||
| 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 | 13.2. Informative References | |||
| 15.1. Normative References . . . . . . . . . . . . . . . . . . 23 | Appendix A. Example of Monitoring Network and Clusters Partition | |||
| 15.2. Informative References . . . . . . . . . . . . . . . . . 23 | Acknowledgements | |||
| Appendix A. Example of Monitoring Network and Clusters | Contributors | |||
| Partition . . . . . . . . . . . . . . . . . . . . . . . . 24 | Authors' Addresses | |||
| Appendix B. Changes Log . . . . . . . . . . . . . . . . . . . . 27 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 | ||||
| 1. Introduction | 1. Introduction | |||
| The Alternate-Marking Method, as described in | The Alternate-Marking Method, as described in [RFC9341], is | |||
| [I-D.ietf-ippm-rfc8321bis], is applicable to a point-to-point path. | applicable to a point-to-point path. The extension proposed in this | |||
| The extension proposed in this document applies to the most general | document applies to the most general case of a multipoint-to- | |||
| case of a multipoint-to-multipoint path and enables flexible and | multipoint path and enables flexible and adaptive performance | |||
| adaptive performance measurements in a managed network. | measurements in a managed network. | |||
| The Alternate-Marking methodology consists in splitting the packet | The Alternate-Marking methodology consists of splitting the packet | |||
| flow into marking blocks and the monitoring parameters are the packet | flow into marking blocks, and the monitoring parameters are the | |||
| counters and the timestamps for each marking period. In some | packet counters and the timestamps for each marking period. In some | |||
| applications of the Alternate-Marking method, a lot of flows and | applications of the Alternate-Marking Method, a lot of flows and | |||
| nodes are to be monitored. Multipoint Alternate-Marking aims to | nodes are to be monitored. Multipoint Alternate Marking aims to | |||
| reduce these values and makes the performance monitoring more | reduce these values and makes the performance monitoring more | |||
| flexible in case a detailed analysis is not needed. For instance, by | flexible in case a detailed analysis is not needed. For instance, by | |||
| considering n measurement points and m monitored flows, the order of | 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 | magnitude of the packet counters for each time interval is n*m*2 (1 | |||
| per color). The number of measurement points and monitored flows may | per color). The number of measurement points and monitored flows may | |||
| vary and depends on the portion of the network we are monitoring | vary and depends on the portion of the network we are monitoring | |||
| (core network, metro network, access network) and the granularity | (core network, metro network, access network, etc.) and the | |||
| (for each service, each customer). So if both n and m are high | granularity (for each service, each customer, etc.). So if both n | |||
| values, the packet counters increase a lot, and Multipoint Alternate- | and m are high values, the packet counters increase a lot, and | |||
| Marking offers a tool to control these parameters. | Multipoint Alternate Marking 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. Broadcast, Unknown Unicast, and | flows and not to multicast. Broadcast, Unknown Unicast, and | |||
| Multicast (BUM) traffic is not considered here, because traffic | Multicast (BUM) 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 | Method. Furthermore, it can be applicable to anycast flows, and | |||
| Equal-Cost Multipath (ECMP) paths can also be easily monitored with | Equal-Cost Multipath (ECMP) paths can also be easily monitored with | |||
| this technique. | this technique. | |||
| [I-D.ietf-ippm-rfc8321bis] applies to point-to-point unicast flows | [RFC9341] applies to point-to-point unicast flows and BUM traffic. | |||
| and BUM traffic. For BUM traffic, the basic method of | For BUM traffic, the basic method of [RFC9341] can be easily applied | |||
| [I-D.ietf-ippm-rfc8321bis] can easily be applied link by link and | link by link; therefore, the multicast flow tree distribution can be | |||
| therefore split the multicast flow tree distribution into separate | split into separate unicast point-to-point links. | |||
| unicast point-to-point links. While, this document and its Clustered | ||||
| Alternate-Marking method apply to multipoint-to-multipoint unicast | ||||
| flows, anycast, and ECMP flows. | ||||
| Therefore, the Alternate-Marking method can be extended to any kind | This document and its Clustered Alternate-Marking Method applies to | |||
| multipoint-to-multipoint unicast flows, anycast, and ECMP flows. | ||||
| Therefore, the Alternate-Marking Method can be extended to any kind | ||||
| of multipoint-to-multipoint paths, and the network-clustering | of multipoint-to-multipoint paths, and the network-clustering | |||
| approach presented in this document is the formalization of how to | approach presented in this document is the formalization of how to | |||
| implement this property and allow a flexible and optimized | implement this property and allow a flexible and optimized | |||
| performance measurement support for network management in every | performance measurement support for network management in every | |||
| situation. | situation. | |||
| Without network clustering, it is possible to apply Alternate-Marking | Without network clustering, it is possible to apply Alternate Marking | |||
| only for all the network or per single flow. Instead, with network | only for all the network or per single flow. Instead, with network | |||
| clustering, it is possible to use the partition of the network into | clustering, it is possible to partition the network into clusters at | |||
| clusters at different levels in order to provide the needed degree of | different levels in order to provide the needed degree of detail. In | |||
| detail. In some circumstances, it is possible to monitor a | some circumstances, it is possible to monitor a multipoint network by | |||
| multipoint network by monitoring the network clusters, without | monitoring the network clusters, without examining in depth. In case | |||
| examining in depth. In case of problems (packet loss is measured, or | of problems (packet loss is measured or the delay is too high), the | |||
| the delay is too high), the filtering criteria could be enhanced in | filtering criteria could be enhanced in order to perform a detailed | |||
| order to perform a detailed analysis by using a different combination | analysis by using a different combination of clusters up to a per- | |||
| of clusters up to a per-flow measurement as described in | flow measurement as described in [RFC9341]. | |||
| [I-D.ietf-ippm-rfc8321bis]. | ||||
| This approach fits very well with the Closed-Loop Network and | This approach fits very well with the Closed-Loop Network and | |||
| Software-Defined Network (SDN) paradigm, where the SDN orchestrator | Software-Defined Network (SDN) paradigm, where the SDN orchestrator | |||
| and the SDN controllers are the brains of the network and can manage | and the SDN controllers are the brains of the network and can manage | |||
| flow control to the switches and routers and, in the same way, can | flow control to the switches and routers and, in the same way, can | |||
| calibrate the performance measurements depending on the desired | calibrate the performance measurements depending on the desired | |||
| accuracy. An SDN controller application can orchestrate how | accuracy. An SDN controller application can orchestrate how | |||
| accurately the network performance monitoring is set up by applying | accurately the network performance monitoring is set up by applying | |||
| the Multipoint Alternate-Marking as described in this document. | the Multipoint Alternate Marking as described in this document. | |||
| It is important to underline that, as an extension of | It is important to underline that, as an extension of [RFC9341], this | |||
| [I-D.ietf-ippm-rfc8321bis], this is a methodology document, so the | is a methodology document, so the mechanism that can be used to | |||
| mechanism that can be used to transmit the counters and the | transmit the counters and the timestamps is out of scope here. | |||
| timestamps is out of scope here. | ||||
| This document assumes that the blocks are created according to a | This document assumes that the blocks are created according to a | |||
| fixed timer as per [I-D.ietf-ippm-rfc8321bis]. Switching after a | fixed timer as per [RFC9341]. Switching after a fixed number of | |||
| fixed number of packets is possible but it is out of scope here. | packets is possible, but it is out of scope here. | |||
| Note that the fragmented packets' case can be managed with the | Note that the fragmented packets' case can be managed with the | |||
| Alternate-Marking methodology and the same guidance provided in | Alternate-Marking methodology, and the same guidance provided in | |||
| section 6 of [I-D.ietf-ippm-rfc8321bis] apply also in the case of | Section 6 of [RFC9341] also applies in the case of Multipoint | |||
| Multipoint Alternate-Marking. | Alternate Marking. | |||
| 1.1. Summary of Changes from RFC 8889 | 1.1. Summary of Changes from RFC 8889 | |||
| This document defines the Multipoint Alternate-Marking Method, | This document defines the Multipoint Alternate-Marking Method, | |||
| addressing ambiguities and overtaking its experimental phase in the | addressing ambiguities and overtaking its experimental phase in the | |||
| original specification [RFC8889]. | original specification [RFC8889]. | |||
| The relevant changes are: | The relevant changes are: | |||
| * Added the recommendations about the different deployments in case | * Added the recommendations about the different deployments in case | |||
| one or two flag bits are available for marking (Section 9). | one or two flag bits are available for marking (Section 9). | |||
| * Changed the structure to improve the readability. | * Changed the structure to improve readability. | |||
| * Removed the wording about the experimentation of the method and | * Removed the wording about the experimentation of the method and | |||
| considerations that no longer apply. | considerations that no longer apply. | |||
| * Revised the description of detailed aspects of the methodology, | * Revised the description of detailed aspects of the methodology, | |||
| e.g. synchronization and timing. | e.g., synchronization and timing. | |||
| It is important to note that all the changes are totally backward | It is important to note that all the changes are totally backward | |||
| compatible with [RFC8889] and no new additional technique has been | compatible with [RFC8889], and no new additional technique has been | |||
| introduced in this document compared to [RFC8889]. | introduced in this document compared to [RFC8889]. | |||
| 1.2. Requirements Language | 1.2. Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 2. Terminology | 2. Terminology | |||
| The definitions of the basic terms are identical to those found in | The use of the basic terms are identical to those found in Alternate | |||
| Alternate-Marking [I-D.ietf-ippm-rfc8321bis]. It is to be remembered | Marking [RFC9341]. It is to be remembered that [RFC9341] is valid | |||
| that [I-D.ietf-ippm-rfc8321bis] is valid for point-to-point unicast | for point-to-point unicast flows and BUM traffic. | |||
| flows and BUM traffic. | ||||
| The important new terms that need to be explained are listed below: | The important new terms are explained below: | |||
| Multipoint Alternate-Marking: Extension to | Multipoint Alternate Marking: Extension to [RFC9341], valid for | |||
| [I-D.ietf-ippm-rfc8321bis], valid for multipoint-to-multipoint | multipoint-to-multipoint unicast flows, anycast, and ECMP flows. | |||
| unicast flows, anycast, and ECMP flows. It can also be referred | It can also be referred to as "Clustered Alternate Marking". | |||
| to as Clustered Alternate-Marking. | ||||
| Flow definition: The concept of flow is generalized in this | Flow definition: The concept of flow is generalized in this | |||
| document. The identification fields are selected without any | document. The identification fields are selected without any | |||
| constraints and, in general, the flow can be a multipoint-to- | constraints and, in general, the flow can be a multipoint-to- | |||
| multipoint flow, as a result of aggregate point-to-point flows. | multipoint flow, as a result of aggregate point-to-point flows. | |||
| Monitoring Network: Identified with the nodes of the network that | Monitoring network: Identified with the nodes of the network that | |||
| are the measurement points (MPs) and the links that are the | are the measurement points (MPs) and the links that are the | |||
| connections between MPs. The monitoring network graph depends on | connections between MPs. The monitoring network graph depends on | |||
| the flow definition, so it can represent a specific flow or the | the flow definition, so it can represent a specific flow or the | |||
| entire network topology as aggregate of all the flows. Each node | entire network topology as aggregate of all the flows. Each node | |||
| of the monitoring network cannot be both a source and a | of the monitoring network cannot be both a source and a | |||
| destination of the flow. | destination of the flow. | |||
| Cluster: Smallest identifiable non-trivial subnetwork of the | Cluster: Smallest identifiable non-trivial subnetwork of the entire | |||
| entire monitoring network graph that still satisfies the condition | monitoring network graph that still satisfies the condition that | |||
| that the number of packets that go in is the same as the number | the number of packets that go in is the same as the number that go | |||
| that go out. A cluster partition algorithm, such as that found in | out. A cluster partition algorithm, such as that found in | |||
| Section 5.1, can be applied to split the monitoring network into | Section 5.1, can be applied to split the monitoring network into | |||
| clusters. | clusters. | |||
| Multipoint metrics: Packet loss, delay and delay variation are | Multipoint metrics: Packet loss, delay, and delay variation are | |||
| extended to the case of multipoint flows. It is possible to | extended to the case of multipoint flows. It is possible to | |||
| compute these metrics on the basis of multipoint paths in order to | compute these metrics on the basis of multipoint paths in order to | |||
| associate the measurements to a cluster, a combination of | associate the measurements to a cluster, a combination of | |||
| clusters, or the entire monitored network. For delay and delay | clusters, or the entire monitored network. For delay and delay | |||
| variation, it is also possible to define the metrics on a single- | variation, it is also possible to define the metrics on a single- | |||
| packet basis, and it means that the multipoint path is used to | packet basis, and it means that the multipoint path is used to | |||
| easily couple packets between input and output nodes of a | easily couple packets between input and output nodes of a | |||
| multipoint path. | multipoint path. | |||
| The next section highlights the correlation with the terms used in | The next section highlights the correlation with the terms used in | |||
| RFC 5644 [RFC5644]. | [RFC5644]. | |||
| 2.1. Correlation with RFC 5644 | 2.1. Correlation with RFC 5644 | |||
| RFC 5644 [RFC5644] is limited to active measurements using a single | [RFC5644] is limited to active measurements using a single source | |||
| source packet or stream. Its scope is also limited to observations | packet or stream. Its scope is also limited to observations of | |||
| of corresponding packets along the path (spatial metric) and at one | corresponding packets along the path (spatial metric) and at one or | |||
| or more destinations (one-to-group) along the path. | more destinations (one-to-group) along the path. | |||
| Instead, the scope of this memo is to define multiparty metrics for | Instead, the scope of this memo is to define multiparty metrics for | |||
| passive and hybrid measurements in a group-to-group topology with | passive and hybrid measurements in a group-to-group topology with | |||
| multiple sources and destinations. | multiple sources and destinations. | |||
| RFC 5644 [RFC5644] introduces metric names that can be reused here | [RFC5644] introduces metric names that can be reused here but have to | |||
| but have to be extended and rephrased to be applied to the Alternate- | be extended and rephrased to be applied to the Alternate-Marking | |||
| Marking schema: | schema: | |||
| a. the multiparty metrics are not only one-to-group metrics but can | a. the multiparty metrics are not only one-to-group metrics but can | |||
| be also group-to-group metrics; | also be group-to-group metrics; | |||
| b. the spatial metrics, used for measuring the performance of | b. the spatial metrics, used for measuring the performance of | |||
| segments of a source to destination path, are applied here to | segments of a source-to-destination path, are applied here to | |||
| clusters. | clusters. | |||
| 3. Flow Classification | 3. Flow Classification | |||
| A unicast flow is identified by all the packets having a set of | A unicast flow is identified by all the packets having a set of | |||
| common characteristics. This definition is inspired by RFC 7011 | common characteristics. This definition is inspired by [RFC7011]. | |||
| [RFC7011]. | ||||
| As an example, by considering a flow as all the packets sharing the | As an example, by considering a flow as all the packets sharing the | |||
| same source IP address or the same destination IP address, it is easy | same source IP address or the same destination IP address, it is easy | |||
| to understand that the resulting pattern will not be a point-to-point | to understand that the resulting pattern will not be a point-to-point | |||
| connection, but a point-to-multipoint or multipoint-to-point | connection but a point-to-multipoint or multipoint-to-point | |||
| connection. | connection. | |||
| In general, a flow can be defined by a set of selection rules used to | In general, a flow can be defined by a set of selection rules used to | |||
| match a subset of the packets processed by the network device. These | match a subset of the packets processed by the network device. These | |||
| rules specify a set of Layer 3 and Layer 4 header fields | rules specify a set of Layer 3 and Layer 4 header fields | |||
| (identification fields) and the relative values that must be found in | (identification fields) and the relative values that must be found in | |||
| matching packets. | matching packets. | |||
| The choice of the identification fields directly affects the type of | The choice of the identification fields directly affects the type of | |||
| paths that the flow would follow in the network. In fact, it is | paths that the flow would follow in the network. In fact, it is | |||
| possible to relate a set of identification fields with the pattern of | possible to relate a set of identification fields with the pattern of | |||
| the resulting graphs, as listed in Figure 1. | the resulting graphs, as listed in Figure 1. | |||
| A TCP 5-tuple usually identifies flows following either a single path | A TCP 5-tuple usually identifies flows following either a single path | |||
| or a point-to-point multipath (in the case of load balancing). On | or a point-to-point multipath (in the case of load balancing). On | |||
| the contrary, a single source address selects aggregate flows | the contrary, a single source address selects aggregate flows | |||
| following a point-to-multipoint, while a multipoint-to-point can be | following a point-to-multipoint path, while a multipoint-to-point | |||
| the result of a matching on a single destination address. In the | path can be the result of a matching on a single destination address. | |||
| case where a selection rule and its reverse are used for | In the case where a selection rule and its reverse are used for | |||
| bidirectional measurements, they can correspond to a point-to- | bidirectional measurements, they can correspond to a point-to- | |||
| multipoint in one direction and a multipoint-to-point in the opposite | multipoint path in one direction and a multipoint-to-point path in | |||
| direction. | the opposite direction. | |||
| So the flows to be monitored are selected into the monitoring points | So the flows to be monitored are selected into the monitoring points | |||
| using packet selection rules, which can also change the pattern of | using packet selection rules, which can also change the pattern of | |||
| the monitored network. | the monitored network. | |||
| Note that, more generally, the flow can be defined at different | Note that, more generally, the flow can be defined at different | |||
| levels based on the potential encapsulation, and additional | levels based on the potential encapsulation, and additional | |||
| conditions that are not in the packet header can also be included as | conditions that are not in the packet header can also be included as | |||
| part of matching criteria. | part of matching criteria. | |||
| The Alternate-Marking method is applicable only to a single path (and | The Alternate-Marking Method is applicable only to a single path (and | |||
| partially to a one-to-one multipath), so the extension proposed in | partially to a one-to-one multipath), so the extension proposed in | |||
| this document is suitable also for the most general case of | this document is suitable also for the most general case of | |||
| multipoint-to-multipoint, which embraces all the other patterns of | multipoint-to-multipoint, which embraces all the other patterns in | |||
| Figure 1. | Figure 1. | |||
| point-to-point single path | point-to-point single path | |||
| +------+ +------+ +------+ | +------+ +------+ +------+ | |||
| ---<> R1 <>----<> R2 <>----<> R3 <>--- | ---<> R1 <>----<> R2 <>----<> R3 <>--- | |||
| +------+ +------+ +------+ | +------+ +------+ +------+ | |||
| point-to-point multipath | point-to-point multipath | |||
| +------+ | +------+ | |||
| <> R2 <> | <> R2 <> | |||
| skipping to change at page 9, line 32 ¶ | skipping to change at line 392 ¶ | |||
| Figure 1: Flow Classification | Figure 1: Flow Classification | |||
| The case of unicast flow is considered in Figure 1. The anycast flow | The case of unicast flow is considered in Figure 1. The anycast flow | |||
| is also covered, since it is only a special case of a unicast flow if | is also covered, since it is only a special case of a unicast flow if | |||
| routing is stable throughout the measurement period. Furthermore, an | routing is stable throughout the measurement period. Furthermore, an | |||
| ECMP flow is in scope by definition, since it is a point-to- | ECMP flow is in scope by definition, since it is a point-to- | |||
| multipoint unicast flow. | multipoint unicast flow. | |||
| 4. Extension of the Method to Multipoint Flows | 4. Extension of the Method to Multipoint Flows | |||
| By using the Alternate-Marking method, only point-to-point paths can | By using the Alternate-Marking Method, only point-to-point paths can | |||
| be monitored. To have an IP (TCP/UDP) flow that follows a point-to- | be monitored. To have an IP (TCP/UDP) flow that follows a point-to- | |||
| point path, in general we have to define, with a specific value, 5 | point path, in general we have to define, with a specific value, 5 | |||
| identification fields (IP Source, IP Destination, Transport Protocol, | identification fields (IP Source, IP Destination, Transport Protocol, | |||
| Source Port, Destination Port). | Source Port, and Destination Port). | |||
| Multipoint Alternate-Marking enables the performance measurement for | Multipoint Alternate Marking enables the performance measurement for | |||
| multipoint flows selected by identification fields without any | multipoint flows selected by identification fields without any | |||
| constraints (even the entire network production traffic). It is also | constraints (even the entire network production traffic). It is also | |||
| possible to use multiple marking points for the same monitored flow. | possible to use multiple marking points for the same monitored flow. | |||
| 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. | |||
| It can be modeled as a set of nodes and a set of directed arcs which | It can be modeled as a set of nodes and a set of directed arcs that | |||
| connect pairs of nodes. | connect pairs of nodes. | |||
| 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, see [I-D.ietf-ippm-route]). In | monitoring network (as an example, see [RFC9198]). In general, there | |||
| general, there are different options: the monitoring network can be | are different options: the monitoring network can be obtained by | |||
| obtained by considering all the possible paths for the traffic or | considering all the possible paths for the traffic or periodically | |||
| periodically checking the traffic (e.g. daily, weekly, monthly) and | checking the traffic (e.g., daily, weekly, and monthly) and updating | |||
| updating the graph as appropriate, but this is up to the Network | the graph as appropriate, but this is up to the Network Management | |||
| Management System (NMS) configuration. | System (NMS) configuration. | |||
| 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, where the monitored interfaces and | |||
| identified. Only the measurement points and links where the traffic | links are identified. Only the measurement points and links where | |||
| has flowed have to be represented in the graph. | the traffic has flowed have to be represented in the graph. | |||
| A simple example of a monitoring network graph is showed in | A simple example of a monitoring network graph is shown in | |||
| Appendix A. | Appendix A. | |||
| Each monitoring point is characterized by the packet counter that | Each monitoring point is characterized by the packet counter that | |||
| refers only to a marking period of the monitored flow. Also, it is | refers only to a marking period of the monitored flow. Also, it is | |||
| assumed that there be a monitoring point at all possible egress | assumed that there is a monitoring point at all possible egress | |||
| points of the multipoint monitored network. | points of the multipoint monitored network. | |||
| The same is also applicable for the delay, but it will be described | The same is also applicable for the delay, but it will be described | |||
| in the following sections. | in the following sections. | |||
| The rest of the document assumes that the traffic is going from left | The rest of the document assumes that the traffic is going from left | |||
| to right in order to simplify the explanation. But the analysis done | to right in order to simplify the explanation. But the analysis done | |||
| for one direction applies equally to all directions. | for one direction applies equally to all directions. | |||
| 4.2. Network Packet Loss | 4.2. Network 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 than, or equal to, the number of | the input nodes is always greater than, or equal to, the number of | |||
| packets counted by all the output nodes. It is assumed that routing | packets counted by all the output nodes. It is assumed that routing | |||
| is stable during the measurement period while packet fragmentation | is stable during the measurement period while packet fragmentation | |||
| must be handled as described in [I-D.ietf-ippm-rfc8321bis]. | must be handled as described in [RFC9341]. | |||
| In the case of no packet loss occurring in the marking period, if all | In the 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 only have the task of splitting the | intermediate measurement points only have the task of splitting the | |||
| measurement. | measurement. | |||
| It is possible to define the Network Packet Loss of one monitored | It is possible to define the network packet loss of one monitored | |||
| flow for a single 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; and | |||
| 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 | |||
| this period | in this period. | |||
| The equation is applied on a per-time-interval basis and a per-flow | The equation is applied on a per-time-interval basis and a per-flow | |||
| basis: | basis: | |||
| The reference interval is the Alternate-Marking period, as defined | * The reference interval is the Alternate-Marking period, as defined | |||
| in [I-D.ietf-ippm-rfc8321bis]. | in [RFC9341]. | |||
| The flow definition is generalized here. Indeed, as described | * The flow definition is generalized here. Indeed, as described | |||
| before, a multipoint packet flow is considered, and the | before, a multipoint packet flow is considered, and the | |||
| identification fields can be selected without any constraints. | identification fields can be selected without any constraints. | |||
| 5. Network Clustering | 5. Network Clustering | |||
| The previous equation of Section 4.2 can determine the number of | The previous equation of Section 4.2 can determine the number of | |||
| packets lost globally in the monitored network, exploiting only the | packets lost globally in the monitored network, exploiting only the | |||
| data provided by the counters in the input and output nodes. | data provided by the counters in the input and output nodes. | |||
| In addition, it is possible to leverage the data provided by the | In addition, it is possible to leverage the data provided by the | |||
| skipping to change at page 12, line 42 ¶ | skipping to change at line 534 ¶ | |||
| clusters based on the topological information so that they are | clusters based on the topological information so that they are | |||
| applicable to all the possible flows in the monitored network. | applicable to all the possible flows in the monitored network. | |||
| Note that, in case of translation or encapsulation, the cluster | Note that, in case of translation or encapsulation, the cluster | |||
| properties must also be invariant. | properties must also be invariant. | |||
| 5.1. Algorithm for Clusters Partition | 5.1. Algorithm for Clusters Partition | |||
| A simple algorithm can be applied in order to split the monitoring | A simple algorithm can be applied in order to split the monitoring | |||
| network into clusters. This can be done for each direction | network into clusters. This can be done for each direction | |||
| separately, indeed a node cannot be both a source and a destination. | separately; indeed, a node cannot be both a source and a destination. | |||
| The clusters partition is based on the monitoring network graph, | The clusters partition is based on the monitoring network graph, | |||
| which can be valid for a specific flow or can also be general and | which can be valid for a specific flow or can also be general and | |||
| valid for the entire network topology. | valid for the entire network topology. | |||
| It is a two-step algorithm: | It is a two-step algorithm: | |||
| * Group the links where there is the same starting node; | * Group the links where there is the same starting node; | |||
| * Join the grouped links with at least one ending node in common. | * Join the grouped links with at least one ending node in common. | |||
| skipping to change at page 13, line 17 ¶ | skipping to change at line 557 ¶ | |||
| the different links if they have the same starting node. Note that | the different links if they have the same starting node. Note that | |||
| it is possible to start from any link, and the procedure will work. | it is possible to start from any link, and the procedure will work. | |||
| Following this classification, the second step implies eventually | Following this classification, the second step implies eventually | |||
| joining the groups classified in the first step by looking at the | joining the groups classified in the first step by looking at the | |||
| ending nodes. If different groups have at least one common ending | ending nodes. If different groups have at least one common ending | |||
| node, they are put together and belong to the same set. After the | node, they are put together and belong to the same set. After the | |||
| application of the two steps of the algorithm, each one of the | application of the two steps of the algorithm, each one of the | |||
| composed sets of links, together with the endpoint nodes, constitutes | composed sets of links, together with the endpoint nodes, constitutes | |||
| a cluster. | a cluster. | |||
| A simple application of the clusters partition is showed in | A simple application of the clusters partition is shown in | |||
| Appendix A. | Appendix A. | |||
| The algorithm, as applied in the example of a point-to-multipoint | The algorithm, as applied in the example of a point-to-multipoint | |||
| network, works for the more general case of multipoint-to-multipoint | network, works for the more general case of a multipoint-to- | |||
| network in the same way. It should be highlighted that for a | multipoint network in the same way. It should be highlighted that | |||
| multipoint-to-multipoint network the multiple sources MUST mark | for a multipoint-to-multipoint network, the multiple sources MUST | |||
| coherently the traffic and MUST be synchronized with all the other | mark the traffic coherently and MUST be synchronized with all the | |||
| nodes according to the timing requirements detailed in Section 8. | other nodes according to the timing requirements detailed in | |||
| Section 8. | ||||
| When the clusters partition is done, the calculation of packet loss, | When the clusters partition is done, the calculation of packet loss, | |||
| delay and delay variation can be made on a cluster basis. Note that | delay, and delay variation can be made on a cluster basis. Note that | |||
| the packet counters for each marking period permit calculating the | the packet counters for each marking period permit calculating the | |||
| packet rate on a cluster basis, so Committed Information Rate (CIR) | packet rate on a cluster basis, so Committed Information Rate (CIR) | |||
| and Excess Information Rate (EIR) could also be deduced on a cluster | and Excess Information Rate (EIR) could also be deduced on a cluster | |||
| basis. | basis. | |||
| Obviously, by combining some clusters in a new connected subnetwork | Obviously, by combining some clusters in a new connected subnetwork, | |||
| the packet-loss rule is still true. So it is also possible to | the packet-loss rule is still true. So it is also possible to | |||
| consider combinations of clusters if and where it suits. | consider combinations of clusters if and where it suits. | |||
| 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. It is possible to | detailed filter criteria to inspect the traffic. It is possible to | |||
| check a multipoint network and, in case of problems, go deep with a | check a multipoint network and, in case of problems, go deep with a | |||
| step-by-step cluster analysis, but only for the cluster or | 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. | |||
| In summary, once a flow is defined, the algorithm to build the | In summary, once a flow is defined, the algorithm to build the | |||
| clusters partition is based on topological information; therefore, it | clusters partition is based on topological information; therefore, it | |||
| considers all the possible links and nodes that could potentially be | considers all the possible links and nodes that could potentially be | |||
| crossed by the given flow, even if there is no traffic. So, if the | crossed by the given flow, even if there is no traffic. So if the | |||
| flow does not enter or traverse all the nodes, the counters have a | flow does not enter or traverse all the nodes, the counters have a | |||
| non-zero value for the involved nodes and a zero value for the other | non-zero value for the involved nodes and a zero value for the other | |||
| nodes without traffic; but in the end, all the formulas are still | nodes without traffic; but in the end, all the formulas are still | |||
| valid. | valid. | |||
| The algorithm described above is an iterative clustering algorithm | The algorithm described above is an iterative clustering algorithm | |||
| since it executes steps in iterations, but it is also possible to | since it executes steps in iterations, but it is also possible to | |||
| apply a recursive clustering algorithm as detailed in | apply a recursive clustering algorithm as detailed in | |||
| [IEEE-ACM-ToN-MPNPM]. | [IEEE-ACM-TON-MPNPM]. | |||
| The complete and mathematical analysis of the possible algorithms for | The complete and mathematical analysis of the possible algorithms for | |||
| clusters partition, including the considerations in terms of | the clusters 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]. | |||
| 6. Multipoint Packet Loss Measurement | 6. Multipoint Packet-Loss Measurement | |||
| The Network Packet Loss, defined in Section 4.2, valid for the entire | The network packet loss, defined in Section 4.2, valid for the entire | |||
| monitored flow, can easily be extended to each multipoint path (e.g., | monitored flow, can easily be extended to each multipoint path (e.g., | |||
| the whole multipoint network, a cluster, or a combination of | the whole multipoint network, a cluster, or a combination of | |||
| clusters). In this way it is possible to calculate Multipoint Packet | clusters). In this way, it is possible to calculate Multipoint | |||
| Loss that is representative of a multipoint path. | Packet Loss that is representative of a multipoint path. | |||
| The same equation of Section 4.2 can be applied to a generic | The same equation of Section 4.2 can be applied to a generic | |||
| multipoint path like a cluster or a combination of clusters, where | multipoint path like a cluster or a combination of clusters, where | |||
| the number of packets are those entering and leaving the multipoint | the number of packets are those entering and leaving the multipoint | |||
| path. | path. | |||
| By applying the algorithm described in Section 5.1, it is possible to | By applying the algorithm described in Section 5.1, it is possible to | |||
| split the monitoring network into clusters. Then, packet loss can be | split the monitoring network into clusters. Then, packet loss can be | |||
| measured on a cluster basis for each single period by considering the | measured on a cluster basis for each single period by considering the | |||
| counters of the input and output nodes that belong to the specific | counters of the input and output nodes that belong to the specific | |||
| cluster. This can be done for every packet flow in each marking | cluster. This can be done for every packet flow in each marking | |||
| period. | period. | |||
| 7. Multipoint Delay and Delay Variation | 7. 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. The delay measurement methods defined in | variation. The delay measurement methods defined in [RFC9341] can be | |||
| [I-D.ietf-ippm-rfc8321bis] can be extended to the case of multipoint | extended to the case of multipoint flows. It is important to | |||
| flows. It is important to highlight that both delay and delay- | highlight that both delay and delay-variation measurements make sense | |||
| variation measurements make sense in a multipoint path. The delay | in a multipoint path. The delay variation is calculated by | |||
| variation is calculated by considering the same packets selected for | considering the same packets selected for measuring the delay. | |||
| measuring the delay. | ||||
| In general, it is possible to perform delay and delay-variation | In general, it is possible to perform delay and delay-variation | |||
| measurements on the basis of multipoint paths or single packets: | measurements on the basis of multipoint paths or single packets: | |||
| * Delay measurements on the basis of multipoint paths mean that the | * Delay measurements on the basis of multipoint paths mean that the | |||
| delay value is representative of an entire multipoint path (e.g., | delay value is representative of an entire multipoint path (e.g., | |||
| the whole multipoint network, a cluster, or a combination of | the whole multipoint network, a cluster, or a combination of | |||
| clusters). | clusters). | |||
| * Delay measurements on a single-packet basis mean that it is | * Delay measurements on a single-packet basis mean that it is | |||
| skipping to change at page 15, line 27 ¶ | skipping to change at line 663 ¶ | |||
| or the entire monitored network. | or the entire monitored network. | |||
| The average latency can be measured as the difference between the | The average latency can be measured as the difference between the | |||
| weighted averages of the mean timestamps of the sets of output and | weighted averages of the mean timestamps of the sets of output and | |||
| input nodes. This means that, in the calculation, it is possible to | input nodes. This means that, in the calculation, it is possible to | |||
| weigh the timestamps with the number of packets for each endpoint. | weigh the timestamps with the number of packets for each endpoint. | |||
| Note that, since the one-way delay value is representative of a | Note that, since the one-way delay value is representative of a | |||
| multipoint path, it is possible to calculate the two-way delay of a | multipoint path, it is possible to calculate the two-way delay of a | |||
| multipoint path by summing the one-way delays of the two directions, | multipoint path by summing the one-way delays of the two directions, | |||
| similarly to [I-D.ietf-ippm-rfc8321bis]. | similarly to [RFC9341]. | |||
| 7.2. Delay Measurements on a Single-Packet Basis | 7.2. Delay Measurements on a Single-Packet Basis | |||
| 7.2.1. Single- and Double-Marking Measurement | 7.2.1. Single- and Double-Marking Measurement | |||
| Delay and delay-variation measurements associated with only one | Delay and delay-variation measurements associated with only one | |||
| picked packet per period, both single and double marked, cannot be | picked packet per period, both single and double marked, cannot be | |||
| easily performed in a multipoint scenario since there are some | easily performed in a multipoint scenario since there are some | |||
| limitations: | limitations: | |||
| Single marking based on the first/last packet of the interval does | * Single Marking based on the first/last packet of the interval does | |||
| not work properly. Indeed, by considering a point-to-multipoint | not work properly. Indeed, by considering a point-to-multipoint | |||
| scenario, it is not possible to recognize which path the first | scenario, it is not possible to recognize which path the first | |||
| packet of each block takes over the multipoint flow in order to | packet of each block takes over the multipoint flow in order to | |||
| correlate it. This is also true for the general case of the | correlate it. This is also true for the general case of the | |||
| multipoint-to-multipoint scenario. | multipoint-to-multipoint scenario. | |||
| Double marking or multiplexed marking works but only through | * Double Marking or multiplexed marking works but only through | |||
| statistical means. In a point-to-multipoint scenario, by | statistical means. In a point-to-multipoint scenario, by | |||
| selecting only a single packet with the second marking for each | selecting only a single packet with the second marking for each | |||
| block, it is possible to follow and calculate the delay for that | block, it is possible to follow and calculate the delay for that | |||
| picked packet. But the measurement can only be done for a single | picked packet. But the measurement can only be done for a single | |||
| path in each marking period. To traverse all the paths of the | path in each marking period. To traverse all the paths of the | |||
| multipoint flow, it can theoretically be done by continuing the | multipoint flow, it can theoretically be done by continuing the | |||
| measurement for the following marking periods and expect to span | measurement for the following marking periods and expect to span | |||
| all the paths. In the general case of a multipoint-to-multipoint | all the paths. In the general case of a multipoint-to-multipoint | |||
| path, it is also needed to take into account the multiple source | path, it is also needed to take into account the multiple source | |||
| nodes which complicate the correlation of the samples. In this | nodes that complicate the correlation of the samples. In this | |||
| case, it can be possible to select the second marked packet only | case, it can be possible to select the second marked packet only | |||
| for a source node at a time for each block and cover the remaining | for a source node at a time for each block and cover the remaining | |||
| source nodes one by one in the next marking periods. | source nodes one by one in the next marking periods. | |||
| Note that, since the one-way delay measurement is done on a single- | Note that, since the one-way delay measurement is done on a single- | |||
| packet basis, it is always possible to calculate the two-way delay | packet basis, it is always possible to calculate the two-way delay, | |||
| but it is not immediate since it is necessary to couple the | but it is not immediate since it is necessary to couple the | |||
| measurement on each single path with the opposite direction. In this | measurement on each single path with the opposite direction. In this | |||
| case the NMS can do the calculation. | case, the NMS can do the calculation. | |||
| If a delay measurement is performed for more than one picked packet | If a delay measurement is performed for more than one picked packet | |||
| and for all the paths of the multipoint flow in the same marking | and for all the paths of the multipoint flow in the same marking | |||
| period, neither the single- nor the double-marking method are | period, neither the Single- nor the Double-Marking Method are | |||
| applicable in the multipoint scenario. The packets follow different | applicable in the multipoint scenario. The packets follow different | |||
| paths and it becomes very difficult to correlate marked packets in a | paths, and it becomes very difficult to correlate marked packets in a | |||
| multipoint-to-multipoint path if there are more than one per period. | multipoint-to-multipoint path if there are more than one per 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 | |||
| multipoint path in the same marking period. For this purpose, | multipoint path in the same marking period. For this purpose, | |||
| hashing can be used, as reported in the next section. | hashing can be used, as reported in the next section. | |||
| 7.2.2. Hashing Selection Method | 7.2.2. Hashing Selection Method | |||
| RFCs 5474 [RFC5474] and 5475 [RFC5475] introduce sampling and | Sampling and filtering techniques for IP packet selection are | |||
| filtering techniques for IP packet selection. | introduced in [RFC5474] and [RFC5475]. | |||
| The hash-based selection methodologies for delay measurement can work | The hash-based selection methodologies for delay measurement can work | |||
| in a multipoint-to-multipoint path and can be used either coupled to | in a multipoint-to-multipoint path and can be used either coupled to | |||
| mean delay or stand-alone. | mean delay or standalone. | |||
| [IEEE-Network-PNPM] introduces how to use the hash method (RFC 5474 | [IEEE-NETWORK-PNPM] introduces how to use the hash method (see | |||
| [RFC5474] and RFC 5475 [RFC5475]) combined with the Alternate-Marking | [RFC5474] and [RFC5475]) combined with the Alternate-Marking Method | |||
| method for point-to-point flows. It is also called Mixed Hashed | for point-to-point flows. It is also called "Mixed Hashed Marking" | |||
| Marking because it refers to the conjunction of the marking method | because it refers to the conjunction of the marking method and the | |||
| and the hashing technique. It involves only the single marking, | hashing technique. It involves only the Single Marking; indeed, it | |||
| indeed it is supposed that double marking is not used with hashing. | is supposed that Double Marking is not used with hashing. The | |||
| The coupling of the single marking with the hashing selection allows | coupling of the Single Marking with the hashing selection allows | |||
| choosing a simplified hash function since the alternation of blocks | choosing a simplified hash function since the alternation of blocks | |||
| gives temporal boundaries for the hashing samples. The marking | gives temporal boundaries for the hashing samples. The marking | |||
| batches anchor the samples selected with hashing and this eases the | batches anchor the samples selected with hashing, and this eases the | |||
| correlation of the hashing packets along the path. For example, in | correlation of the hashing packets along the path. For example, in | |||
| case a hashed sample is lost, it is confined to the considered block | case a hashed sample is lost, it is confined to the considered block | |||
| without affecting the identification of the samples for the following | without affecting the identification of the samples for the following | |||
| blocks. | blocks. | |||
| Using the hash-based sampling, the number of samples in each block | Using the hash-based sampling, the number of samples in each block | |||
| may vary a lot because it depends on the packet rate that is | may vary a lot because it depends on the packet rate that is | |||
| variable. A dynamic approach can help to have an almost fixed number | variable. A dynamic approach can help to have an almost fixed number | |||
| of samples for each marking period, and this is a better option for | of samples for each marking period, and this is a better option for | |||
| making regular measurements over time. In the hash-based sampling, | making regular measurements over time. In the hash-based sampling, | |||
| Alternate-Marking is used to create periods, so that hash-based | Alternate Marking is used to create periods, so that hash-based | |||
| samples are divided into batches, which allows anchoring the selected | samples are divided into batches, which allows anchoring the selected | |||
| samples to their period. Moreover, in a dynamic hash-based sampling, | samples to their period. Moreover, in a dynamic hash-based sampling, | |||
| it can be possible to dynamically adapt the length of the hash value | it can be possible to dynamically adapt the length of the hash value | |||
| to meet the current packet rate, so that the number of samples is | to meet the current packet rate, so that the number of samples is | |||
| bounded in each marking period. | bounded in each marking period. | |||
| In a multipoint environment, the hashing selection may be the | In a multipoint environment, the hashing selection may be the | |||
| solution for performing delay measurements on specific packets and | solution for performing delay measurements on specific packets and | |||
| overcoming the single- and double-marking limitations. | overcoming the Single- and Double-Marking limitations. | |||
| 8. Synchronization and Timing | 8. Synchronization and Timing | |||
| 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 | packets happen and have to be handled as well, as described in | |||
| [I-D.ietf-ippm-rfc8321bis]. | [RFC9341]. | |||
| However, in a multisource situation, an additional issue has to be | However, in a multisource situation, an additional issue has to be | |||
| considered. With multipoint path, the egress nodes will receive | considered. With multipoint path, the egress nodes will receive | |||
| alternate marked packets in random order from different ingress | alternate marked packets in random order from different ingress | |||
| nodes, and this must not affect the measurement. | nodes, and this must not affect the measurement. | |||
| So, if we analyze a multipoint-to-multipoint path with more than one | So, if we analyze a multipoint-to-multipoint path with more than one | |||
| marking node, it is important to recognize the reference measurement | marking node, it is important to recognize the reference measurement | |||
| interval. In general, the measurement interval for describing the | interval. In general, the measurement interval for describing the | |||
| results is the interval of the marking node that is more aligned with | results is the interval of the marking node that is more aligned with | |||
| skipping to change at page 18, line 7 ¶ | skipping to change at line 782 ¶ | |||
| time -> start stop | time -> start stop | |||
| T(R1) |-------------| | T(R1) |-------------| | |||
| T(R2) |-------------| | T(R2) |-------------| | |||
| T(R3) |------------| | T(R3) |------------| | |||
| Figure 2: Measurement Interval | Figure 2: Measurement Interval | |||
| In Figure 2, it is assumed that the node with the earliest clock (R1) | In Figure 2, it is assumed that the node with the earliest clock (R1) | |||
| identifies the right starting and ending times of the measurement, | identifies the right starting and ending times of the measurement, | |||
| but it is just an assumption, and other possibilities could occur. | but it is just an assumption and other possibilities could occur. So | |||
| So, in this case, T(R1) is the measurement interval, and its | in this case, T(R1) is the measurement interval, and its recognition | |||
| recognition is essential in order to make comparisons with other | is essential in order to make comparisons with other active/passive/ | |||
| active/passive/hybrid Packet Loss metrics. | hybrid packet-loss metrics. | |||
| Regarding the timing constraints of the methodology, | Regarding the timing constraints of the methodology, [RFC9341] | |||
| [I-D.ietf-ippm-rfc8321bis] already describes two contributions that | already describes two contributions that are taken into account: the | |||
| are taken into account: the clock error between network devices and | clock error between network devices and the network delay between the | |||
| the network delay between the measurement points. | measurement points. | |||
| When we expand to a multipoint environment, we have to consider that | When we expand to a multipoint environment, we have to consider that | |||
| there are more marking nodes that mark the traffic based on | there are more marking nodes that mark the traffic based on | |||
| synchronized clock time. But, due to different synchronization | synchronized clock time. But, due to different synchronization | |||
| issues that may happen, the marking batches can be of different | issues that may happen, the marking batches can be of different | |||
| lengths and with different offsets when they get mixed in a | lengths and with different offsets when they get mixed in a | |||
| multipoint flow. According to [I-D.ietf-ippm-rfc8321bis], the | multipoint flow. According to [RFC9341], the maximum clock skew | |||
| maximum clock skew between the network devices is A. Therefore, the | between the network devices is A. Therefore, the additional gap that | |||
| additional gap that results between the multiple sources can be | results between the multiple sources can be incorporated into A. | |||
| incorporated into A. | ||||
| ...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB... | ...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB... | |||
| |<======================================>| | |<======================================>| | |||
| | L | | | L | | |||
| ...=========>|<==================><==================>|<==========... | ...=========>|<==================><==================>|<==========... | |||
| | L/2 L/2 | | | L/2 L/2 | | |||
| |<====>| |<====>| | |<====>| |<====>| | |||
| d | | d | d | | d | |||
| |<========================>| | |<========================>| | |||
| available counting interval | available counting interval | |||
| Figure 3: Timing Aspects | Figure 3: Timing Aspects | |||
| Moreover, it is assumed that the multipoint path can be modeled with | Moreover, it is assumed that the multipoint path can be modeled with | |||
| a normal distribution, otherwise it is necessary to reformulate based | a normal distribution; otherwise, it is necessary to reformulate | |||
| on the type of distribution. Under this assumption, the definition | based on the type of distribution. Under this assumption, the | |||
| of the guard band d is still applicable as defined in | definition of the guard band d is still applicable as defined in | |||
| [I-D.ietf-ippm-rfc8321bis] and is given by: | [RFC9341] and is given by: | |||
| d = A + D_avg + 3*D_stddev, | d = A + D_avg + 3*D_stddev, | |||
| where A is the clock accuracy, D_avg is the average value of the | where A is the clock accuracy, D_avg is the average value of the | |||
| network delay, and D_stddev is the standard deviation of the delay. | network delay, and D_stddev is the standard deviation of the delay. | |||
| As shown in Figure 3 and according to [I-D.ietf-ippm-rfc8321bis], the | As shown in Figure 3 and according to [RFC9341], the condition that | |||
| condition that must be satisfied to enable the method to function | must be satisfied to enable the method to function properly is that | |||
| properly is that the available counting interval must be > 0, and | the available counting interval must be > 0, and that means: | |||
| that means: | ||||
| L - 2d > 0. | L - 2d > 0. | |||
| This formula needs to be verified for each measurement point on the | This formula needs to be verified for each measurement point on the | |||
| multipoint path. | multipoint path. | |||
| Note that the timing considerations are valid for both packet loss | Note that the timing considerations are valid for both packet loss | |||
| and delay measurements. | and delay measurements. | |||
| 9. Recommendations for Deployment | 9. Recommendations for Deployment | |||
| The methodology described in the previous sections can be applied to | The methodology described in the previous sections can be applied to | |||
| various performance measurement problems, as also explained in | various performance measurement problems, as also explained in | |||
| [I-D.ietf-ippm-rfc8321bis]. [RFC8889] reports experimental examples | [RFC9341]. [RFC8889] reports experimental examples and | |||
| and [IEEE-Network-PNPM] also includes some information about the | [IEEE-NETWORK-PNPM] also includes some information about the | |||
| deployment experience. | deployment experience. | |||
| Different deployments are possible using one flag bit, two flag bits | Different deployments are possible using one flag bit, two flag bits, | |||
| or hashing selection: | or the hashing selection: | |||
| One flag: packet loss measurement MUST be done as described in | One flag: packet-loss measurement MUST be done as described in | |||
| Section 6 by applying the network clustering partition described | Section 6 by applying the network clustering partition described | |||
| in Section 5. Delay measurement MUST be done according to the | in Section 5. Delay measurement MUST be done according to the | |||
| Mean delay calculation representative of the multipoint path, as | mean delay calculation representative of the multipoint path, as | |||
| described in Section 7.1.1. Single-marking method based on the | described in Section 7.1.1. A Single-Marking Method based on the | |||
| first/last packet of the interval cannot be applied, as mentioned | first/last packet of the interval cannot be applied, as mentioned | |||
| in Section 7.2.1. | in Section 7.2.1. | |||
| Two flags: packet loss measurement MUST be done as described in | Two flags: packet-loss measurement MUST be done as described in | |||
| Section 6 by applying the network clustering partition described | Section 6 by applying the network clustering partition described | |||
| in Section 5. Delay measurement SHOULD be done on a single packet | in Section 5. Delay measurement SHOULD be done on a single-packet | |||
| basis according to double-marking method Section 7.2.1. In this | basis according to the Double-Marking Method (Section 7.2.1). In | |||
| case the Mean delay calculation (Section 7.1.1) MAY also be used | this case, the mean delay calculation (Section 7.1.1) MAY also be | |||
| as a representative value of a multipoint path. The choice | used as a representative value of a multipoint path. The choice | |||
| depends on the kind of information that is needed, as further | depends on the kind of information that is needed, as further | |||
| detailed below. | detailed below. | |||
| One flag with hash-based selection: packet loss measurement MUST | One flag with hash-based selection: packet-loss measurement MUST be | |||
| be done as described in Section 6 by applying the network | done as described in Section 6 by applying the network clustering | |||
| clustering partition described in Section 5. Hash-based selection | partition described in Section 5. Hash-based selection | |||
| methodologies, introduced in Section 7.2.2, MUST be used for delay | methodologies, introduced in Section 7.2.2, MUST be used for delay | |||
| measurement. | measurement. | |||
| Similarly to [I-D.ietf-ippm-rfc8321bis], there are some operational | Similarly to [RFC9341], there are some operational guidelines to | |||
| guidelines to consider for the purpose of deciding to follow the | consider when deciding which recommendation to use (i.e., one flag or | |||
| recommendations above and use one or two flags or one flag with hash- | two flags or one flag with hash-based selection. | |||
| based selection. | ||||
| The Multipoint Alternate-Marking method utilizes specific flags in | * The Multipoint Alternate-Marking Method utilizes specific flags in | |||
| the packet header, so an important factor is the number of flags | the packet header, so an important factor is the number of flags | |||
| available for the implementation. Indeed, if there is only one | available for the implementation. Indeed, if there is only one | |||
| flag available there is no other way, while if two flags are | flag available, there is no other way, while if two flags are | |||
| available the option with two flags can be considered in | available, the option with two flags can be considered in | |||
| comparison with the option of one flag with hash-based selection. | comparison with the option of one flag with hash-based selection. | |||
| The duration of the Alternate-Marking period affects the frequency | * The duration of the Alternate-Marking period affects the frequency | |||
| of the measurement and this is a parameter that can be decided on | of the measurement, and this is a parameter that can be decided on | |||
| the basis of the required temporal sampling. But it cannot be | the basis of the required temporal sampling. But it cannot be | |||
| freely chosen, as explained in Section 8. | freely chosen, as explained in Section 8. | |||
| The Multipoint Alternate-Marking methodologies enable packet loss, | * The Multipoint Alternate-Marking methodologies enable packet loss, | |||
| delay and delay variation calculation, but in accordance with the | delay, and delay variation calculation, but in accordance with the | |||
| method used (e.g. single-marking or double-marking or hashing | method used (e.g., Single Marking, Double Marking, or hashing | |||
| selection), there is a different kind of information that can be | selection), there is a different kind of information that can be | |||
| derived. For example, to get measurements on a multipoint-paths | derived. For example, to get measurements on a multipoint-paths | |||
| basis, one flag can be used. To get measurements on a single- | basis, one flag can be used. To get measurements on a single- | |||
| packet basis, two flags are preferred. For this reason, the type | packet basis, two flags are preferred. For this reason, the type | |||
| of data needed in the specific scenario is an additional element | of data needed in the specific scenario is an additional element | |||
| to take into account. | to take into account. | |||
| The Multipoint Alternate-Marking methods imply different | * The Multipoint Alternate-Marking Methods imply different | |||
| computational load depending on the method employed. Therefore, | computational load depending on the method employed. Therefore, | |||
| the available computational resources on the measurement points | the available computational resources on the measurement points | |||
| can also influence the choice. As an example, mean delay | can also influence the choice. As an example, mean delay | |||
| calculation may require more processing and it may not be the best | calculation may require more processing, and it may not be the | |||
| option to minimize the computational load. | best option to minimize the computational load. | |||
| The experiment with Multipoint Alternate-Marking methodologies | The experiment with Multipoint Alternate-Marking methodologies | |||
| confirmed the benefits of the Alternate-Marking methodology | confirmed the benefits of the Alternate-Marking methodology [RFC9341] | |||
| ([I-D.ietf-ippm-rfc8321bis]), as its extension to the general case of | as its extension to the general case of multipoint-to-multipoint | |||
| multipoint-to-multipoint scenarios. | scenarios. | |||
| The Multipoint Alternate-Marking Method MUST only be applied to | The Multipoint Alternate-Marking Method MUST only be applied to | |||
| controlled domains, as per [I-D.ietf-ippm-rfc8321bis]. | controlled domains, as per [RFC9341]. | |||
| 10. A Closed-Loop Performance-Management Approach | 10. A Closed-Loop 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 Performance Management (PM), because it | document adds flexibility to Performance Management (PM), because it | |||
| can reduce the order of magnitude of the packet counters. This | can reduce the order of magnitude of the packet counters. This | |||
| allows an SDN orchestrator to supervise, control, and manage PM in | allows an SDN orchestrator to supervise, control, and manage PM in | |||
| large networks. | large networks. | |||
| The monitoring network can be considered as a whole or split into | The monitoring network can be considered as a whole or split into | |||
| clusters that are the smallest subnetworks (group-to-group segments), | clusters that are the smallest subnetworks (group-to-group segments), | |||
| maintaining the packet-loss property for each subnetwork. The | maintaining the packet-loss property for each subnetwork. The | |||
| clusters can also be combined in new, connected subnetworks at | clusters can also be combined in new, connected subnetworks at | |||
| different levels, depending on the detail we want to achieve. | different levels, depending on the detail we want to achieve. | |||
| An SDN controller or a Network Management System (NMS) can calibrate | An SDN controller or an NMS can calibrate performance measurements, | |||
| performance measurements, since they are aware of the network | since they are aware of the network topology. They can start without | |||
| topology. They can start without examining in depth. In case of | examining in depth. In case of necessity (packet loss is measured or | |||
| necessity (packet loss is measured, or the delay is too high), the | the delay is too high), the filtering criteria could be immediately | |||
| filtering criteria could be immediately reconfigured in order to | reconfigured in order to perform a partition of the network by using | |||
| perform a partition of the network by using clusters and/or different | clusters and/or different combinations of clusters. In this way, the | |||
| combinations of clusters. In this way, the problem can be localized | problem can be localized in a specific cluster or a single | |||
| in a specific cluster or a single combination of clusters, and a more | combination of clusters, and a more detailed analysis can be | |||
| detailed analysis can be performed step by step by successive | performed step by step by successive approximation up to a point-to- | |||
| approximation up to a point-to-point flow detailed analysis. This is | point flow detailed analysis. This is the so-called "closed loop". | |||
| the so-called "closed loop". | ||||
| This approach can be called "network zooming" and can be performed in | This approach can be called "network zooming" and can be performed in | |||
| two different ways: | two different ways: | |||
| 1) change the traffic filter and select more detailed flows; | 1. change the traffic filter and select more detailed flows; | |||
| 2) activate new measurement points by defining more specified | 2. activate new measurement points by defining more specified | |||
| clusters. | clusters. | |||
| The network-zooming approach implies that some filters or rules are | The network-zooming approach implies that some filters or rules are | |||
| changed and that therefore there is a transient time to wait once the | changed; therefore, there is a transient time to wait once the new | |||
| new network configuration takes effect. This time can be determined | network configuration takes effect. This time can be determined by | |||
| by the Network Orchestrator/Controller, based on the network | the network orchestrator/controller, based on the network conditions. | |||
| conditions. | ||||
| For example, if the network zooming identifies the performance | For example, if the network zooming identifies the performance | |||
| problem for the traffic coming from a specific source, we need to | problem for the traffic coming from a specific source, we need to | |||
| recognize the marked signal from this specific source node and its | recognize the marked signal from this specific source node and its | |||
| relative path. For this purpose, we can activate all the available | relative path. For this purpose, we can activate all the available | |||
| measurement points and better specify the flow filter criteria (i.e., | measurement points and better specify the flow filter criteria (i.e., | |||
| 5-tuple). As an alternative, it can be enough to select packets from | 5-tuple). As an alternative, it can be enough to select packets from | |||
| the specific source for delay measurements; in this case, it is | the specific source for delay measurements; in this case, it is | |||
| possible to apply the hashing technique, as mentioned in the previous | possible to apply the hashing technique, as mentioned in the previous | |||
| sections. | sections. | |||
| [I-D.song-opsawg-ifit-framework] defines an architecture where the | [OPSAWG-IFIT-FRAMEWORK] defines an architecture where the centralized | |||
| centralized Data Collector and Network Management can apply the | data collector and network management can apply the intelligent and | |||
| intelligent and flexible Alternate-Marking algorithm as previously | flexible Alternate-Marking algorithm as previously described. | |||
| described. | ||||
| As for [I-D.ietf-ippm-rfc8321bis], it is possible to classify the | As for [RFC9341], it is possible to classify the traffic and mark a | |||
| traffic and mark a portion of the total traffic. For each period, | portion of the total traffic. For each period, the packet rate and | |||
| the packet rate and bandwidth are calculated from the number of | bandwidth are calculated from the number of packets. In this way, | |||
| packets. In this way, the network orchestrator becomes aware if the | the network orchestrator becomes aware if the traffic rate surpasses | |||
| traffic rate surpasses limits. In addition, more precision can be | limits. In addition, more precision can be obtained by reducing the | |||
| obtained by reducing the marking period; indeed, some implementations | marking period; indeed, some implementations use a marking period of | |||
| use a marking period of 1 sec or less. | 1 sec or less. | |||
| In addition, an SDN controller could also collect the measurement | In addition, an SDN controller could also collect the measurement | |||
| history. | history. | |||
| It is important to mention that the Multipoint Alternate-Marking | It is important to mention that the Multipoint Alternate-Marking | |||
| framework also helps Traffic Visualization. Indeed, this methodology | framework also helps Traffic Visualization. Indeed, this methodology | |||
| is very useful for identifying which path or cluster is crossed by | is very useful for identifying which path or cluster is crossed by | |||
| the flow. | the flow. | |||
| 11. Security Considerations | 11. Security Considerations | |||
| This document specifies a method of performing measurements that does | This document specifies a method of performing measurements that does | |||
| not directly affect Internet security or applications that run on the | not directly affect Internet security or applications that run on the | |||
| Internet. However, implementation of this method must be mindful of | Internet. However, implementation of this method must be mindful of | |||
| security and privacy concerns, as explained in | security and privacy concerns, as explained in [RFC9341]. | |||
| [I-D.ietf-ippm-rfc8321bis]. | ||||
| 12. IANA Considerations | 12. IANA Considerations | |||
| This document has no IANA actions. | This document has no IANA actions. | |||
| 13. Contributors | 13. References | |||
| Greg Mirsky Ericsson Email: gregimirsky@gmail.com | ||||
| Tal Mizrahi Huawei Technologies Email: tal.mizrahi.phd@gmail.com | ||||
| Xiao Min ZTE Corp. Email: xiao.min2@zte.com.cn | ||||
| 14. Acknowledgements | ||||
| The authors would like to thank Martin Duke and Tommy Pauly for their | ||||
| assistance and their detailed and precious reviews. | ||||
| 15. References | ||||
| 15.1. Normative References | ||||
| [I-D.ietf-ippm-rfc8321bis] | 13.1. Normative References | |||
| Fioccola, G., Cociglio, M., Mirsky, G., Mizrahi, T., and | ||||
| T. Zhou, "Alternate-Marking Method", Work in Progress, | ||||
| Internet-Draft, draft-ietf-ippm-rfc8321bis-03, 25 July | ||||
| 2022, <https://www.ietf.org/archive/id/draft-ietf-ippm- | ||||
| rfc8321bis-03.txt>. | ||||
| [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>. | |||
| [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. | [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. | |||
| Raspall, "Sampling and Filtering Techniques for IP Packet | Raspall, "Sampling and Filtering Techniques for IP Packet | |||
| Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, | Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, | |||
| <https://www.rfc-editor.org/info/rfc5475>. | <https://www.rfc-editor.org/info/rfc5475>. | |||
| [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>. | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| 15.2. Informative References | [RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T., | |||
| and T. Zhou, "Alternate-Marking Method", RFC 9341, | ||||
| [I-D.ietf-ippm-route] | DOI 10.17487/RFC9341, December 2022, | |||
| Alvarez-Hamelin, J. I., Morton, A., Fabini, J., Pignataro, | <https://www.rfc-editor.org/info/rfc9341>. | |||
| C., and R. Geib, "Advanced Unidirectional Route Assessment | ||||
| (AURA)", Work in Progress, Internet-Draft, draft-ietf- | ||||
| ippm-route-10, 13 August 2020, | ||||
| <https://www.ietf.org/archive/id/draft-ietf-ippm-route- | ||||
| 10.txt>. | ||||
| [I-D.song-opsawg-ifit-framework] | 13.2. Informative References | |||
| Song, H., Qin, F., Chen, H., Jin, J., and J. Shin, "A | ||||
| Framework for In-situ Flow Information Telemetry", Work in | ||||
| Progress, Internet-Draft, draft-song-opsawg-ifit- | ||||
| framework-18, 6 September 2022, | ||||
| <https://www.ietf.org/archive/id/draft-song-opsawg-ifit- | ||||
| framework-18.txt>. | ||||
| [IEEE-ACM-ToN-MPNPM] | [IEEE-ACM-TON-MPNPM] | |||
| IEEE/ACM TRANSACTION ON NETWORKING, "Multipoint Passive | Cociglio, M., Fioccola, G., Marchetto, G., Sapio, A., and | |||
| Monitoring in Packet Networks", | R. Sisto, "Multipoint Passive Monitoring in Packet | |||
| DOI 10.1109/TNET.2019.2950157, 2019, | Networks", IEEE/ACM Transactions on Networking, Vol. 27, | |||
| Issue 6, DOI 10.1109/TNET.2019.2950157, December 2019, | ||||
| <https://doi.org/10.1109/TNET.2019.2950157>. | <https://doi.org/10.1109/TNET.2019.2950157>. | |||
| [IEEE-Network-PNPM] | [IEEE-NETWORK-PNPM] | |||
| IEEE Network, "AM-PM: Efficient Network Telemetry using | Mizrahi, T., Navon, G., Fioccola, G., Cociglio, M., Chen, | |||
| Alternate Marking", DOI 10.1109/MNET.2019.1800152, 2019, | M., and G. Mirsky, "AM-PM: Efficient Network Telemetry | |||
| using Alternate Marking", IEEE Network, Vol. 33, Issue 4, | ||||
| DOI 10.1109/MNET.2019.1800152, July 2019, | ||||
| <https://doi.org/10.1109/MNET.2019.1800152>. | <https://doi.org/10.1109/MNET.2019.1800152>. | |||
| [OPSAWG-IFIT-FRAMEWORK] | ||||
| Song, H., Qin, F., Chen, H., Jin, J., and J. Shin, "A | ||||
| Framework for In-situ Flow Information Telemetry", Work in | ||||
| Progress, Internet-Draft, draft-song-opsawg-ifit- | ||||
| framework-19, 24 October 2022, | ||||
| <https://datatracker.ietf.org/doc/html/draft-song-opsawg- | ||||
| ifit-framework-19>. | ||||
| [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>. | |||
| [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, | [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, | |||
| "Specification of the IP Flow Information Export (IPFIX) | "Specification of the IP Flow Information Export (IPFIX) | |||
| Protocol for the Exchange of Flow Information", STD 77, | Protocol for the Exchange of Flow Information", STD 77, | |||
| RFC 7011, DOI 10.17487/RFC7011, September 2013, | RFC 7011, DOI 10.17487/RFC7011, September 2013, | |||
| <https://www.rfc-editor.org/info/rfc7011>. | <https://www.rfc-editor.org/info/rfc7011>. | |||
| [RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto, | [RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto, | |||
| "Multipoint Alternate-Marking Method for Passive and | "Multipoint Alternate-Marking Method for Passive and | |||
| Hybrid Performance Monitoring", RFC 8889, | Hybrid Performance Monitoring", RFC 8889, | |||
| DOI 10.17487/RFC8889, August 2020, | DOI 10.17487/RFC8889, August 2020, | |||
| <https://www.rfc-editor.org/info/rfc8889>. | <https://www.rfc-editor.org/info/rfc8889>. | |||
| [RFC9198] Alvarez-Hamelin, J., Morton, A., Fabini, J., Pignataro, | ||||
| C., and R. Geib, "Advanced Unidirectional Route Assessment | ||||
| (AURA)", RFC 9198, DOI 10.17487/RFC9198, May 2022, | ||||
| <https://www.rfc-editor.org/info/rfc9198>. | ||||
| Appendix A. Example of Monitoring Network and Clusters Partition | Appendix A. Example of Monitoring Network and Clusters Partition | |||
| Figure 4 shows a simple example of a monitoring network graph: | Figure 4 shows a simple example of a monitoring network graph: | |||
| +------+ | +------+ | |||
| <> R6 <>--- | <> R6 <>--- | |||
| / +------+ | / +------+ | |||
| +------+ +------+ / | +------+ +------+ / | |||
| <> R2 <>---<> R4 <> | <> R2 <>---<> R4 <> | |||
| / +------+ \ +------+ \ | / +------+ \ +------+ \ | |||
| skipping to change at page 25, line 35 ¶ | skipping to change at line 1098 ¶ | |||
| +------+ | +------+ | |||
| Figure 4: Monitoring Network Graph | Figure 4: Monitoring Network Graph | |||
| In the monitoring network graph example, it is possible to identify | In the monitoring network graph example, it is possible to identify | |||
| the clusters partition by applying this two-step algorithm described | the clusters partition by applying this two-step algorithm described | |||
| in Section 5.1. | in Section 5.1. | |||
| The first step identifies the following groups: | The first step identifies the following groups: | |||
| 1. Group 1: (R1-R2), (R1-R3), (R1-R10) | Group 1: (R1-R2), (R1-R3), (R1-R10) | |||
| 2. Group 2: (R2-R4), (R2-R5) | Group 2: (R2-R4), (R2-R5) | |||
| 3. Group 3: (R3-R5), (R3-R9) | Group 3: (R3-R5), (R3-R9) | |||
| 4. Group 4: (R4-R6), (R4-R7) | Group 4: (R4-R6), (R4-R7) | |||
| 5. Group 5: (R5-R8) | Group 5: (R5-R8) | |||
| And then, the second step builds the clusters partition (in | Then, the second step builds the clusters partition (in particular, | |||
| particular, we can underline that Groups 2 and 3 connect together, | we can underline that Groups 2 and 3 connect together, since R5 is in | |||
| since R5 is in common): | common): | |||
| 1. Cluster 1: (R1-R2), (R1-R3), (R1-R10) | Cluster 1: (R1-R2), (R1-R3), (R1-R10) | |||
| 2. Cluster 2: (R2-R4), (R2-R5), (R3-R5), (R3-R9) | Cluster 2: (R2-R4), (R2-R5), (R3-R5), (R3-R9) | |||
| 3. Cluster 3: (R4-R6), (R4-R7) | ||||
| 4. Cluster 4: (R5-R8) | Cluster 3: (R4-R6), (R4-R7) | |||
| The flow direction here considered is from left to right. For the | Cluster 4: (R5-R8) | |||
| The flow direction considered here is from left to right. For the | ||||
| opposite direction, the same reasoning can be applied, and in this | opposite direction, the same reasoning can be applied, and in this | |||
| example, you get the same clusters partition. | example, you get the same clusters partition. | |||
| In the end, the following 4 clusters are obtained: | In the end, the following 4 clusters are obtained: | |||
| Cluster 1 | Cluster 1 | |||
| +------+ | +------+ | |||
| <> R2 <>--- | <> R2 <>--- | |||
| / +------+ | / +------+ | |||
| / | / | |||
| skipping to change at page 27, line 31 ¶ | skipping to change at line 1188 ¶ | |||
| <> R8 <>--- | <> R8 <>--- | |||
| +------+ | +------+ | |||
| Figure 5: Clusters Example | Figure 5: Clusters Example | |||
| There are clusters with more than two nodes as well as two-node | There are clusters with more than two nodes as well as two-node | |||
| clusters. In the two-node clusters, the loss is on the link (Cluster | clusters. In the two-node clusters, the loss is on the link (Cluster | |||
| 4). In more-than-two-node clusters, the loss is on the cluster, but | 4). In more-than-two-node clusters, the loss is on the cluster, but | |||
| we cannot know in which link (Cluster 1, 2, or 3). | we cannot know in which link (Cluster 1, 2, or 3). | |||
| Appendix B. Changes Log | Acknowledgements | |||
| Changes from RFC 8889 in draft-fioccola-rfc8889bis-00 include: | ||||
| * Minor editorial changes | ||||
| * Removed section on "Examples of application" | ||||
| Changes in draft-fioccola-rfc8889bis-01 include: | ||||
| * Considerations on BUM traffic | ||||
| * Reference to RFC8321bis for the fragmentation part | ||||
| * Revised section on "Delay Measurements on a Single-Packet Basis" | ||||
| * Revised section on "Timing Aspects" | ||||
| Changes in draft-fioccola-rfc8889bis-02 include: | ||||
| * Clarified the formula in the section on "Timing Aspects" to be | ||||
| aligned with RFC 8321 | ||||
| * Considerations on two-way delay measurements in both sections 8.1 | ||||
| and 8.2 on delay measurements | ||||
| * Clarified in section 4.1 on "Monitoring Network" that the | ||||
| description is done for one direction but it can easily be | ||||
| extended to all direction | ||||
| * New section on "Results of the Multipoint Alternate Marking | ||||
| Experiment" | ||||
| Changes in draft-fioccola-rfc8889bis-03 include: | ||||
| * Moved and renamed section on "Timing Aspects" as "Synchronization | ||||
| and Timing" | ||||
| * Renamed old section on "Multipoint Packet Loss" as "Network Packet | ||||
| Loss" | ||||
| * New section on "Multipoint Packet Loss Measurement" | ||||
| * Renamed section on "Multipoint Performance Measurement" as | ||||
| "Extension of the Method to Multipoint Flows" | ||||
| Changes in draft-fioccola-rfc8889bis-04/draft-ietf-ippm-rfc8889bis-00 | ||||
| include: | ||||
| * Revised section 5.1 on "Algorithm for Clusters Partition" | ||||
| Changes in draft-ietf-ippm-rfc8889bis-01 include: | ||||
| * New section on "Summary of Changes from RFC 8889" | ||||
| Changes in draft-ietf-ippm-rfc8889bis-02 include: | ||||
| * Revised sections on "Single- and Double-Marking Measurement", | ||||
| "Hashing Selection Method" and "Synchronization and Timing" | ||||
| * Revised references | The authors would like to thank Martin Duke and Tommy Pauly for their | |||
| assistance and their detailed and valuable reviews. | ||||
| Changes in draft-ietf-ippm-rfc8889bis-03 include: | Contributors | |||
| * Comments addressed from Last Call review | Greg Mirsky | |||
| Ericsson | ||||
| Email: gregimirsky@gmail.com | ||||
| * Renamed section 9 as "Recommendations for Deployment" | Tal Mizrahi | |||
| Changes in draft-ietf-ippm-rfc8889bis-04 include: | Huawei Technologies | |||
| Email: tal.mizrahi.phd@gmail.com | ||||
| * Comments addressed from Last Call review | Xiao Min | |||
| ZTE Corp. | ||||
| Email: xiao.min2@zte.com.cn | ||||
| Authors' Addresses | Authors' Addresses | |||
| Giuseppe Fioccola (editor) | Giuseppe Fioccola (editor) | |||
| Huawei Technologies | Huawei Technologies | |||
| Riesstrasse, 25 | Riesstrasse, 25 | |||
| 80992 Munich | 80992 Munich | |||
| Germany | Germany | |||
| Email: giuseppe.fioccola@huawei.com | Email: giuseppe.fioccola@huawei.com | |||
| End of changes. 139 change blocks. | ||||
| 426 lines changed or deleted | 345 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||