draft-ietf-ippm-multipoint-alt-mark-06.txt | draft-ietf-ippm-multipoint-alt-mark-07.txt | |||
---|---|---|---|---|
IPPM Working Group G. Fioccola, Ed. | IPPM Working Group G. Fioccola, Ed. | |||
Internet-Draft Huawei Technologies | Internet-Draft Huawei Technologies | |||
Intended status: Experimental M. Cociglio | Intended status: Experimental M. Cociglio | |||
Expires: August 27, 2020 Telecom Italia | Expires: September 10, 2020 Telecom Italia | |||
A. Sapio | A. Sapio | |||
R. Sisto | R. Sisto | |||
Politecnico di Torino | Politecnico di Torino | |||
February 24, 2020 | March 9, 2020 | |||
Multipoint Alternate Marking method for passive and hybrid performance | Multipoint Alternate Marking method for passive and hybrid performance | |||
monitoring | monitoring | |||
draft-ietf-ippm-multipoint-alt-mark-06 | draft-ietf-ippm-multipoint-alt-mark-07 | |||
Abstract | Abstract | |||
The Alternate Marking method, as presented in RFC 8321, can be | The Alternate Marking method, as presented in RFC 8321, can be | |||
applied only to point-to-point flows because it assumes that all the | applied only to point-to-point flows because it assumes that all the | |||
packets of the flow measured on one node are measured again by a | packets of the flow measured on one node are measured again by a | |||
single second node. This document aims to generalize and expand this | single second node. This document aims to generalize and expand this | |||
methodology to measure any kind of unicast flows, whose packets can | methodology to measure any kind of unicast flows, whose packets can | |||
follow several different paths in the network, in wider terms a | follow several different paths in the network, in wider terms a | |||
multipoint-to-multipoint network. For this reason the technique here | multipoint-to-multipoint network. For this reason the technique here | |||
skipping to change at page 1, line 42 ¶ | skipping to change at page 1, line 42 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on August 27, 2020. | This Internet-Draft will expire on September 10, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 23 ¶ | skipping to change at page 2, line 23 ¶ | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Correlation with RFC5644 . . . . . . . . . . . . . . . . . . 4 | 2. Correlation with RFC5644 . . . . . . . . . . . . . . . . . . 4 | |||
3. Flow classification . . . . . . . . . . . . . . . . . . . . . 4 | 3. Flow classification . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Multipoint Performance Measurement . . . . . . . . . . . . . 7 | 4. Multipoint Performance Measurement . . . . . . . . . . . . . 7 | |||
4.1. Monitoring Network . . . . . . . . . . . . . . . . . . . 7 | 4.1. Monitoring Network . . . . . . . . . . . . . . . . . . . 7 | |||
5. Multipoint Packet Loss . . . . . . . . . . . . . . . . . . . 8 | 5. Multipoint Packet Loss . . . . . . . . . . . . . . . . . . . 8 | |||
6. Network Clustering . . . . . . . . . . . . . . . . . . . . . 9 | 6. Network Clustering . . . . . . . . . . . . . . . . . . . . . 10 | |||
6.1. Algorithm for Cluster partition . . . . . . . . . . . . . 10 | 6.1. Algorithm for Cluster partition . . . . . . . . . . . . . 10 | |||
7. Timing Aspects . . . . . . . . . . . . . . . . . . . . . . . 13 | 7. Timing Aspects . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
8. Multipoint Delay and Delay Variation . . . . . . . . . . . . 15 | 8. Multipoint Delay and Delay Variation . . . . . . . . . . . . 15 | |||
8.1. Delay measurements on multipoint paths basis . . . . . . 15 | 8.1. Delay measurements on multipoint paths basis . . . . . . 16 | |||
8.1.1. Single Marking measurement . . . . . . . . . . . . . 15 | 8.1.1. Single Marking measurement . . . . . . . . . . . . . 16 | |||
8.2. Delay measurements on single packets basis . . . . . . . 15 | 8.2. Delay measurements on single packets basis . . . . . . . 16 | |||
8.2.1. Single and Double Marking measurement . . . . . . . . 15 | 8.2.1. Single and Double Marking measurement . . . . . . . . 16 | |||
8.2.2. Hashing selection method . . . . . . . . . . . . . . 16 | 8.2.2. Hashing selection method . . . . . . . . . . . . . . 17 | |||
9. An Intelligent Performance Management approach . . . . . . . 18 | 9. An Intelligent Performance Management approach . . . . . . . 18 | |||
10. Examples of application . . . . . . . . . . . . . . . . . . . 19 | 10. Examples of application . . . . . . . . . . . . . . . . . . . 20 | |||
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 | |||
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 | 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 | |||
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 | |||
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
14.1. Normative References . . . . . . . . . . . . . . . . . . 20 | 14.1. Normative References . . . . . . . . . . . . . . . . . . 21 | |||
14.2. Informative References . . . . . . . . . . . . . . . . . 20 | 14.2. Informative References . . . . . . . . . . . . . . . . . 21 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
1. Introduction | 1. Introduction | |||
The alternate marking method, as described in RFC 8321 [RFC8321], is | The alternate marking method, as described in RFC 8321 [RFC8321], is | |||
applicable to a point-to-point path; so the extension proposed in | applicable to a point-to-point path; so the extension proposed in | |||
this document explains the most general case of multipoint-to- | this document explains the most general case of multipoint-to- | |||
multipoint path and enables flexible and adaptive performance | multipoint path and enables flexible and adaptive performance | |||
measurements in a managed network. | measurements in a managed network. | |||
The Alternate Marking methodology described in RFC 8321 [RFC8321] has | The Alternate Marking methodology described in RFC 8321 [RFC8321] has | |||
skipping to change at page 5, line 28 ¶ | skipping to change at page 5, line 28 ¶ | |||
multipoint, while a multipoint-to-point can be the result of a | multipoint, while a multipoint-to-point can be the result of a | |||
matching on a single destination address. In case a selection rule | matching on a single destination address. In case a selection rule | |||
and its reverse are used for bidirectional measurements, they can | and its reverse are used for bidirectional measurements, they can | |||
correspond to a point-to-multipoint in one direction and a | correspond to a point-to-multipoint in one direction and a | |||
multipoint-to-point in the opposite direction. | multipoint-to-point in the opposite direction. | |||
In this way the flows to be monitored are selected into the | In this way the flows to be monitored are selected into the | |||
monitoring points using packet selection rules, that can also change | monitoring points using packet selection rules, that can also change | |||
the pattern of the monitored network. | the pattern of the monitored network. | |||
Note that, more in general, the flow can be defined at different | ||||
levels based on the encapsulation considered and additional | ||||
conditions that are not in the packet header can also be included as | ||||
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 of | |||
Figure 1. | Figure 1. | |||
point-to-point single path | point-to-point single path | |||
+------+ +------+ +------+ | +------+ +------+ +------+ | |||
---<> R1 <>----<> R2 <>----<> R3 <>--- | ---<> R1 <>----<> R2 <>----<> R3 <>--- | |||
+------+ +------+ +------+ | +------+ +------+ +------+ | |||
skipping to change at page 9, line 7 ¶ | skipping to change at page 9, line 7 ¶ | |||
The same is applicable also for the delay but it will be described in | The same is applicable also for the delay but it will be described in | |||
the following sections. | the following sections. | |||
5. Multipoint Packet Loss | 5. Multipoint Packet Loss | |||
Since all the packets of the considered flow leaving the network have | Since all the packets of the considered flow leaving the network have | |||
previously entered the network, the number of packets counted by all | previously entered the network, the number of packets counted by all | |||
the input nodes is always greater or equal than the number of packets | the input nodes is always greater or equal than the number of packets | |||
counted by all the output nodes. | counted by all the output nodes. | |||
And in case of no packet loss occurring in the marking period, if all | The assumption is the use of the Alternate Marking Method. And in | |||
the input and output points of the network domain to be monitored are | 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 | ||||
measurement points, the sum of the number of packets on all the | measurement points, the sum of the number of packets on all the | |||
ingress interfaces equals the number on egress interfaces for the | ingress interfaces equals the number on egress interfaces for the | |||
monitored flow. In this circumstance, if no packet loss occurs, the | monitored flow. In this circumstance, if no packet loss occurs, the | |||
intermediate measurement points have only the task to split the | intermediate measurement points have only the task to split the | |||
measurement. | measurement. | |||
It is possible to define the Network Packet Loss 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 | |||
skipping to change at page 10, line 38 ¶ | skipping to change at page 10, line 44 ¶ | |||
criteria adopted. | criteria adopted. | |||
Moreover, sometimes Clusters can be optionally simplified. For | Moreover, sometimes Clusters can be optionally simplified. For | |||
example when two monitored interfaces are divided by a single router | example when two monitored interfaces are divided by a single router | |||
(one is the input interface and the other is the output interface and | (one is the input interface and the other is the output interface and | |||
the router has only these two interfaces), instead of counting | the router has only these two interfaces), instead of counting | |||
exactly twice, upon entering and leaving, it is possible to consider | exactly twice, upon entering and leaving, it is possible to consider | |||
a single measurement point (in this case we do not care of the | a single measurement point (in this case we do not care of the | |||
internal packet loss of the router). | internal packet loss of the router). | |||
It is worth highlighting that it might also be convenient to define | ||||
Clusters based on the topological information and applicable to all | ||||
the possible flows in the monitored network. | ||||
6.1. Algorithm for Cluster partition | 6.1. Algorithm for Cluster partition | |||
A simple algorithm can be applied in order to split our monitoring | A simple algorithm can be applied in order to split our monitoring | |||
network into Clusters. It is a two-step algorithm: | network into Clusters. It is a two-step algorithm: | |||
o Group the links where there is the same starting node; | o Group the links where there is the same starting node; | |||
o Join the grouped links with at least one ending node in common. | o Join the grouped links with at least one ending node in common. | |||
After the application of the previous two steps, each one of the | After the application of the previous two steps, each one of the | |||
skipping to change at page 13, line 18 ¶ | skipping to change at page 13, line 33 ¶ | |||
Obviously, by combining some Clusters in a new connected subnetwork | Obviously, by combining some Clusters in a new connected subnetwork | |||
(called Super Cluster) the Packet Loss Rule is still true. | (called Super Cluster) the Packet Loss Rule is still true. | |||
In this way in a very large network there is no need to configure | In this way in a very large network there is no need to configure | |||
detailed filter criteria to inspect the traffic. You can check | detailed filter criteria to inspect the traffic. You can check | |||
multipoint network and only in case of problems you can go deep with | multipoint network and only in case of problems you can go deep with | |||
a step-by-step cluster analysis, but only for the cluster or | a step-by-step cluster analysis, but only for the cluster or | |||
combination of clusters where the problem happens. | combination of clusters where the problem happens. | |||
In summary, once defined a flow, the algorithm to build the Cluster | ||||
Partition considers all the possible links and nodes crossed by the | ||||
given flow, even if there is no traffic. It is based on topological | ||||
information. So, if the flow do not enter or traverse all the nodes, | ||||
the counters has a non-zero value for the involved nodes, while a | ||||
zero value for the other nodes without traffic, but, in the end all | ||||
the formulas are still valid. | ||||
The algorithm described above is an Iterative clustering algorithm, | The algorithm described above is an Iterative clustering algorithm, | |||
but it is also possible to apply a Recursive clustering algorithm by | but it is also possible to apply a Recursive clustering algorithm by | |||
using the node-node adjacency matrix representation. | using the node-node adjacency matrix representation. | |||
The complete and mathematical analysis of the possible Algorithms for | The complete and mathematical analysis of the possible Algorithms for | |||
Cluster partition, including the considerations in terms of | Cluster partition, including the considerations in terms of | |||
efficiency and a comparison between the different methods, is in the | efficiency and a comparison between the different methods, is in the | |||
paper [IEEE-ACM-ToN-MPNPM]. | paper [IEEE-ACM-ToN-MPNPM]. | |||
7. Timing Aspects | 7. Timing Aspects | |||
It is important to consider the timing aspects, since out of order | It is important to consider the timing aspects, since out of order | |||
packets happen and have to be handled as well as described in RFC | packets happen and have to be handled as well as described in RFC | |||
8321 [RFC8321]. But, in a multi-source situation an additional issue | 8321 [RFC8321]. But, in a multi-source situation an additional issue | |||
has to be considered. | has to be considered. With multipoint path, the egress nodes will | |||
receive alternate marked packets in random order from different | ||||
ingress nodes, and this must not affect the measurement. | ||||
So, if we analyse a multipoint-to-multipoint path with more than one | So, if we analyse 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 | |||
the start of the measurement, as reported in the following figure. | the start of the measurement, as reported in the following figure. | |||
Note that the mark switching approach based on a fixed timer is | Note that the mark switching approach based on a fixed timer is | |||
considered in this document. | considered in this document. | |||
time -> start stop | time -> start stop | |||
T(R1) |-------------| | T(R1) |-------------| | |||
T(R2) |-------------| | T(R2) |-------------| | |||
T(R3) |------------| | T(R3) |------------| | |||
Figure 4: Measurement Interval | Figure 4: Measurement Interval | |||
In the figure it is assumed that the node with the earliest clock | In the figure it is assumed that the node with the earliest clock | |||
(R1) identifies the right starting and ending time of the | (R1) identifies the right starting and ending time of the | |||
measurement, but it is just an assumption and other possibilities | measurement, but it is just an assumption and other possibilities | |||
could occurr. So, in this case, T(R1) is the measurement interval | could occur. So, in this case, T(R1) is the measurement interval and | |||
and its recognition is essential in order to be compatible and make | its recognition is essential in order to be compatible and make | |||
comparison with other active/passive/hybrid Packet Loss metrics. | comparison with other active/passive/hybrid Packet Loss metrics. | |||
Therefore, when we expand to multipoint-to-multipoint flows, we have | Therefore, when we expand to multipoint-to-multipoint flows, we have | |||
to consider that all source nodes mark the traffic and this adds more | to consider that all source nodes mark the traffic and this adds more | |||
complexity. | complexity. | |||
Regarding the timing aspects of the methodology, RFC 8321 [RFC8321] | Regarding the timing aspects of the methodology, RFC 8321 [RFC8321] | |||
already describes two contributions that are taken into account: the | already describes two contributions that are taken into account: the | |||
clock error between network devices and the network delay between | clock error between network devices and the network delay between | |||
measurement points. | measurement points. | |||
skipping to change at page 18, line 25 ¶ | skipping to change at page 19, line 5 ¶ | |||
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 can be split | The monitoring network can be considered as a whole or can be split | |||
in Clusters, that are the smallest subnetworks (group-to-group | in Clusters, that are the smallest subnetworks (group-to-group | |||
segments), maintaining the packet loss property for each subnetwork. | segments), maintaining the packet loss property for each subnetwork. | |||
They can also be combined in new connected subnetworks at different | They can also be combined in new connected subnetworks at different | |||
levels depending on the detail we want to achieve. | levels depending on the detail we want to achieve. | |||
An SDN Controller can calibrate Performance Measurements since it is | An SDN Controller or a Network Management System (NMS) can calibrate | |||
aware of the network topology. It can start without examining in | Performance Measurements since it is aware of the network topology. | |||
depth. In case of necessity (packet loss is measured or the delay is | It can start without examining in depth. In case of necessity | |||
too high), the filtering criteria could be immediately specified more | (packet loss is measured or the delay is too high), the filtering | |||
in order to perform a partition of the network by using Clusters and/ | criteria could be immediately specified more in order to perform a | |||
or different combinations of Clusters. In this way the problem can | partition of the network by using Clusters and/or different | |||
be localized in a specific Cluster or in a single combination of | combinations of Clusters. In this way the problem can be localized | |||
Clusters and a more detailed analysis can be performed step-by-step | in a specific Cluster or in a single combination of Clusters and a | |||
by successive approximation up to a point-to-point flow detailed | more detailed analysis can be performed step-by-step by successive | |||
analysis. | approximation up to a point-to-point flow detailed analysis. | |||
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 the some filters or rules | The Network Zooming approach implies that the some filters or rules | |||
are changed and there is a transient time to wait once the new | are changed and there is a transient time to wait once the new | |||
network configuration takes effect and it can be determined by the | network configuration takes effect and it can be determined by the | |||
Network Orchestrator/Controller, based on the network conditions. | Network Orchestrator/Controller, based on the network conditions. | |||
For example, if the Network Zooming identifies the performance | ||||
problem for the traffic coming from a specific source, we need to | ||||
recognize the marked signal from this specific source node and its | ||||
relative path. For this purpose we can activate all the available | ||||
measurement points and specify better the flow filter criteria (i.e. | ||||
5-tuple). As an alternative, it can be enough to select packets from | ||||
the specific source for delay measurements, and in this case it is | ||||
possible to apply the hashing technique as mentioned in the previous | ||||
sections. | ||||
[I-D.song-opsawg-ifit-framework] defines an architecture where the | [I-D.song-opsawg-ifit-framework] defines an architecture where the | |||
centralized Data Collector and Network Management can apply the | centralized Data Collector and Network Management can apply the | |||
intelligent and flexible Alternate Marking algorithm as previously | intelligent and flexible Alternate Marking algorithm as previously | |||
described. | described. | |||
As for RFC 8321 [RFC8321], it is possible to classify the traffic and | As for RFC 8321 [RFC8321], it is possible to classify the traffic and | |||
mark a portion of the total traffic. For each period the packet rate | mark a portion of the total traffic. For each period the packet rate | |||
and bandwidth are calculated from the number of packets. In this way | and bandwidth are calculated from the number of packets. In this way | |||
the Network Orchestrator becomes aware if the traffic rate overcomes | the Network Orchestrator becomes aware if the traffic rate overcomes | |||
limits. In addition more precision can be obtained by reducing the | limits. In addition more precision can be obtained by reducing the | |||
skipping to change at page 20, line 9 ¶ | skipping to change at page 20, line 47 ¶ | |||
o Enterprise SD-WAN: SD-WAN allows to connect remote branch offices | o Enterprise SD-WAN: SD-WAN allows to connect remote branch offices | |||
to Data Centers and build higher-performance WANs. A centralized | to Data Centers and build higher-performance WANs. A centralized | |||
controller is used to set policies and prioritize traffic. The | controller is used to set policies and prioritize traffic. The | |||
SD-WAN takes into account these policies and the availability of | SD-WAN takes into account these policies and the availability of | |||
network bandwidth to route traffic. This helps ensure that | network bandwidth to route traffic. This helps ensure that | |||
application performance meets service level agreements (SLAs). | application performance meets service level agreements (SLAs). | |||
This methodology can also help the path selection for the WAN | This methodology can also help the path selection for the WAN | |||
connection based on per Cluster and per flow performance. | connection based on per Cluster and per flow performance. | |||
Note that the list is just an example and it is not exhaustive. More | ||||
applications are possible. | ||||
11. Security Considerations | 11. Security Considerations | |||
This document specifies a method to perform measurements that does | This document specifies a method to perform measurements that does | |||
not directly affect Internet security nor applications that run on | not directly affect Internet security nor applications that run on | |||
the Internet. However, implementation of this method must be mindful | the Internet. However, implementation of this method must be mindful | |||
of security and privacy concerns, as explained in RFC 8321 [RFC8321]. | of security and privacy concerns, as explained in RFC 8321 [RFC8321]. | |||
12. Acknowledgements | 12. Acknowledgements | |||
The authors would like to thank Al Morton, Tal Mizrahi, Rachel Huang | The authors would like to thank Al Morton, Tal Mizrahi, Rachel Huang | |||
End of changes. 17 change blocks. | ||||
34 lines changed or deleted | 67 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |