idnits 2.17.1 draft-c2f-ippm-big-data-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 : ---------------------------------------------------------------------------- No issues found here. 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 (October 30, 2020) is 1274 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) -- Obsolete informational reference (is this intentional?): RFC 8889 (Obsoleted by RFC 9342) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group M. Cociglio 3 Internet-Draft Telecom Italia 4 Intended status: Experimental C. Corbo 5 Expires: May 3, 2021 Politecnico di Torino 6 G. Fioccola 7 Huawei Technologies 8 M. Nilo 9 Telecom Italia 10 R. Sisto 11 Politecnico di Torino 12 October 30, 2020 14 The Big Data Approach for Multipoint Alternate Marking method 15 draft-c2f-ippm-big-data-alt-mark-01 17 Abstract 19 This document introduces a new approach for the Alternate Marking 20 method. It is called Big Data Multipoint Alternate Marking method 21 and, starting from the methodology described in RFC 8321 and RFC 22 8889, it explains how to implement performance measurement analytics 23 on the Network Management System by analysing the raw data of the 24 network nodes. 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 https://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 May 3, 2021. 49 Copyright Notice 51 Copyright (c) 2020 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 (https://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. Marking Methods Classification . . . . . . . . . . . . . . . 3 68 3. Scenario and Background . . . . . . . . . . . . . . . . . . . 4 69 4. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Data collecting . . . . . . . . . . . . . . . . . . . . . 6 71 4.2. Sending data . . . . . . . . . . . . . . . . . . . . . . 8 72 4.3. Preprocessing . . . . . . . . . . . . . . . . . . . . . . 8 73 4.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 8.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 This document describes a scenario and a methodology that can be used 85 to get performance details from a monitored network. The approach is 86 inspired by the concepts illustrated in the Alternate Marking Method 87 (RFC 8321 [RFC8321]), Multipoint Alternate Marking Method (RFC 8889 88 [RFC8889]), and Hash Sampling (RFC 5474 [RFC5474] and RFC 5475 89 [RFC5475]). 91 In general the performance measurement results are based on a 92 posteriori calculation and the method is called Big Data Multipoint 93 Alternate Marking performance measurement. 95 The kinds of measurements are specified on the Network Management 96 System (NMS) and they can be split into two main categories: per 97 cluster and end-to-end. 99 o The per cluster approach includes all the details that refer to 100 each single cluster and provides a list of parameters that 101 characterize it (packet loss, mean delay). 103 o The end-to-end approach provides more general information about 104 the entire path (packet loss, mean delay). 106 The results can be provided on demand, in a non real-time processing 107 environment, and each one of them refers to a single monitoring 108 period, even if it is possible to broaden the search to more periods. 110 The basic mechanism of the Big data approach here introduced is the 111 Packet sampling. Packet sampling, which is performed through Hashing 112 Sampling technique (RFC 5474 [RFC5474] and RFC 5475 [RFC5475]) 113 applied on all incoming traffic, without any flow distinction. 114 Nevertheless, thanks to data postprocessing, results are split by 115 flow afterwards, since the storage system memorizes the fields of the 116 packet headers that identify flows. The NMS, in fact, requires, as 117 input parameters, the flow identification fields as well as the 118 timestamp. 120 The use of hash sampling improves packet tracking performance and 121 thus overall performance. It allows to track the path followed by 122 each packet without further efforts by the NMS. 124 2. Marking Methods Classification 126 [I-D.mizrahi-ippm-compact-alternate-marking] presents a summary of 127 the alternate marking methods, and discusses the trade-offs among 128 them. 130 The methodologies are classified as follows: 132 o Double Marking, 134 o Single Marking, 136 o Hash-based Marking. 138 Double Marking and Single Marking are described in RFC 8321 [RFC8321] 139 and RFC 8889 [RFC8889]. 141 While, Hash-based selection can be leveraged as a marking method, 142 allowing a zero-bit marking approach. As defined in RFC 5475 143 [RFC5475]: 145 A Hash Function h maps the Packet Content c, or some portion of 146 it, onto a Hash Range R. The packet is selected if h(c) is an 147 element of S, which is a subset of R called the Hash Selection 148 Range. 150 The Hash-Based marking requires the hash function and the set S to be 151 configured consistently across the measurement points. It is worth 152 mentioning that the duration between sampled packets depends only on 153 the hash value. 155 The single marking approach can be combined with hash-based sampling 156 as described in [I-D.mizrahi-ippm-compact-alternate-marking]: a 157 single marking bit is used for the loss measurement, while the hash- 158 based sampling is used to trigger delay measurement. In the same 159 way, the hash-based sampling can be used in multipoint network, and 160 this is explained in RFC 8889 [RFC8889]. 162 3. Scenario and Background 164 The service provider's network is made up of a main backbone network 165 surrounded by routers that handle customers traffic input and output. 166 The proposed methodology requires that the traffic is marked before 167 entering the backbone network, by means of the Alternate Marking 168 technique. The marking process can be made by the edge routers or by 169 the customers itself, keeping in mind that it requires that the 170 markers are synchronized. 172 ,..-..,_ 173 .'` '. 174 +--+ ,' `. +--+ 175 ----|R1| / Backbone \ |R2|---- 176 +--+/ Network \+--+ 177 [unmarked | | [unmarked 178 traffic] | [marked | traffic] 179 +--+\ traffic] /+--+ 180 ----|R3| \ / |R4|---- 181 +--+ `, ,' +--+ 182 '. ,'` 183 `''-''`` 185 Figure 1: Backbone Network 187 Only the marked traffic can be monitored. In case of one marking 188 bit, all the traffic must be marked. Instead, in case of two marking 189 bits, it is possible to mark the traffic partially, therefore the 190 results will not be affected by unmarked packets and will refer only 191 to the marked ones. 193 In order to apply the Alternate Marking methodology a time reference 194 period and a marking method must be fixed at the beginning. The time 195 reference period must consider the misalignment between the marking 196 source routers, clock error between network devices and the interval 197 we need to wait to avoid packets being out of order because of 198 network delay, as described in RFC 8321 [RFC8321] and RFC 8889 199 [RFC8889]. 201 A possible marking method could use two bits of the header and set 202 them to 0x01, to identify a period, and to 0x10 to identify the next 203 one. This allows to distinguish between marked traffic and unmarked 204 traffic, instead of using just one bit, which can can generate 205 misunderstanding between the unmarked traffic (that has the marked 206 bit set to 0 by default) and the marked traffic (that alternates 207 between 0x0 and 0x1, with 0x0 as marker value and not as default). 208 As an alternative, it is possible to use just one marking bit and 209 utilize a filter based on IP subnets to exclude the flows from 210 monitoring. The flows that do not have to be monitored are those 211 internal to the network (that usually have private IP addresses). 213 To enable the Big Data approach for monitoring, the network nodes 214 require a packet collector, that is the agent installed on board of 215 the network node that collects measurements, based on the configured 216 Packet sampling criteria. 218 The portion of network to be monitored must be delimited by routers 219 with packet collector installed on. The rest of the network cannot 220 be monitored even if the traffic is marked. So, the size of the 221 monitored network depends on the network devices placement. However, 222 the size of the network surrounded by packet collectors must be less 223 than or equal to the size of the network with marked traffic. 225 It is worth highlighting that, if one marking bit is used, the 226 requirement is that all the ingress traffic from the boundary nodes 227 must be marked. While, if two marking bits are used, the marking is 228 applied even on flow basis by the boundary nodes delimiting the 229 monitored network and it is easy to recognize the marked traffic 230 within the network. Moreover, both in the case of one and two 231 marking bits, we need to ensure that all the marked traffic, both 232 ingress and egress, comes through the monitoring nodes in order to 233 guarantee to properly monitor the network. 235 4. Methodology 237 The method described here consists of the following steps: 239 1. Data collecting; 241 2. Sending data; 243 3. Preprocessing; 245 4. Results. 247 ___________ _____________ 248 | Packet | | | 249 |collector 1| -----> | | 250 |___________| |Preprocessing| 251 | | 252 | | ___________ 253 ___________ | | | | 254 | Packet | | (Grouping) | | Clusters | 255 |collector 2| ------> | | <-- |information| 256 |___________| | | | | 257 | | |___________| 258 | Results | 259 ___________ | | 260 | Packet | | | 261 |collector 3| -------> | | 262 |___________| |_____________| 264 Figure 2: Outline of the Methodology 266 4.1. Data collecting 268 The Data collecting phase implies that, on board of the network 269 nodes, the packet collector analyses data passing through a network 270 interface. A packet collector needs to be placed into each router 271 interface we want to monitor. 273 The agent is configured by setting: 275 o the reference hash, 277 o the maximum number of packets to store, 279 o the alternate marking period duration, 280 o the one or the two alternate marking bits that identify the marked 281 flow, 283 o the interface to monitor, 285 o the flows to exclude from monitoring (i.e identified by header IP 286 fields): to be used only in case of one marking bit. 288 In general, if one alternate marking bit is available it is always 289 possible to identify the flow. In this case it must be used a filter 290 that excludes from monitoring the traffic flows that are not marked 291 in the network (e.g. IP addresses in use in the transit network that 292 often use private addresses) and, at the same time, it is needed to 293 make sure that all the ingress traffic is marked. This is a little 294 more complicated but helps to address the case of IPv4 where only one 295 bit could be available (i.e. so called unused bit). In this regard, 296 the flows to exclude from monitoring are needed only for the case of 297 one marking bit in order to identify the marked traffic. On the 298 other hand, these are not necessary in case of two marking bits 299 because it is already easy to identify the marked traffic and monitor 300 only this portion. 302 The Data collection is based on Hashing sampling described in RFC 303 5474 [RFC5474] and RFC 5475 [RFC5475]. 305 The process is recursive. Each incoming packet is hashed, compared 306 with the reference hash, and recorded if the number of bits that are 307 matching are the same of those required by the packet collector . 308 When the number of matched packets exceed the maximum number 309 requested in configuration, the number of bits to match is increased 310 by one. At this point all the previous stored packets could be 311 potentially discarded and must be rechecked. So data are stored 312 temporally and are subject to changes, discards and additions. After 313 the period ends, previous data are still subject to change, but after 314 a guard band (reasonably L/2 if L is the period duration) data are 315 stored permanently and ready to be sent. 317 Note that the packet collector (carried out with probe) selects the 318 packets based on the configured parameters, so it works with every 319 incoming packet, without distinction. This greatly increases the 320 probe configuration easiness. Otherwise the probe should save all 321 possible flows (potentially too many), which would be too expensive 322 for the device, and need to be reconfigured if a new flow is 323 available for performance monitoring. On the other hand, this 324 increases the amount of data collected. 326 Stored data include two kind of details: one refers to each single 327 packet and the other one is about aggregate measures. 329 The first set of data includes the fields that identify the flow 330 (IP header fields), packet hash, timestamp when the packets come 331 in, period to which data refer. 333 The second set of data reports network interface identification, 334 total counted packets, total hashed packets, mean timestamp based 335 on all the timestamp of all packets that passed through the 336 interface, period. 338 4.2. Sending data 340 The Sending data phase is separated from the previous one. Once the 341 data has been stored and collected as logs by the network device 342 following the provisions of the theoretical model, the sending system 343 has only the task of carrying data safely and reliably. It is 344 possible to use a synchronous mechanism, in which the sending system 345 periodically checks the availability of new data, or an asynchronous 346 mechanism. In the last case when a new batch of data is ready, an 347 alert wakes up the sending system that carries them to the 348 destination. 350 4.3. Preprocessing 352 The Preprocessing phase has two main goals: 354 o aggregate input data to produce a new record that is ready to be 355 postprocessed and that makes it easier to obtain performance 356 parameters; 358 o decrease the total amount of data to store. 360 Although this step is not mandatory, it is recommended to speed up 361 subsequent operations and to give a better shape to the stored data 362 in order to fit well with the last queries. 364 Preprocessing can be done after data has been stored into the NMS in 365 an iterative loop that parses that periodically or just before to be 366 sent to NMS, through a consolidator, that collects data that comes 367 from all network devices, parses them and then sends them to the NMS. 369 However, in this phase it is possible to group incoming data from all 370 devices and determine the path followed by each sampled packet. In 371 order to do that, if the data are grouped by hash and ordered them by 372 timestamp, it is possible to outline the path. 374 After providing to the NMS the topology information and Clusters 375 partition of the monitored network, it is also possible to track the 376 crossed cluster for each couple of sorted data, by analyzing the 377 interface ID available in the stored record and comparing them with 378 the edge that characterizes the clusters available in the monitored 379 network. 381 4.4. Results 383 The Results phase involves the preprocessed records lay into 384 database. When necessary the storage system can be queried, in a 385 deferred time. The records are organized to fit well with the 386 queries that care about timing and loss aspects. 388 Results are achieved by querying the storage system properly. 389 Certainly, input parameters that identify which flow we are 390 addressing are required. Additionally, time reference is needed to 391 select only the packets of interest. The Big data system is aware of 392 flow identification fields and performs packet flow grouping on the 393 fly. The results described below can refer to different flows, 394 depending on which parameters have been specified for the query. 396 It is possible to deduce the cluster mean delay D_i (mean delay 397 referred to cluster i), by analyzing each record, computing delay d_j 398 (delay referred to record j) as difference between the two available 399 timestamps, that correspond to the input timestamp (when the packet 400 has gone into the cluster) and the output timestamp (when the packet 401 has gone out of that cluster), and summing it with all other delays; 402 then the result is divided by the number of records that refer to the 403 same cluster: 405 D_i = [d_0 + d_1 +...+ d_(N_i-1)] / N_i 407 Where D_i is the mean delay related to cluster i, d_j the delay 408 related to record j, N_i the total number of records belonging to 409 cluster i. 411 It could also be computed the end-to-end mean delay AD as the sum of 412 all delays available in our database, and dividing it by all the 413 records: 415 AD = [ad_0 + ad_1 +...+ ad_(M-1)] / M 417 Where AD is the end-to-end mean delay, ad_j the delay related to 418 records j, and M the total number of records. 420 If necessary, after observing an unusual cluster delay, it could be 421 possible to compute also max/avg/min link delay, by analyzing records 422 again, and exploiting the difference between the two timestamps. 424 Additionally, also details about loss are available. Since the total 425 packets are counted by each node, the sum of the input packets must 426 be equal to the sum of the output packets inside each cluster. If 427 their difference is greater than 0, then a loss has occurred, and the 428 result is the total loss. The total packet loss per cluster: 430 PL_i = [p_(i,0) + p_(i,1) +...+ p_(i,K-1)] - [p_(o,0) + p_(o,1) +...+ 431 p_(o,L-1)] 433 Considering cluster i with K input nodes and L output nodes, the 434 calculation follows RFC 8889 [RFC8889]. 436 In the same way it is possible to get the entire packet loss, as the 437 sum of all the packet loss per cluster. The same measure can be 438 obtained by using only the hashed packets, but in this case, we get 439 an approximate measurement that might reflect or not the real one. 441 Notice that all these measurements refers to the flow we specify as 442 input of the query and that the specified flow can include or not all 443 the sampled packets (e.g. filter on ip_src=0.0.0.0/0, 444 ip_dst=0.0.0.0/0, port_src=/, port_dst=/, type=tcp, outlines a flow 445 that includes all the TCP packets in an IP network). 447 5. Security Considerations 449 This document specifies a method of performing measurements that does 450 not directly affect Internet security or applications that run on the 451 Internet. However, implementation of this method must be mindful of 452 security and privacy concerns, as explained in RFC 8321 [RFC8321] and 453 RFC 8889 [RFC8889]. 455 6. Acknowledgements 457 The authors would like to thank Guido Marchetto for the precious 458 contribution. 460 7. IANA Considerations 462 This document has no IANA actions 464 8. References 466 8.1. Normative References 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, 470 DOI 10.17487/RFC2119, March 1997, 471 . 473 8.2. Informative References 475 [I-D.mizrahi-ippm-compact-alternate-marking] 476 Mizrahi, T., Arad, C., Fioccola, G., Cociglio, M., Chen, 477 M., Zheng, L., and G. Mirsky, "Compact Alternate Marking 478 Methods for Passive and Hybrid Performance Monitoring", 479 draft-mizrahi-ippm-compact-alternate-marking-05 (work in 480 progress), July 2019. 482 [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., 483 Grossglauser, M., and J. Rexford, "A Framework for Packet 484 Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474, 485 March 2009, . 487 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. 488 Raspall, "Sampling and Filtering Techniques for IP Packet 489 Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, 490 . 492 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 493 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 494 "Alternate-Marking Method for Passive and Hybrid 495 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 496 January 2018, . 498 [RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto, 499 "Multipoint Alternate-Marking Method for Passive and 500 Hybrid Performance Monitoring", RFC 8889, 501 DOI 10.17487/RFC8889, August 2020, 502 . 504 Authors' Addresses 506 Mauro Cociglio 507 Telecom Italia 508 Via Reiss Romoli, 274 509 Torino 10148 510 Italy 512 Email: mauro.cociglio@telecomitalia.it 514 Calogero Corbo 515 Politecnico di Torino 517 Email: corbocalo94@gmail.com 518 Giuseppe Fioccola 519 Huawei Technologies 520 Riesstrasse, 25 521 Munich 80992 522 Germany 524 Email: giuseppe.fioccola@huawei.com 526 Massimo Nilo 527 Telecom Italia 528 Via Reiss Romoli, 274 529 Torino 10148 530 Italy 532 Email: massimo.nilo@telecomitalia.it 534 Riccardo Sisto 535 Politecnico di Torino 536 Corso Duca degli Abruzzi, 24 537 Torino 10129 538 Italy 540 Email: riccardo.sisto@polito.it