idnits 2.17.1 draft-ietf-ippm-multipoint-alt-mark-01.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 (March 4, 2019) is 1879 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-03 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 Huawei Technologies 4 Intended status: Experimental M. Cociglio 5 Expires: September 5, 2019 Telecom Italia 6 A. Sapio 7 R. Sisto 8 Politecnico di Torino 9 March 4, 2019 11 Multipoint Alternate Marking method for passive and hybrid performance 12 monitoring 13 draft-ietf-ippm-multipoint-alt-mark-01 15 Abstract 17 The Alternate Marking method, as presented in RFC 8321 [RFC8321], can 18 be applied only to point-to-point flows because it assumes that all 19 the packets of the flow measured on one node are measured again by a 20 single second node. This document aims to generalize and expand this 21 methodology to measure any kind of unicast flows, whose packets can 22 follow several different paths in the network, in wider terms a 23 multipoint-to-multipoint network. For this reason the technique here 24 described is called Multipoint Alternate Marking. Some definitions 25 here introduced extend the scope of RFC 5644 [RFC5644] in the context 26 of alternate marking schema. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 5, 2019. 50 Copyright Notice 52 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Correlation with RFC5644 . . . . . . . . . . . . . . . . . . 4 69 3. Flow classification . . . . . . . . . . . . . . . . . . . . . 4 70 4. Multipoint Performance Measurement . . . . . . . . . . . . . 7 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. Timing Aspects . . . . . . . . . . . . . . . . . . . . . . . 12 76 8. Multipoint Delay and Delay Variation . . . . . . . . . . . . 14 77 8.1. Delay measurements on multipoint paths basis . . . . . . 14 78 8.1.1. Single Marking measurement . . . . . . . . . . . . . 14 79 8.2. Delay measurements on single packets basis . . . . . . . 14 80 8.2.1. Single and Double Marking measurement . . . . . . . . 14 81 8.2.2. Hashing selection method . . . . . . . . . . . . . . 15 82 9. An SDN enabled Performance Management . . . . . . . . . . . . 17 83 10. Examples of application . . . . . . . . . . . . . . . . . . . 17 84 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 86 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 89 14.2. Informative References . . . . . . . . . . . . . . . . . 18 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 92 1. Introduction 94 The alternate marking method, as presented until now, is applicable 95 to a point-to-point path; so the extension proposed in this document 96 explains the most general case of multipoint-to-multipoint path and 97 enables flexible and adaptive performance measurements in a managed 98 network. 100 The Alternate Marking methodology described in RFC 8321 [RFC8321] has 101 the property to synchronize measurements in different points 102 maintaining the coherence of the counters. So it is possible to show 103 what is happening in every marking period for each monitored flow. 104 The monitoring parameters are the packet counter and timestamps of a 105 flow for each marking period. 107 There are some applications of the alternate marking method where 108 there are a lot of monitored flows and nodes. Multipoint Alternate 109 Marking aims to reduce these values and makes the performance 110 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 The approach presented in this document is applied only to unicast 118 flows and not to multicast. BUM (Boradcast Unkown Unicast Multicast) 119 traffic is not considered here, because traffic replication is not 120 covered by the Multipoint Alternate Marking method. Furthermore it 121 can be applicable to anycast flows. 123 Alternate Marking method works by definition for multipoint to 124 multipoint paths but the network clustering approach presented in 125 this document is the formalization of how to implement this property 126 and it allows a flexible and optimized performance measurement 127 support. 129 Without network clustering, it is possible to apply alternate marking 130 only for all the network or per single flow. Instead, with network 131 clustering, it is possible to use the network clusters partition at 132 different levels to perform the needed degree of detail. In some 133 circumstances it is possible to monitor a Multipoint Network by 134 analyzing the Network Clustering, without examining in depth. In 135 case of problems (packet loss is measured or the delay is too high) 136 the filtering criteria could be specified more in order to perform a 137 detailed analysis by using a different combination of clusters up to 138 a per-flow measurement as described in RFC 8321 [RFC8321]. 140 An application could be the Software Defined Network (SDN) paradigm 141 where the SDN Controllers are the brains of the network and can 142 manage flow control to the switches and routers and, in the same way, 143 can calibrate the performance measurements depending on the 144 necessity. An SDN Controller Application can orchestrate how deep 145 the network performance monitoring is setup. 147 2. Correlation with RFC5644 149 RFC 5644 [RFC5644] is limited to active measurements using a single 150 source packet or stream, and observations of corresponding packets 151 along the path (spatial), at one or more destinations (one-to-group), 152 or both. Instead, the scope of this memo is to define multiparty 153 metrics for passive and hybrid measurements in a group-to-group 154 topology with multiple sources and destinations. 156 RFC 5644 [RFC5644] introduces metric names that can be reused also 157 here but have to be extended and rephrased to be applied to the 158 alternate marking schema: 160 a. the multiparty metrics are not only one-to-group metrics but can 161 be also group-to-group metrics; 163 b. the spatial metrics, used for measuring the performance of 164 segments of a source to destination path, are applied here to 165 group-to-group segments (called Clusters). 167 3. Flow classification 169 An unicast flow is identified by all the packets having a set of 170 common characteristics. This definition is inspired by RFC 7011 171 [RFC7011]. 173 As an example, by considering a flow as all the packets sharing the 174 same source IP address or the same destination IP address, it is easy 175 to understand that the resulting pattern will not be a point-to-point 176 connection, but a point-to-multipoint or multipoint-to-point 177 connection. 179 In general a flow can be defined by a set of selection rules used to 180 match a subset of the packets processed by the network device. These 181 rules specify a set of headers fields (Identification Fields) and the 182 relative values that must be found in matching packets. 184 The choice of the identification fields directly affects the type of 185 paths that the flow would follow in the network. In fact, it is 186 possible to relate a set of identification fields with the pattern of 187 the resulting graphs, as listed in Figure 1. 189 A TCP 5-tuple usually identifies flows following either a single path 190 or a point-to-point multipath (in case of load balancing). On the 191 contrary, a single source address selects flows following a point-to- 192 multipoint, while a multipoint-to-point can be the result of a 193 matching on a single destination address. In case a selection rule 194 and its reverse are used for bidirectional measurements, they can 195 correspond to a point-to-multipoint in one direction and a 196 multipoint-to-point in the opposite direction. 198 In this way the flows to be monitored are selected into the 199 monitoring points using packet selection rules, that can also change 200 the pattern of the monitored network. 202 The alternate marking method is applicable only to a single path (and 203 partially to a one-to-one multipath), so the extension proposed in 204 this document is suitable also for the most general case of 205 multipoint-to-multipoint, which embraces all the other patterns of 206 Figure 1. 208 point-to-point single path 209 +------+ +------+ +------+ 210 ---<> R1 <>----<> R2 <>----<> R3 <>--- 211 +------+ +------+ +------+ 213 point-to-point multipath 214 +------+ 215 <> R2 <> 216 / +------+ \ 217 / \ 218 +------+ / \ +------+ 219 ---<> R1 <> <> R4 <>--- 220 +------+ \ / +------+ 221 \ / 222 \ +------+ / 223 <> R3 <> 224 +------+ 226 point-to-multipoint 227 +------+ 228 <> R4 <>--- 229 / +------+ 230 +------+ / 231 <> R2 <> 232 / +------+ \ 233 +------+ / \ +------+ 234 ---<> R1 <> <> R5 <>--- 235 +------+ \ +------+ 236 \ +------+ 237 <> R3 <> 238 +------+ \ 239 \ +------+ 240 <> R6 <>--- 241 +------+ 243 multipoint-to-point 244 +------+ 245 ---<> R1 <> 246 +------+ \ 247 \ +------+ 248 <> R4 <> 249 / +------+ \ 250 +------+ / \ +------+ 251 ---<> R2 <> <> R4 <>--- 252 +------+ / +------+ 253 +------+ / 254 <> R5 <> 255 / +------+ 256 +------+ / 257 ---<> R3 <> 258 +------+ 260 multipoint-to-multipoint 261 +------+ +------+ 262 ---<> R1 <> <> R6 <>--- 263 +------+ \ / +------+ 264 \ +------+ / 265 <> R4 <> 266 +------+ \ 267 +------+ \ +------+ 268 ---<> R2 <> <> R7 <>--- 269 +------+ \ / +------+ 270 \ +------+ / 271 <> R5 <> 272 / +------+ \ 273 +------+ / \ +------+ 274 ---<> R3 <> <> R8 <>--- 275 +------+ +------+ 277 Figure 1: Flow classification 279 The case of unicast flow is considered in the previous figure. 280 Anyway the anycast flow is also in scope because there is no 281 replication and only a single node from the anycast group receives 282 the traffic, so it can be viewed as a special case of unicast flow. 284 4. Multipoint Performance Measurement 286 By Using the "traditional" alternate marking method only point-to- 287 point paths can be monitored. To have an IP (TCP/UDP) flow that 288 follows a point-to-point path we have to define, with a specific 289 value, 5 identification fields (IP Source, IP Destination, Transport 290 Protocol, Source Port, Destination Port). 292 Multipoint Alternate Marking enables the performance measurement for 293 multipoint flows selected by identification fields without any 294 constraints (even the entire network production traffic). It is also 295 possible to use multiple marking points for the same monitored flow. 297 4.1. Monitoring Network 299 The Monitoring Network is deduced from the Production Network, by 300 identifying the nodes of the graph that are the measurement points, 301 and the links that are the connections between measurement points. 303 There are some techniques that can help with the building of the 304 monitoring network (as an example it is possible to mention 305 [I-D.amf-ippm-route]). In general there are different options: the 306 monitoring network can be obtained by considering all the possible 307 paths for the traffic or also by checking the traffic sometimes and 308 update the graph consequently. 310 So a graph model of the monitoring network can be built according to 311 the alternate marking method: the monitored interfaces and links are 312 identified. Only the measurement points and links where the traffic 313 has flowed have to be represented in the graph. 315 The following figure shows a simple example of a Monitoring Network 316 graph: 318 +------+ 319 <> R6 <>--- 320 / +------+ 321 +------+ +------+ / 322 <> R2 <>---<> R4 <> 323 / +------+ \ +------+ \ 324 / \ \ +------+ 325 +------+ / +------+ \ +------+ <> R7 <>--- 326 ---<> R1 <>---<> R3 <>---<> R5 <> +------+ 327 +------+ \ +------+ \ +------+ \ 328 \ \ \ +------+ 329 \ \ <> R8 <>--- 330 \ \ +------+ 331 \ \ 332 \ \ +------+ 333 \ <> R9 <>--- 334 \ +------+ 335 \ 336 \ +------+ 337 <> R10 <>--- 338 +------+ 340 Figure 2: Monitoring Network Graph 342 Each monitoring point is characterized by the packet counter that 343 refers only to a marking period of the monitored flow. 345 The same is applicable also for the delay but it will be described in 346 the following sections. 348 5. Multipoint Packet Loss 350 Since all the packets of the considered flow leaving the network have 351 previously entered the network, the number of packets counted by all 352 the input nodes is always greater or equal than the number of packets 353 counted by all the output nodes. 355 And in case of no packet loss occurring in the marking period, if all 356 the input and output points of the network domain to be monitored are 357 measurement points, the sum of the number of packets on all the 358 ingress interfaces and on all the egress interfaces is the same. In 359 this circumstance, if no packet loss occurs, the intermediate 360 measurement points have only the task to split the measurement. 362 It is possible to define the Network Packet Loss (for 1 flow, for 1 363 period): <>. This is true for every packet 366 flow in each marking period. 368 The Monitored Network Packet Loss with n input nodes and m output 369 nodes is given by: 371 PL = (PI1 + PI2 +...+ PIn) - (PO1 + PO2 +...+ POm) 373 where: 375 PL is the Network Packet Loss (number of lost packets) 377 PIi is the Number of packets flowed through the i-th Input node in 378 this period 380 POj is the Number of packets flowed through the j-th Output node in 381 this period 383 The equation is applied on a per-time-interval basis. 385 6. Network Clustering 387 The previous Equation can determine the number of packets lost 388 globally in the monitored network, exploiting only the data provided 389 by the counters in the input and output nodes. 391 In addition it is also possible to leverage the data provided by the 392 other counters in the network to converge on the smallest 393 identifiable subnetworks where the losses occur. These subnetworks 394 are named Clusters. 396 A Cluster graph is a subnetwork of the entire Monitoring Network 397 graph that still satisfies the packet loss equation where PL in this 398 case is the number of packets lost in the Cluster. 400 For this reason a Cluster should contain all the arcs emanating from 401 its input nodes and all the arcs terminating at its output nodes. 402 This ensures that we can count all the packets (and only those) 403 exiting an input node again at the output node, whatever path they 404 follow. 406 In a completely monitored network (a network where every network 407 interface is monitored), each network device corresponds to a Cluster 408 and each physical link corresponds to two Clusters (one for each 409 direction). 411 Clusters can have different sizes depending on flow filtering 412 criteria adopted. 414 Moreover, sometimes Clusters can be optionally simplified. For 415 example when two monitored interfaces are divided by a single router 416 (one is the input interface and the other is the output interface and 417 the router has only these two interfaces), instead of counting 418 exactly twice, upon entering and leaving, it is possible to consider 419 a single measurement point (in this case we do not care of the 420 internal packet loss of the router). 422 6.1. Algorithm for Cluster partition 424 A simple algorithm can be applied in order to split our monitoring 425 network into Clusters. It is a two-step algorithm: 427 o Group the links where there is the same starting node; 429 o Join the grouped links with at least one ending node in common. 431 In our monitoring network graph example it is possible to identify 432 the Clusters partition by applying this two-step algorithm. 434 The first step identifies the following groups: 436 1. Group 1: (R1-R2), (R1-R3), (R1-R10) 438 2. Group 2: (R2-R4), (R2-R5) 440 3. Group 3: (R3-R5), (R3-R9) 442 4. Group 4: (R4-R6), (R4-R7) 444 5. Group 5: (R5-R8) 446 And then, the second step builds the Clusters partition (in 447 particular we can underline that Group 2 and Group 3 connect 448 together, since R5 is in common): 450 1. Cluster 1: (R1-R2), (R1-R3), (R1-R10) 452 2. Cluster 2: (R2-R4), (R2-R5), (R3-R5), (R3-R9) 454 3. Cluster 3: (R4-R6), (R4-R7) 456 4. Cluster 4: (R5-R8) 458 In the end the following 4 Clusters are obtained: 460 Cluster 1 461 +------+ 462 <> R2 <>--- 463 / +------+ 464 / 465 +------+ / +------+ 466 ---<> R1 <>---<> R3 <>--- 467 +------+ \ +------+ 468 \ 469 \ 470 \ 471 \ 472 \ 473 \ 474 \ 475 \ 476 \ +------+ 477 <> R10 <>--- 478 +------+ 480 Cluster 2 481 +------+ +------+ 482 ---<> R2 <>---<> R4 <>--- 483 +------+ \ +------+ 484 \ 485 +------+ \ +------+ 486 ---<> R3 <>---<> R5 <>--- 487 +------+ \ +------+ 488 \ 489 \ 490 \ 491 \ 492 \ +------+ 493 <> R9 <>--- 494 +------+ 496 Cluster 3 497 +------+ 498 <> R6 <>--- 499 / +------+ 500 +------+ / 501 ---<> R4 <> 502 +------+ \ 503 \ +------+ 504 <> R7 <>--- 505 +------+ 507 Cluster 4 508 +------+ 509 ---<> R5 <> 510 +------+ \ 511 \ +------+ 512 <> R8 <>--- 513 +------+ 515 Figure 3: Clusters example 517 There are Clusters with more than 2 nodes and two-nodes Clusters. In 518 the two-nodes Clusters the loss is on the link (Cluster 4). In more- 519 than-2-nodes Clusters the loss is on the Cluster but we cannot know 520 in which link (Cluster 1, 2, 3). 522 In this way the calculation of packet loss can be made on Cluster 523 basis. Note that CIR(Committed Information Rate) and EIR(Excess 524 Information Rate) can also be deduced on Cluster basis. 526 Obviously, by combining some Clusters in a new connected subnetwork 527 (called Super Cluster) the Packet Loss Rule is still true. 529 In this way in a very large network there is no need to configure 530 detailed filter criteria to inspect the traffic. You can check 531 multipoint network and only in case of problems you can go deep with 532 a step-by-step cluster analysis, but only for the cluster or 533 combination of clusters where the problem happens. 535 7. Timing Aspects 537 The mark switching approach based on a fixed timer is considered in 538 this document. 540 So, if we analyze a multipoint-to-multipoint path with more than one 541 marking node, it is important to recognize the reference measurement 542 interval. In general the measurement interval for describing the 543 results is the interval of the marking node that is more aligned with 544 the start of the measurement, as reported in the following figure. 546 time -> start stop 547 T(R1) |-------------| 548 T(R2) |-------------| 549 T(R3) |------------| 551 Figure 4: Measurement Interval 553 T(R1) is the measurement interval and this is essential in order to 554 be compatible and make comparison with other active/passive/hybrid 555 Packet Loss metrics. 557 That is why, when we expand to multipoint-to-multipoint flows, we 558 have to consider that all source nodes mark the traffic. 560 Regarding the timing aspects of the methodology, RFC 8321 [RFC8321] 561 already describes two contributions that are taken into account: the 562 clock error between network devices and the network delay between 563 measurement points. 565 But we should now consider an additional contribution. Since all 566 source nodes mark the traffic, the source measurement intervals can 567 be of different lengths and with different offsets and this mismatch 568 m can be added to d, as shown in figure. 570 ...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB... 571 |<======================================>| 572 | L | 573 ...=========>|<==================><==================>|<==========... 574 | L/2 L/2 | 575 |<=><===>| |<===><=>| 576 m d | | d m 577 |<====================>| 578 available counting interval 580 Figure 5: Timing Aspects for Multipoint paths 582 So the misalignment between the marking source routers gives an 583 additional constraint and the value of m is added to d (that already 584 includes clock error and network delay). 586 In the end, the condition that must be satisfied to enable the method 587 to function properly is that the available counting interval must be 588 > 0, and that means: L - 2m - 2d > 0 for each measurement point on 589 the multipoint path. Therefore, the mismatch between measurement 590 intervals must satisfy this condition. 592 8. Multipoint Delay and Delay Variation 594 The same line of reasoning can be applied to Delay and Delay 595 Variation. It is important to highlight that both delay and delay 596 variation measurements make sense in a multipoint path. The Delay 597 Variation is calculated by considering the same packets selected for 598 measuring the Delay. 600 In general, it is possible to perform delay and delay variation 601 measurements on multipoint paths basis or on single packets basis: 603 o Delay measurements on multipoint paths basis means that the delay 604 value is representative of an entire multipoint path (e.g. whole 605 multipoint network, a cluster or a combination of clusters). 607 o Delay measurements on single packets basis means that you can use 608 multipoint path just to easily couple packets between inputs and 609 output nodes of a multipoint path, as it is described in the 610 following sections. 612 8.1. Delay measurements on multipoint paths basis 614 8.1.1. Single Marking measurement 616 Mean delay and mean delay variation measurements can also be 617 generalized to the case of multipoint flows. It is possible to 618 compute the average one-way delay of packets, in one block, in a 619 cluster or in the entire monitored network. 621 The average latency can be measured as the difference between the 622 weighted averages of the mean timestamps of the sets of output and 623 input nodes. 625 8.2. Delay measurements on single packets basis 627 8.2.1. Single and Double Marking measurement 629 Delay and delay variation measurements relative to only one picked 630 packet per period (both single and double marked) can be performed in 631 the Multipoint scenario with some limitations: 633 Single marking based on the first/last packet of the interval 634 would not work, because it would not be possible to agree on the 635 first packet of the interval. 637 Double marking or multiplexed marking would work, but each 638 measurement would only give information about the delay of a 639 single path. However, by repeating the measurement multiple 640 times, it is possible to get information about all the paths in 641 the multipoint flow. This can be done in case of point-to- 642 multipoint path but it is more difficult to achieve in case of 643 multipoint-to-multipoint path because of the multiple source 644 routers. 646 if we would perform a delay measurement for more than one picked 647 packet in the same marking period and, especially, if we want to get 648 delay mesurements on multipoint-to-multipoint basis, both single and 649 double marking method are not useful in the Multipoint scenario, 650 since they would not be representative of the entire flow. The 651 packets can follow different paths with various delays and in general 652 it can be very difficult to recognize marked packets in a multipoint- 653 to-multipoint path especially in case they are more than one per 654 period. 656 A desirable option is to monitor simultaneously all the paths of a 657 multipoint path in the same marking period and, for this purpose, 658 hashing can be used as reported in the next Section. 660 8.2.2. Hashing selection method 662 RFC 5474 [RFC5474] and RFC 5475 [RFC5475] introduce sampling and 663 filtering techniques for IP Packet Selection. 665 The hash-based selection methodologies for delay measurement can work 666 in a multipoint-to-multipoint path and can be used both coupled to 667 mean delay or stand alone. 669 [I-D.mizrahi-ippm-compact-alternate-marking] introduces how to use 670 the Hash method combined with alternate marking method for point-to- 671 point flows. It is also called Mixed Hashed Marking: the coupling of 672 marking method and hashing technique is very useful because the 673 marking batches anchor the samples selected with hashing and this 674 simplifies the correlation of the hashing packets along the path. 676 It is possible to use a basic hash or a dynamic hash method. One of 677 the challenges of the basic approach is that the frequency of the 678 sampled packets may vary considerably. For this reason the dynamic 679 approach has been introduced for point-to-point flow in order to have 680 the desired and almost fixed number of samples for each measurement 681 period. In the hash-based sampling, alternate marking is used to 682 create periods, so that hash-based samples are divided into batches, 683 allowing to anchor the selected samples to their period. Moreover in 684 the dynamic hash-based sampling, by dynamically adapting the length 685 of the hash value, the number of samples is bounded in each marking 686 period. This can be realized by choosing the maximum number of 687 samples (NMAX) to be catched in a marking period. The algorithm 688 starts with only few hash bits, that permit to select a greater 689 percentage of packets (e.g. with 0 bit of hash all the packets are 690 sampled, with 1 bit of hash half of the packets are sampled, and so 691 on). When the number of selected packets reaches NMAX, a hashing bit 692 is added. As a consequence, the sampling proceeds at half of the 693 original rate and also the packets already selected that don't match 694 the new hash are discarded. This step can be repeated iteratively. 695 It is assumed that each sample includes the timestamp (used for delay 696 measurement) and the hash value, allowing the management system to 697 match the samples received from the two measurement points. The 698 dynamic process statistically converges at the end of a marking 699 period and the final number of selected samples is between NMAX/2 and 700 NMAX. Therefore, the dynamic approach paces the sampling rate, 701 allowing to bound the number of sampled packets per sampling period. 703 In a multipoint environment the behaviour is similar to point-to 704 point flow. In particular, in the context of multipoint-to- 705 multipoint flow, the dynamic hash could be the solution to perform 706 delay measurements on specific packets and to overcome the single and 707 double marking limitations. 709 The management system receives the samples including the timestamps 710 and the hash value from all the MPs, and this happens both for point- 711 to-point and for multipoint-to-multipoint flow. Then the longest 712 hash used by MPs is deduced and it is applied to couple timestamps of 713 same packets of 2 MPs of a point-to-point path or of input and output 714 MPs of a Cluster (or a Super Cluster or the entire network). But 715 some considerations are needed: if there isn't packet loss the set of 716 input samples is always equal to the set of output samples. In case 717 of packet loss the set of output samples can be a subset of input 718 samples but the method still works because, at the end, it is easy to 719 couple the input and output timestamps of each catched packet using 720 the hash (in particular the "unused part of the hash" that should be 721 different for each packet). 723 In summary, the basic hash is logically similar to the double marking 724 method, and in case of point-to-point path double marking and basic 725 hash selection are equivalent. The dynamic approach scales the 726 number of measurements per interval, and it would seem that double 727 marking would also work well if we reduced the interval length, but 728 this can be done only for point-to-point path and not for multipoint 729 path, where we cannot couple the picked packets in a multipoint 730 paths. So, in general, if we want to get delay mesurements on 731 multipoint-to-multipoint path basis and want to select more than one 732 packet per period, double marking cannot be used because we could not 733 be able to couple the picked packets between input and output nodes. 734 On the other hand we can do that by using hashing selection. 736 9. An SDN enabled Performance Management 738 The Multipoint Alternate Marking framework that is introduced in this 739 document adds flexibility to PM because it can reduce the order of 740 magnitude of the packet counters. This allows an SDN Orchestrator to 741 supervise, control and manage PM in large networks. 743 The monitoring network can be considered as a whole or can be split 744 in Clusters, that are the smallest subnetworks (group-to-group 745 segments), maintaining the packet loss property for each subnetwork. 746 They can also be combined in new connected subnetworks at different 747 levels depending on the detail we want to achieve. 749 An SDN Controller can calibrate Performance Measurements. It can 750 start without examining in depth. In case of necessity (packet loss 751 is measured or the delay is too high), the filtering criteria could 752 be immediately specified more in order to perform a partition of the 753 network by using Clusters and/or different combinations of Clusters. 754 In this way the problem can be localized in a specific Cluster or in 755 a single combination of Clusters and a more detailed analysis can be 756 performed step-by-step by successive approximation up to a point-to- 757 point flow detailed analysis. 759 In addition an SDN Controller could also collect the measurement 760 history. 762 10. Examples of application 764 There are three application fields where it may be useful to take 765 into consideration the Multipoint Alternate Marking: 767 o VPN: The IP traffic is selected on IP source basis in both 768 directions. At the end point WAN interface all the output traffic 769 is counted in a single flow. The input traffic is composed by all 770 the other flows aggregated for source address. So, by considering 771 n end-points, the monitored flows are n (each flow with 1 ingress 772 point and (n-1) egress points) instead of n*(n-1) flows (each 773 flow, with 1 ingress point and 1 egress point); 775 o Mobile Backhaul: LTE traffic is selected, in the Up direction, by 776 the EnodeB source address and, in Down direction, by the EnodeB 777 destination address because the packets are sent from the Mobile 778 Packet Core to the EnodeB. So the monitored flow is only one per 779 EnodeB in both directions; 781 o OTT(Over The Top) services: The traffic is selected, in the Down 782 direction by the source addresses of the packets sent by OTT 783 Servers. In the opposite direction (Up) by the destination IP 784 addresses of the same Servers. So the monitoring is based on a 785 single flow per OTT Servers in both directions. 787 11. Security Considerations 789 This document specifies a method to perform measurements that does 790 not directly affect Internet security nor applications that run on 791 the Internet. However, implementation of this method must be mindful 792 of security and privacy concerns, as explained in RFC 8321 [RFC8321]. 794 12. Acknowledgements 796 The authors would like to thank Al Morton, Tal Mizrahi, Rachel Huang 797 for the precious contribution. 799 13. IANA Considerations 801 tbc 803 14. References 805 14.1. Normative References 807 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 808 Requirement Levels", BCP 14, RFC 2119, 809 DOI 10.17487/RFC2119, March 1997, 810 . 812 [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance 813 Metrics (IPPM): Spatial and Multicast", RFC 5644, 814 DOI 10.17487/RFC5644, October 2009, 815 . 817 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 818 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 819 "Alternate-Marking Method for Passive and Hybrid 820 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 821 January 2018, . 823 14.2. Informative References 825 [I-D.amf-ippm-route] 826 Alvarez-Hamelin, J., Morton, A., and J. Fabini, "Advanced 827 Unidirectional Route Assessment", draft-amf-ippm-route-01 828 (work in progress), October 2017. 830 [I-D.mizrahi-ippm-compact-alternate-marking] 831 Mizrahi, T., Arad, C., Fioccola, G., Cociglio, M., Chen, 832 M., Zheng, L., and G. Mirsky, "Compact Alternate Marking 833 Methods for Passive and Hybrid Performance Monitoring", 834 draft-mizrahi-ippm-compact-alternate-marking-03 (work in 835 progress), October 2018. 837 [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., 838 Grossglauser, M., and J. Rexford, "A Framework for Packet 839 Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474, 840 March 2009, . 842 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. 843 Raspall, "Sampling and Filtering Techniques for IP Packet 844 Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, 845 . 847 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 848 "Specification of the IP Flow Information Export (IPFIX) 849 Protocol for the Exchange of Flow Information", STD 77, 850 RFC 7011, DOI 10.17487/RFC7011, September 2013, 851 . 853 Authors' Addresses 855 Giuseppe Fioccola (editor) 856 Huawei Technologies 857 Riesstrasse, 25 858 Munich 80992 859 Germany 861 Email: giuseppe.fioccola@huawei.com 863 Mauro Cociglio 864 Telecom Italia 865 Via Reiss Romoli, 274 866 Torino 10148 867 Italy 869 Email: mauro.cociglio@telecomitalia.it 870 Amedeo Sapio 871 Politecnico di Torino 872 Corso Duca degli Abruzzi, 24 873 Torino 10129 874 Italy 876 Email: amedeo.sapio@polito.it 878 Riccardo Sisto 879 Politecnico di Torino 880 Corso Duca degli Abruzzi, 24 881 Torino 10129 882 Italy 884 Email: riccardo.sisto@polito.it