idnits 2.17.1 draft-fioccola-ippm-multipoint-alt-mark-00.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 ([I-D.ietf-ippm-alt-mark]), 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 29, 2017) is 2492 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-ippm-alt-mark-05 Summary: 1 error (**), 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, Ed. 4 Intended status: Experimental Telecom Italia 5 Expires: December 31, 2017 A. Sapio, Ed. 6 R. Sisto, Ed. 7 Politecnico di Torino 8 June 29, 2017 10 Multipoint Alternate Marking method for passive and hybrid performance 11 monitoring 12 draft-fioccola-ippm-multipoint-alt-mark-00 14 Abstract 16 The Alternate Marking method, as presented in 17 [I-D.ietf-ippm-alt-mark], can be applied only to point-to-point flows 18 because it assumes that all the packets of the flow measured on one 19 node are measured again by a single second node. This document aims 20 to generalize and expand this methodology to measure any kind of 21 unicast flows, whose packets can follow several different paths in 22 the network, in wider terms a multipoint-to-multipoint network. For 23 this reason the technique here described is called Multipoint 24 Alternate Marking. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 31, 2017. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Flow classification . . . . . . . . . . . . . . . . . . . . . 3 68 3. Multipoint Performance Measurement . . . . . . . . . . . . . 5 69 3.1. Monitoring Network . . . . . . . . . . . . . . . . . . . 6 70 3.2. Multipoint Packet Loss . . . . . . . . . . . . . . . . . 7 71 3.3. Network Clustering . . . . . . . . . . . . . . . . . . . 7 72 3.4. Multipoint Delay and Jitter . . . . . . . . . . . . . . . 10 73 3.4.1. Single and Double Marking measurement . . . . . . . . 10 74 3.4.2. Mean Delay and Jitter . . . . . . . . . . . . . . . . 10 75 3.4.3. Hash method . . . . . . . . . . . . . . . . . . . . . 10 76 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 8.2. Informative References . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 The Alternate Marking methodology described in 88 [I-D.ietf-ippm-alt-mark] has the property to synchronize measurements 89 in different points maintaining the coherence of the counters. So it 90 is possible to show what is happening in every marking period for 91 each monitored flow. The monitoring parameters are the packet 92 counter and timestamps of a flow for each marking period. 94 There are some applications of the alternate marking method where 95 there are a lot of monitored flows and nodes. 97 For instance, by considering n measurement points and n monitored 98 flows, the order of magnitude of the packet counters for each time 99 interval is n*n*2 (1 per color). 101 Multipoint Alternate Marking aims to reduce this value and makes the 102 performance monitoring more flexible in case a detailed analysis is 103 not needed. It can be applied only to unicast flows. 105 In some circumstances it is possible to monitor a Multipoint Network 106 by analyzing the Network Clustering, without examining in depth. In 107 case there is packet loss or the delay is too high the filtering 108 criteria could be specified more in order to perform a per flow 109 detailed analysis, as described in [I-D.ietf-ippm-alt-mark]. 111 An application could be the software defined network (SDN) paradigm 112 where the SDN Controllers are the brains of the network and can 113 manage flow control to the switches and routers and, in the same way, 114 can calibrate the performance measurements depending on the 115 necessity. 117 2. Flow classification 119 A flow is identified by all the packets having a set of common 120 characteristics. This definition is inspired by RFC 7011 [RFC7011]. 122 As an example, by considering a flow as all the packets sharing the 123 same source IP address or the same destination IP address, it is easy 124 to understand that the resulting pattern will not be a point-to-point 125 connection, but a point-to-multipoint or multipoint-to-point 126 connection. 128 In general a flow can be defined by a set of selection rules used to 129 match a subset of the packets processed by the network device. These 130 rules specify a set of headers fields (Identification Fields) and the 131 relative values that must be found in matching packets. 133 The choice of the identification fields directly affects the type of 134 paths that the flow would follow in the network. In fact, it is 135 possible to relate a set of identification fields with the pattern of 136 the resulting graphs, as listed in Figure 1. 138 point-to-point single path 139 +------+ +------+ +------+ 140 ---<> R1 <>----<> R2 <>----<> R3 <>--- 141 +------+ +------+ +------+ 143 point-to-point multipath 144 +------+ 145 <> R2 <> 146 / +------+ \ 147 / \ 148 +------+ / \ +------+ 149 ---<> R1 <> <> R4 <>--- 150 +------+ \ / +------+ 151 \ / 152 \ +------+ / 153 <> R3 <> 154 +------+ 156 point-to-multipoint 157 +------+ 158 <> R4 <>--- 159 / +------+ 160 +------+ / 161 <> R2 <> 162 / +------+ \ 163 +------+ / \ +------+ 164 ---<> R1 <> <> R5 <>--- 165 +------+ \ +------+ 166 \ +------+ 167 <> R3 <> 168 +------+ \ 169 \ +------+ 170 <> R6 <>--- 171 +------+ 173 multipoint-to-point 174 +------+ 175 ---<> R1 <> 176 +------+ \ 177 \ +------+ 178 <> R4 <> 179 / +------+ \ 180 +------+ / \ +------+ 181 ---<> R2 <> <> R4 <>--- 182 +------+ / +------+ 183 +------+ / 184 <> R5 <> 185 / +------+ 186 +------+ / 187 ---<> R3 <> 188 +------+ 190 multipoint-to-multipoint 191 +------+ +------+ 192 ---<> R1 <> <> R6 <>--- 193 +------+ \ / +------+ 194 \ +------+ / 195 <> R4 <> 196 +------+ \ 197 +------+ \ +------+ 198 ---<> R2 <> <> R7 <>--- 199 +------+ \ / +------+ 200 \ +------+ / 201 <> R5 <> 202 / +------+ \ 203 +------+ / \ +------+ 204 ---<> R3 <> <> R8 <>--- 205 +------+ +------+ 207 Figure 1: Flow classification 209 A TCP 5-tuple usually identifies flows following either a single path 210 or a point-to-point multipath (in case of load balancing). On the 211 contrary, a single source address selects flows following a point-to- 212 multipoint, while a multipoint-to-point can be the result of a 213 matching on a single destination address. In case a selection rule 214 and its reverse are used for bidirectional measurements, they can 215 correspond to a point-to-multipoint in one direction and a 216 multipoint-to-point in the opposite direction. 218 In this way the flows to be monitored are selected into the 219 monitoring points using packet selection rules, that can also change 220 the pattern of the monitored network. 222 The alternate marking method is applicable only to a single path (and 223 partially to a one-to-one multipath), so the extension proposed in 224 this document is suitable also for the most general case of 225 multipoint-to-multipoint, which embraces all the other patterns of 226 Figure 1. 228 3. Multipoint Performance Measurement 230 By Using the "traditional" alternate marking method only point-to- 231 point paths can be monitored. To have an IP (TCP/UDP) flow that 232 follows a point-to-point path we have to define, with a specific 233 value, 5 identification fields (IP Source, IP Destination, Transport 234 Protocol, Source Port, Destination Port). 236 Multipoint Alternate Marking enables the performance measurement for 237 multipoint flows selected by identification fields without any 238 constraints (even the entire network production traffic). It is also 239 possible to use multiple marking points for the same monitored flow. 241 3.1. Monitoring Network 243 The Monitoring Network is deduced from the Production Network, by 244 identifying the nodes of the graph, that are the measurement points, 245 and the links, that are the connections between measurement points. 247 So a model of the monitoring network can be built according to the 248 alternate marking method: the monitored interfaces and links are 249 identified. Only the measurement points and links where the traffic 250 has flowed have to be represented in the graph. 252 The following figure shows a simple example of a Monitoring Network 253 graph: 255 +------+ 256 <> R6 <>--- 257 / +------+ 258 +------+ +------+ / 259 <> R2 <>---<> R4 <> 260 / +------+ \ +------+ \ 261 / \ \ +------+ 262 +------+ / +------+ \ +------+ <> R7 <>--- 263 ---<> R1 <>---<> R3 <>---<> R5 <> +------+ 264 +------+ \ +------+ \ +------+ \ 265 \ \ \ +------+ 266 \ \ <> R8 <>--- 267 \ \ +------+ 268 \ \ 269 \ \ +------+ 270 \ <> R9 <>--- 271 \ +------+ 272 \ 273 \ +------+ 274 <> R10 <>--- 275 +------+ 277 Figure 2: Monitoring Network 279 Each monitoring point is characterized by the packet counter that 280 refers only to a marking period of the monitored flow. 282 The same is applicable also for the delay but it will be described in 283 the following sections. 285 3.2. Multipoint Packet Loss 287 Since all the packets of the considered flow leaving the network have 288 previously entered the network, the number of packets counted by all 289 the input nodes is always greater or equal than the number of packets 290 counted by all the output nodes. 292 And in case of no packet loss occurring in the marking period, if all 293 the input and output points of the network domain to be monitored are 294 measurement points, the number of packets is the same on all the 295 ingress interfaces and on all the egress interfaces. The 296 intermediate measurement points have only the task to split the 297 measurement. 299 It is possible to define the Network Packet Loss (for 1 flow, for 1 300 period): <>. This is true for every packet 303 flow in each marking period. 305 The Monitored Network Packet Loss with n input nodes and m output 306 nodes is given by: 308 PL = (PI1 + PI2 +...+ PIn) - (POi + PO2 +...+ POm) 310 where: 312 PL is the Network Packet Loss (number of lost packets) 314 PIi is the Number of packets flowed through the i-th Input node in 315 this period 317 POj is the Number of packets flowed through the j-th Output node in 318 this period 320 3.3. Network Clustering 322 The previous Equation can determine the number of packets lost 323 globally in the monitored network, exploiting only the data provided 324 by the counters in the input and output nodes. 326 In addition it is also possible to leverage the data provided by the 327 other counters in the network to converge on the smallest 328 identifiable subnetworks where the losses occur. These subnetworks 329 are named Clusters. 331 A Cluster is a subnetwork of the entire Monitoring Network graph that 332 still satisfies the packet loss equation where PL in this case is the 333 number of packets lost in the Cluster. 335 For this reason a Cluster should contain all the arcs emanating from 336 its input nodes and all the arcs terminating at its output nodes. 337 This ensures that we can count all the packets (and only those) 338 exiting an input node again at the output node, whatever path they 339 follow. 341 In a completely monitored network (a network where every network 342 interface is monitored), each network device corresponds to a Cluster 343 and each physical link corresponds to two Clusters (one for each 344 direction). 346 Clusters can have different sizes depending on flow filtering 347 criteria adopted. 349 Moreover, sometimes Clusters can be simplified; for example when two 350 monitored interfaces are divided by a single router (one is the input 351 interface and the other is the output interface and the router has 352 only these two interfaces), instead of counting exactly twice, upon 353 entering and leaving, in this case it is possible to consider a 354 single measurement point. 356 In our monitoring network graph example it is possible to identify 4 357 Clusters: 359 Cluster 1 360 +------+ 361 <> R2 <>--- 362 / +------+ 363 / 364 +------+ / +------+ 365 ---<> R1 <>---<> R3 <>--- 366 +------+ \ +------+ 367 \ 368 \ 369 \ 370 \ 371 \ 372 \ 373 \ 374 \ 375 \ +------+ 376 <> R10 <>--- 377 +------+ 379 Cluster 2 380 +------+ +------+ 381 ---<> R2 <>---<> R4 <>--- 382 +------+ \ +------+ 383 \ 384 +------+ \ +------+ 385 ---<> R3 <>---<> R5 <>--- 386 +------+ \ +------+ 387 \ 388 \ 389 \ 390 \ 391 \ +------+ 392 <> R9 <>--- 393 +------+ 395 Cluster 3 396 +------+ 397 <> R6 <>--- 398 / +------+ 399 +------+ / 400 ---<> R4 <> 401 +------+ \ 402 \ +------+ 403 <> R7 <>--- 404 +------+ 406 Cluster 4 407 +------+ 408 ---<> R5 <> 409 +------+ \ 410 \ +------+ 411 <> R8 <>--- 412 +------+ 414 Figure 3: Clusters example 416 There are Clusters with more than 2 nodes and two-nodes Clusters. In 417 the two-nodes Clusters the loss is on the link (Cluster 4). In more- 418 than-2-nodes Clusters the loss is on the Cluster but we cannot know 419 in which link (Cluster 1, 2, 3). 421 Obviously, by combining some Clusters in a new connected subnetwork 422 (called Super Cluster) the Packet Loss Rule is still true. 424 3.4. Multipoint Delay and Jitter 426 The same line of reasoning can be applied to Delay and Jitter. 428 3.4.1. Single and Double Marking measurement 430 Delay and Jitter measurements relative to a picked packet (both 431 single and double marked) cannot be performed in the Multipoint 432 scenario, since they would not be representative of the entire flow. 433 The packets can follow different paths with various delays and in 434 general it is very difficult to recognize a marked packet in a 435 multipoint-to-multipoint path. 437 3.4.2. Mean Delay and Jitter 439 Mean delay and jitter measurements can also be generalized to the 440 case of multipoint flows. It is possible to compute the average one- 441 way delay of packets, in one block, in a cluster or in the entire 442 monitored network. 444 The average latency can be measured as the difference between the 445 weighted averages of the mean timestamps of the sets of output and 446 input nodes. 448 3.4.3. Hash method 450 RFC 5475 [RFC5475] introduces sampling and filtering techniques for 451 IP Packet Selection. 453 Hash selection methodologies can work in a multipoint-to-multipoint 454 path and can be used both coupled to mean delay or stand alone. 456 4. Examples 458 There are three application fields where it may be useful to take 459 into consideration the Multipoint Alternate Marking: 461 o VPN: The IP traffic is selected on IP source basis in both 462 directions. At the end point WAN interface all the output traffic 463 is counted in a single flow. The input traffic is composed by all 464 the other flows aggregated for source address. So, by considering 465 n end-points, the monitored flows are n (each flow with 1 ingress 466 point and (n-1) egress points) instead of n*(n-1) flows (each 467 flow, with 1 ingress point and 1 egress point); 469 o Mobile Backhaul: LTE traffic is selected, in the Up direction, by 470 the EnodeB source address and, in Down direction, by the EnodeB 471 destination address because the packets are sent from the Mobile 472 Packet Core to the EnodeB. So the monitored flow is only one per 473 EnodeB in both directions; 475 o OTT(Over The Top) services: The traffic is selected, in the Down 476 direction by the source addresses of the packets sent by OTT 477 Servers. In the opposite direction (Up) by the destination IP 478 addresses of the same Servers. So the monitoring is based on a 479 single flow per OTT Servers in both directions. 481 5. Security Considerations 483 tbc 485 6. Acknowledgements 487 tbc 489 7. IANA Considerations 491 tbc 493 8. References 495 8.1. Normative References 497 [I-D.ietf-ippm-alt-mark] 498 Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., 499 Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 500 "Alternate Marking method for passive and hybrid 501 performance monitoring", draft-ietf-ippm-alt-mark-05 (work 502 in progress), June 2017. 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, 506 DOI 10.17487/RFC2119, March 1997, 507 . 509 8.2. Informative References 511 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. 512 Raspall, "Sampling and Filtering Techniques for IP Packet 513 Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, 514 . 516 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 517 "Specification of the IP Flow Information Export (IPFIX) 518 Protocol for the Exchange of Flow Information", STD 77, 519 RFC 7011, DOI 10.17487/RFC7011, September 2013, 520 . 522 Authors' Addresses 524 Giuseppe Fioccola (editor) 525 Telecom Italia 526 Via Reiss Romoli, 274 527 Torino 10148 528 Italy 530 Email: giuseppe.fioccola@telecomitalia.it 532 Mauro Cociglio (editor) 533 Telecom Italia 534 Via Reiss Romoli, 274 535 Torino 10148 536 Italy 538 Email: mauro.cociglio@telecomitalia.it 540 Amedeo Sapio (editor) 541 Politecnico di Torino 542 Corso Duca degli Abruzzi, 24 543 Torino 10129 544 Italy 546 Email: amedeo.sapio@polito.it 548 Riccardo Sisto (editor) 549 Politecnico di Torino 550 Corso Duca degli Abruzzi, 24 551 Torino 10129 552 Italy 554 Email: riccardo.sisto@polito.it