idnits 2.17.1 draft-fioccola-ippm-multipoint-alt-mark-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8321], [RFC5644]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 4, 2018) is 2146 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 8321 (Obsoleted by RFC 9341) == Outdated reference: A later version (-05) exists of draft-mizrahi-ippm-compact-alternate-marking-01 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group G. Fioccola, Ed. 3 Internet-Draft M. Cociglio 4 Intended status: Experimental Telecom Italia 5 Expires: December 6, 2018 A. Sapio 6 R. Sisto 7 Politecnico di Torino 8 June 4, 2018 10 Multipoint Alternate Marking method for passive and hybrid performance 11 monitoring 12 draft-fioccola-ippm-multipoint-alt-mark-03 14 Abstract 16 The Alternate Marking method, as presented in RFC 8321 [RFC8321], can 17 be applied only to point-to-point flows because it assumes that all 18 the packets of the flow measured on one node are measured again by a 19 single second node. This document aims to generalize and expand this 20 methodology to measure any kind of unicast flows, whose packets can 21 follow several different paths in the network, in wider terms a 22 multipoint-to-multipoint network. For this reason the technique here 23 described is called Multipoint Alternate Marking. Some definitions 24 here introduced extend the scope of RFC 5644 [RFC5644] in the context 25 of alternate marking schema. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 6, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Correlation with RFC5644 . . . . . . . . . . . . . . . . . . 4 69 3. Flow classification . . . . . . . . . . . . . . . . . . . . . 4 70 4. Multipoint Performance Measurement . . . . . . . . . . . . . 6 71 4.1. Monitoring Network . . . . . . . . . . . . . . . . . . . 7 72 5. Multipoint Packet Loss . . . . . . . . . . . . . . . . . . . 8 73 6. Network Clustering . . . . . . . . . . . . . . . . . . . . . 9 74 6.1. Algorithm for Cluster partition . . . . . . . . . . . . . 10 75 7. Multipoint Delay and Delay Variation . . . . . . . . . . . . 12 76 7.1. Delay measurements on multipoint paths basis . . . . . . 12 77 7.1.1. Single Marking measurement . . . . . . . . . . . . . 12 78 7.2. Delay measurements on single packets basis . . . . . . . 13 79 7.2.1. Single and Double Marking measurement . . . . . . . . 13 80 7.2.2. Hashing selection method . . . . . . . . . . . . . . 13 81 8. An SDN enabled Performance Management . . . . . . . . . . . . 15 82 9. Examples of application . . . . . . . . . . . . . . . . . . . 15 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 88 13.2. Informative References . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 The alternate marking method, as presented until now, is applicable 94 to a point-to-point path; so the extension proposed in this document 95 explains the most general case of multipoint-to-multipoint path and 96 enables flexible and adaptive performance measurements in a managed 97 network. 99 The Alternate Marking methodology described in RFC 8321 [RFC8321] has 100 the property to synchronize measurements in different points 101 maintaining the coherence of the counters. So it is possible to show 102 what is happening in every marking period for each monitored flow. 103 The monitoring parameters are the packet counter and timestamps of a 104 flow for each marking period. 106 There are some applications of the alternate marking method where 107 there are a lot of monitored flows and nodes. Multipoint Alternate 108 Marking aims to reduce these values and makes the performance 109 monitoring more flexible in case a detailed analysis is not needed. 111 For instance, by considering n measurement points and m monitored 112 flows, the order of magnitude of the packet counters for each time 113 interval is n*m*2 (1 per color). If both n and m are high values the 114 packet counters increase a lot and Multipoint Alternate Marking 115 offers a tool to control these parameters. 117 Alternate Marking method works by definition for multipoint to 118 multipoint paths but the network clustering approach presented in 119 this document is the formalization of how to implement this property 120 and it allows a flexible and optimized performance measurement 121 support. Note that Multipoint Alternate Marking is applied only to 122 unicast flows and not to multicast. 124 Without network clustering, it is possible to apply alternate marking 125 only for all the network or per single flow. Instead, with network 126 clustering, it is possible to use the network clusters partition at 127 different levels to perform the needed degree of detail. 129 In some circumstances it is possible to monitor a Multipoint Network 130 by analyzing the Network Clustering, without examining in depth. In 131 case there is packet loss or the delay is too high the filtering 132 criteria could be specified more in order to perform a detailed 133 analysis by using a different combination of clusters up to a per- 134 flow measurement as described in RFC 8321 [RFC8321]. 136 An application could be the Software Defined Network (SDN) paradigm 137 where the SDN Controllers are the brains of the network and can 138 manage flow control to the switches and routers and, in the same way, 139 can calibrate the performance measurements depending on the 140 necessity. An SDN Controller Application can orchestrate how deep 141 the network performance monitoring is setup. 143 2. Correlation with RFC5644 145 RFC 5644 [RFC5644] is limited to active measurements using a single 146 source packet or stream, and observations of corresponding packets 147 along the path (spatial), at one or more destinations (one-to-group), 148 or both. Instead, the scope of this memo is to define multiparty 149 metrics for passive and hybrid measurements in a group-to-group 150 topology with multiple sources and destinations. 152 RFC 5644 [RFC5644] introduces metric names that can be reused also 153 here but have to be extended and rephrased to be applied to the 154 alternate marking schema: 156 a. the multiparty metrics are not only one-to-group metrics but can 157 be also group-to-group metrics; 159 b. the spatial metrics, used for measuring the performance of 160 segments of a source to destination path, are applied here to 161 group-to-group segments (called Clusters). 163 3. Flow classification 165 A flow is identified by all the packets having a set of common 166 characteristics. This definition is inspired by RFC 7011 [RFC7011]. 168 As an example, by considering a flow as all the packets sharing the 169 same source IP address or the same destination IP address, it is easy 170 to understand that the resulting pattern will not be a point-to-point 171 connection, but a point-to-multipoint or multipoint-to-point 172 connection. 174 In general a flow can be defined by a set of selection rules used to 175 match a subset of the packets processed by the network device. These 176 rules specify a set of headers fields (Identification Fields) and the 177 relative values that must be found in matching packets. 179 The choice of the identification fields directly affects the type of 180 paths that the flow would follow in the network. In fact, it is 181 possible to relate a set of identification fields with the pattern of 182 the resulting graphs, as listed in Figure 1. 184 A TCP 5-tuple usually identifies flows following either a single path 185 or a point-to-point multipath (in case of load balancing). On the 186 contrary, a single source address selects flows following a point-to- 187 multipoint, while a multipoint-to-point can be the result of a 188 matching on a single destination address. In case a selection rule 189 and its reverse are used for bidirectional measurements, they can 190 correspond to a point-to-multipoint in one direction and a 191 multipoint-to-point in the opposite direction. 193 In this way the flows to be monitored are selected into the 194 monitoring points using packet selection rules, that can also change 195 the pattern of the monitored network. 197 The alternate marking method is applicable only to a single path (and 198 partially to a one-to-one multipath), so the extension proposed in 199 this document is suitable also for the most general case of 200 multipoint-to-multipoint, which embraces all the other patterns of 201 Figure 1. 203 point-to-point single path 204 +------+ +------+ +------+ 205 ---<> R1 <>----<> R2 <>----<> R3 <>--- 206 +------+ +------+ +------+ 208 point-to-point multipath 209 +------+ 210 <> R2 <> 211 / +------+ \ 212 / \ 213 +------+ / \ +------+ 214 ---<> R1 <> <> R4 <>--- 215 +------+ \ / +------+ 216 \ / 217 \ +------+ / 218 <> R3 <> 219 +------+ 221 point-to-multipoint 222 +------+ 223 <> R4 <>--- 224 / +------+ 225 +------+ / 226 <> R2 <> 227 / +------+ \ 228 +------+ / \ +------+ 229 ---<> R1 <> <> R5 <>--- 230 +------+ \ +------+ 231 \ +------+ 232 <> R3 <> 233 +------+ \ 234 \ +------+ 235 <> R6 <>--- 236 +------+ 238 multipoint-to-point 239 +------+ 240 ---<> R1 <> 241 +------+ \ 242 \ +------+ 243 <> R4 <> 244 / +------+ \ 245 +------+ / \ +------+ 246 ---<> R2 <> <> R4 <>--- 247 +------+ / +------+ 248 +------+ / 249 <> R5 <> 250 / +------+ 251 +------+ / 252 ---<> R3 <> 253 +------+ 255 multipoint-to-multipoint 256 +------+ +------+ 257 ---<> R1 <> <> R6 <>--- 258 +------+ \ / +------+ 259 \ +------+ / 260 <> R4 <> 261 +------+ \ 262 +------+ \ +------+ 263 ---<> R2 <> <> R7 <>--- 264 +------+ \ / +------+ 265 \ +------+ / 266 <> R5 <> 267 / +------+ \ 268 +------+ / \ +------+ 269 ---<> R3 <> <> R8 <>--- 270 +------+ +------+ 272 Figure 1: Flow classification 274 4. Multipoint Performance Measurement 276 By Using the "traditional" alternate marking method only point-to- 277 point paths can be monitored. To have an IP (TCP/UDP) flow that 278 follows a point-to-point path we have to define, with a specific 279 value, 5 identification fields (IP Source, IP Destination, Transport 280 Protocol, Source Port, Destination Port). 282 Multipoint Alternate Marking enables the performance measurement for 283 multipoint flows selected by identification fields without any 284 constraints (even the entire network production traffic). It is also 285 possible to use multiple marking points for the same monitored flow. 287 4.1. Monitoring Network 289 The Monitoring Network is deduced from the Production Network, by 290 identifying the nodes of the graph that are the measurement points, 291 and the links that are the connections between measurement points. 293 There are some techniques that can help with the building of the 294 monitoring network (as an example it is possible to mention 295 [I-D.amf-ippm-route]). 297 So a graph model of the monitoring network can be built according to 298 the alternate marking method: the monitored interfaces and links are 299 identified. Only the measurement points and links where the traffic 300 has flowed have to be represented in the graph. 302 The following figure shows a simple example of a Monitoring Network 303 graph: 305 +------+ 306 <> R6 <>--- 307 / +------+ 308 +------+ +------+ / 309 <> R2 <>---<> R4 <> 310 / +------+ \ +------+ \ 311 / \ \ +------+ 312 +------+ / +------+ \ +------+ <> R7 <>--- 313 ---<> R1 <>---<> R3 <>---<> R5 <> +------+ 314 +------+ \ +------+ \ +------+ \ 315 \ \ \ +------+ 316 \ \ <> R8 <>--- 317 \ \ +------+ 318 \ \ 319 \ \ +------+ 320 \ <> R9 <>--- 321 \ +------+ 322 \ 323 \ +------+ 324 <> R10 <>--- 325 +------+ 327 Figure 2: Monitoring Network Graph 329 Each monitoring point is characterized by the packet counter that 330 refers only to a marking period of the monitored flow. 332 The same is applicable also for the delay but it will be described in 333 the following sections. 335 5. Multipoint Packet Loss 337 Since all the packets of the considered flow leaving the network have 338 previously entered the network, the number of packets counted by all 339 the input nodes is always greater or equal than the number of packets 340 counted by all the output nodes. 342 And in case of no packet loss occurring in the marking period, if all 343 the input and output points of the network domain to be monitored are 344 measurement points, the sum of the number of packets on all the 345 ingress interfaces and on all the egress interfaces is the same. In 346 this circumstance, if no packet loss occurs, the intermediate 347 measurement points have only the task to split the measurement. 349 It is possible to define the Network Packet Loss (for 1 flow, for 1 350 period): <>. This is true for every packet 353 flow in each marking period. 355 The Monitored Network Packet Loss with n input nodes and m output 356 nodes is given by: 358 PL = (PI1 + PI2 +...+ PIn) - (PO1 + PO2 +...+ POm) 360 where: 362 PL is the Network Packet Loss (number of lost packets) 364 PIi is the Number of packets flowed through the i-th Input node in 365 this period 367 POj is the Number of packets flowed through the j-th Output node in 368 this period 370 The equation is applied on a per-time-interval basis. 372 6. Network Clustering 374 The previous Equation can determine the number of packets lost 375 globally in the monitored network, exploiting only the data provided 376 by the counters in the input and output nodes. 378 In addition it is also possible to leverage the data provided by the 379 other counters in the network to converge on the smallest 380 identifiable subnetworks where the losses occur. These subnetworks 381 are named Clusters. 383 A Cluster graph is a subnetwork of the entire Monitoring Network 384 graph that still satisfies the packet loss equation where PL in this 385 case is the number of packets lost in the Cluster. 387 For this reason a Cluster should contain all the arcs emanating from 388 its input nodes and all the arcs terminating at its output nodes. 389 This ensures that we can count all the packets (and only those) 390 exiting an input node again at the output node, whatever path they 391 follow. 393 In a completely monitored network (a network where every network 394 interface is monitored), each network device corresponds to a Cluster 395 and each physical link corresponds to two Clusters (one for each 396 direction). 398 Clusters can have different sizes depending on flow filtering 399 criteria adopted. 401 Moreover, sometimes Clusters can be optionally simplified. For 402 example when two monitored interfaces are divided by a single router 403 (one is the input interface and the other is the output interface and 404 the router has only these two interfaces), instead of counting 405 exactly twice, upon entering and leaving, it is possible to consider 406 a single measurement point (in this case we do not care of the 407 internal packet loss of the router). 409 6.1. Algorithm for Cluster partition 411 A simple algorithm can be applied in order to split our monitoring 412 network into Clusters. It is a two-step algorithm: 414 o Group the links where there is the same starting node; 416 o Join the grouped links with at least one ending node in common. 418 In our monitoring network graph example it is possible to identify 419 the Clusters partition by applying this two-step algorithm. 421 The first step identifies the following groups: 423 1. Group 1: (R1-R2), (R1-R3), (R1-R10) 425 2. Group 2: (R2-R4), (R2-R5) 427 3. Group 3: (R3-R5), (R3-R9) 429 4. Group 4: (R4-R6), (R4-R7) 431 5. Group 5: (R5-R8) 433 And then, the second step builds the Clusters partition (in 434 particular we can underline that Group 2 and Group 3 connect 435 together, since R5 is in common): 437 1. Cluster 1: (R1-R2), (R1-R3), (R1-R10) 439 2. Cluster 2: (R2-R4), (R2-R5), (R3-R5), (R3-R9) 441 3. Cluster 3: (R4-R6), (R4-R7) 443 4. Cluster 4: (R5-R8) 445 In the end the following 4 Clusters are obtained: 447 Cluster 1 448 +------+ 449 <> R2 <>--- 450 / +------+ 451 / 452 +------+ / +------+ 453 ---<> R1 <>---<> R3 <>--- 454 +------+ \ +------+ 455 \ 456 \ 457 \ 458 \ 459 \ 460 \ 461 \ 462 \ 463 \ +------+ 464 <> R10 <>--- 465 +------+ 467 Cluster 2 468 +------+ +------+ 469 ---<> R2 <>---<> R4 <>--- 470 +------+ \ +------+ 471 \ 472 +------+ \ +------+ 473 ---<> R3 <>---<> R5 <>--- 474 +------+ \ +------+ 475 \ 476 \ 477 \ 478 \ 479 \ +------+ 480 <> R9 <>--- 481 +------+ 483 Cluster 3 484 +------+ 485 <> R6 <>--- 486 / +------+ 487 +------+ / 488 ---<> R4 <> 489 +------+ \ 490 \ +------+ 491 <> R7 <>--- 492 +------+ 494 Cluster 4 495 +------+ 496 ---<> R5 <> 497 +------+ \ 498 \ +------+ 499 <> R8 <>--- 500 +------+ 502 Figure 3: Clusters example 504 There are Clusters with more than 2 nodes and two-nodes Clusters. In 505 the two-nodes Clusters the loss is on the link (Cluster 4). In more- 506 than-2-nodes Clusters the loss is on the Cluster but we cannot know 507 in which link (Cluster 1, 2, 3). 509 Obviously, by combining some Clusters in a new connected subnetwork 510 (called Super Cluster) the Packet Loss Rule is still true. 512 7. Multipoint Delay and Delay Variation 514 The same line of reasoning can be applied to Delay and Delay 515 Variation. It is important to highlight that both delay and delay 516 variation measurements make sense in a multipoint path. It is 517 possible to perform delay and delay variation measurements on 518 multipoint paths basis or on single packets basis: 520 o Delay measurements on multipoint paths basis means that the delay 521 value is representative of an entire multipoint path (e.g. whole 522 multipoint network, a cluster or a combination of clusters). 524 o Delay measurements on single packets basis means that you can use 525 multipoint path just to easily couple packets between inputs and 526 output nodes of a multipoint path, as it is described in the 527 following sections. 529 7.1. Delay measurements on multipoint paths basis 531 7.1.1. Single Marking measurement 533 Mean delay and mean delay variation measurements can also be 534 generalized to the case of multipoint flows. It is possible to 535 compute the average one-way delay of packets, in one block, in a 536 cluster or in the entire monitored network. 538 The average latency can be measured as the difference between the 539 weighted averages of the mean timestamps of the sets of output and 540 input nodes. 542 7.2. Delay measurements on single packets basis 544 7.2.1. Single and Double Marking measurement 546 Delay and delay variation measurements relative to a picked packet 547 (both single and double marked) can be performed in the Multipoint 548 scenario with some limitations: 550 Single marking based on the first/last packet of the interval 551 would not work, because it would not be possible to agree on the 552 first packet of the interval. 554 Double marking or multiplexed marking would work, but each 555 measurement would only give information about the delay of a 556 single path. However, by repeating the measurement multiple 557 times, it is possible to get information about all the paths in 558 the multipoint flow. 560 if we would perform a delay measurement for more than one picked 561 packet in the same marking period and, especially, if we want to get 562 delay mesurements on multipoint-to-multipoint basis, both single and 563 double marking method are not useful in the Multipoint scenario, 564 since they would not be representative of the entire flow. The 565 packets can follow different paths with various delays and in general 566 it can be very difficult to recognize marked packets in a multipoint- 567 to-multipoint path especially in case they are more than one per 568 period. 570 A desirable option is to monitor simultaneously all the paths of a 571 multipoint path in the same marking period and, for this purpose, 572 hashing can be used as reported in the next Section. 574 7.2.2. Hashing selection method 576 RFC 5474 [RFC5474] and RFC 5475 [RFC5475] introduce sampling and 577 filtering techniques for IP Packet Selection. 579 The hash-based selection methodologies for delay measurement can work 580 in a multipoint-to-multipoint path and can be used both coupled to 581 mean delay or stand alone. 583 [I-D.mizrahi-ippm-compact-alternate-marking] introduces how to use 584 the Hash method combined with alternate marking method for point-to- 585 point flows. It is also called Mixed Hashed Marking: the coupling of 586 marking method and hashing technique is very useful because the 587 marking batches anchor the samples selected with hashing and this 588 simplifies the correlation of the hashing packets along the path. 590 It is possible to use a basic hash or a dynamic hash method. One of 591 the challenges of the basic approach is that the frequency of the 592 sampled packets may vary considerably. For this reason the dynamic 593 approach has been introduced for point-to-point flow in order to have 594 the desired and almost fixed number of samples for each measurement 595 period. In the hash-based sampling, alternate marking is used to 596 create periods, so that hash-based samples are divided into batches, 597 allowing to anchor the selected samples to their period. Moreover in 598 the dynamic hash-based sampling, by dynamically adapting the length 599 of the hash value, the number of samples is bounded in each marking 600 period. This can be realized by choosing the maximum number of 601 samples (NMAX) to be catched in a marking period. The algorithm 602 starts with only few hash bits, that permit to select a greater 603 percentage of packets (e.g. with 0 bit of hash all the packets are 604 sampled, with 1 bit of hash half of the packets are sampled, and so 605 on). When the number of selected packets reaches NMAX, a hashing bit 606 is added. As a consequence, the sampling proceeds at half of the 607 original rate and also the packets already selected that don't match 608 the new hash are discarded. This step can be repeated iteratively. 609 It is assumed that each sample includes the timestamp (used for delay 610 measurement) and the hash value, allowing the management system to 611 match the samples received from the two measurement points. The 612 dynamic process statistically converges at the end of a marking 613 period and the final number of selected samples is between NMAX/2 and 614 NMAX. Therefore, the dynamic approach paces the sampling rate, 615 allowing to bound the number of sampled packets per sampling period. 617 In a multipoint environment the behaviour is similar to point-to 618 point flow. In particular, in the context of multipoint-to- 619 multipoint flow, the dynamic hash could be the solution to perform 620 delay measurements on specific packets and to overcome the single and 621 double marking limitations. 623 The management system receives the samples including the timestamps 624 and the hash value from all the MPs, and this happens both for point- 625 to-point and for multipoint-to-multipoint flow. Then the longest 626 hash used by MPs is deduced and it is applied to couple timestamps of 627 same packets of 2 MPs of a point-to-point path or of input and output 628 MPs of a Cluster (or a Super Cluster or the entire network). But 629 some considerations are needed: if there isn't packet loss the set of 630 input samples is always equal to the set of output samples. In case 631 of packet loss the set of output samples can be a subset of input 632 samples but the method still works because, at the end, it is easy to 633 couple the input and output timestamps of each catched packet using 634 the hash (in particular the "unused part of the hash" that should be 635 different for each packet). 637 In summary, the basic hash is logically similar to the double marking 638 method, and in case of point-to-point path double marking and basic 639 hash selection are equivalent. The dynamic approach scales the 640 number of measurements per interval, and it would seem that double 641 marking would also work well if we reduced the interval length, but 642 this can be done only for point-to-point path and not for multipoint 643 path, where we cannot couple the picked packets in a multipoint 644 paths. So, in general, if we want to get delay mesurements on 645 multipoint-to-multipoint path basis and want to select more than one 646 packet per period, double marking cannot be used because we could not 647 be able to couple the picked packets between input and output nodes. 648 On the other hand we can do that by using hashing selection. 650 8. An SDN enabled Performance Management 652 The Multipoint Alternate Marking framework that is introduced in this 653 document adds flexibility to PM because it can reduce the order of 654 magnitude of the packet counters. This allows an SDN Orchestrator to 655 supervise, control and manage PM in large networks. 657 The monitoring network can be considered as a whole or can be split 658 in Clusters, that are the smallest subnetworks (group-to-group 659 segments), maintaining the packet loss property for each subnetwork. 660 They can also be combined in new connected subnetworks at different 661 levels depending on the detail we want to achieve. 663 An SDN Controller can calibrate Performance Measurements. It can 664 start without examining in depth. In case of necessity (experimented 665 packet loss or the delay is too high), the filtering criteria could 666 be immediately specified more in order to perform a partition of the 667 network by using Clusters and/or different combinations of Clusters. 668 In this way the problem can be localized in a specific Cluster or in 669 a single combination of Clusters and a more detailed analysis can be 670 performed step-by-step by successive approximation up to a point-to- 671 point flow detailed analysis. 673 9. Examples of application 675 There are three application fields where it may be useful to take 676 into consideration the Multipoint Alternate Marking: 678 o VPN: The IP traffic is selected on IP source basis in both 679 directions. At the end point WAN interface all the output traffic 680 is counted in a single flow. The input traffic is composed by all 681 the other flows aggregated for source address. So, by considering 682 n end-points, the monitored flows are n (each flow with 1 ingress 683 point and (n-1) egress points) instead of n*(n-1) flows (each 684 flow, with 1 ingress point and 1 egress point); 686 o Mobile Backhaul: LTE traffic is selected, in the Up direction, by 687 the EnodeB source address and, in Down direction, by the EnodeB 688 destination address because the packets are sent from the Mobile 689 Packet Core to the EnodeB. So the monitored flow is only one per 690 EnodeB in both directions; 692 o OTT(Over The Top) services: The traffic is selected, in the Down 693 direction by the source addresses of the packets sent by OTT 694 Servers. In the opposite direction (Up) by the destination IP 695 addresses of the same Servers. So the monitoring is based on a 696 single flow per OTT Servers in both directions. 698 10. Security Considerations 700 tbc 702 11. Acknowledgements 704 tbc 706 12. IANA Considerations 708 tbc 710 13. References 712 13.1. Normative References 714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 715 Requirement Levels", BCP 14, RFC 2119, 716 DOI 10.17487/RFC2119, March 1997, 717 . 719 [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance 720 Metrics (IPPM): Spatial and Multicast", RFC 5644, 721 DOI 10.17487/RFC5644, October 2009, 722 . 724 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 725 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 726 "Alternate-Marking Method for Passive and Hybrid 727 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 728 January 2018, . 730 13.2. Informative References 732 [I-D.amf-ippm-route] 733 Alvarez-Hamelin, J., Morton, A., and J. Fabini, "Advanced 734 Unidirectional Route Assessment", draft-amf-ippm-route-01 735 (work in progress), October 2017. 737 [I-D.mizrahi-ippm-compact-alternate-marking] 738 Mizrahi, T., Arad, C., Fioccola, G., Cociglio, M., Chen, 739 M., Zheng, L., and G. Mirsky, "Compact Alternate Marking 740 Methods for Passive and Hybrid Performance Monitoring", 741 draft-mizrahi-ippm-compact-alternate-marking-01 (work in 742 progress), March 2018. 744 [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., 745 Grossglauser, M., and J. Rexford, "A Framework for Packet 746 Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474, 747 March 2009, . 749 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. 750 Raspall, "Sampling and Filtering Techniques for IP Packet 751 Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, 752 . 754 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 755 "Specification of the IP Flow Information Export (IPFIX) 756 Protocol for the Exchange of Flow Information", STD 77, 757 RFC 7011, DOI 10.17487/RFC7011, September 2013, 758 . 760 Authors' Addresses 762 Giuseppe Fioccola (editor) 763 Telecom Italia 764 Via Reiss Romoli, 274 765 Torino 10148 766 Italy 768 Email: giuseppe.fioccola@telecomitalia.it 770 Mauro Cociglio 771 Telecom Italia 772 Via Reiss Romoli, 274 773 Torino 10148 774 Italy 776 Email: mauro.cociglio@telecomitalia.it 777 Amedeo Sapio 778 Politecnico di Torino 779 Corso Duca degli Abruzzi, 24 780 Torino 10129 781 Italy 783 Email: amedeo.sapio@polito.it 785 Riccardo Sisto 786 Politecnico di Torino 787 Corso Duca degli Abruzzi, 24 788 Torino 10129 789 Italy 791 Email: riccardo.sisto@polito.it