idnits 2.17.1 draft-ietf-ippm-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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 617: '...correlation mechanism SHOULD be in use...' RFC 2119 keyword, line 672: '... SHOULD provide a way to configure t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2016) is 2849 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC5905' is mentioned on line 640, but not defined == Missing Reference: 'IEEE1588' is mentioned on line 641, but not defined ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) == Outdated reference: A later version (-04) exists of draft-bryant-mpls-rfc6374-sfl-00 == Outdated reference: A later version (-05) exists of draft-bryant-mpls-sfl-framework-01 == Outdated reference: A later version (-12) exists of draft-ietf-bier-mpls-encapsulation-04 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-flow-ident-01 == Outdated reference: A later version (-02) exists of draft-ooamdt-rtgwg-oam-gap-analysis-01 == Outdated reference: A later version (-02) exists of draft-ooamdt-rtgwg-ooam-requirement-00 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Fioccola, Ed. 3 Internet-Draft A. Capello, Ed. 4 Intended status: Experimental M. Cociglio 5 Expires: January 8, 2017 L. Castaldelli 6 Telecom Italia 7 M. Chen, Ed. 8 L. Zheng, Ed. 9 Huawei Technologies 10 G. Mirsky, Ed. 11 Ericsson 12 T. Mizrahi, Ed. 13 Marvell 14 July 7, 2016 16 Alternate Marking method for passive performance monitoring 17 draft-ietf-ippm-alt-mark-01 19 Abstract 21 This document describes a passive method to perform packet loss, 22 delay and jitter measurements on live traffic. This method is based 23 on Alternate Marking (Coloring) technique. A report on the 24 operational experiment done at Telecom Italia is explained in order 25 to give an example and show the method applicability. This technique 26 can be applied in various situations as detailed in this document. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 8, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Overview of the method . . . . . . . . . . . . . . . . . . . 4 64 3. Detailed description of the method . . . . . . . . . . . . . 6 65 3.1. Packet loss measurement . . . . . . . . . . . . . . . . . 6 66 3.2. One-way delay measurement . . . . . . . . . . . . . . . . 10 67 3.2.1. Single marking methodology . . . . . . . . . . . . . 10 68 3.2.2. Average delay . . . . . . . . . . . . . . . . . . . . 11 69 3.2.3. Double marking methodology . . . . . . . . . . . . . 12 70 3.3. Delay variation measurement . . . . . . . . . . . . . . . 13 71 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.1. Synchronization . . . . . . . . . . . . . . . . . . . . . 13 73 4.2. Data Correlation . . . . . . . . . . . . . . . . . . . . 14 74 4.3. Packet Re-ordering . . . . . . . . . . . . . . . . . . . 15 75 5. Implementation and deployment . . . . . . . . . . . . . . . . 15 76 5.1. Report on the operational experiment at Telecom Italia . 15 77 5.1.1. Coloring the packets . . . . . . . . . . . . . . . . 17 78 5.1.2. Counting the packets . . . . . . . . . . . . . . . . 18 79 5.1.3. Collecting data and calculating packet loss . . . . . 19 80 5.1.4. Metric transparency . . . . . . . . . . . . . . . . . 20 81 5.2. IP flow performance measurement (IPFPM) . . . . . . . . . 20 82 5.3. Performance Measurement Marking Method in BIER Domain . . 20 83 5.4. Overlay OAM Passive Performance Measurement . . . . . . . 20 84 5.5. RFC6374 Use Case . . . . . . . . . . . . . . . . . . . . 21 85 5.6. Application to active performance measurement . . . . . . 21 86 6. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 21 87 7. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 21 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 89 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 91 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 94 12.2. Informative References . . . . . . . . . . . . . . . . . 25 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 97 1. Introduction 99 Nowadays, most of the traffic in Service Providers' networks carries 100 real time content. These contents are highly sensitive to packet 101 loss [RFC2680], while interactive contents are sensitive to delay 102 [RFC2679], and jitter [RFC3393]. 104 In view of this scenario, Service Providers need methodologies and 105 tools to monitor and measure network performances with an adequate 106 accuracy, in order to constantly control the quality of experience 107 perceived by their customers. On the other hand, performance 108 monitoring provides useful information for improving network 109 management (e.g. isolation of network problems, troubleshooting, 110 etc.). 112 A lot of work related to OAM, that includes also performance 113 monitoring techniques, has been done by Standards Developing 114 Organizations: [RFC7276] provides a good overview of existing OAM 115 mechanisms defined in IETF, ITU-T and IEEE. Considering IETF, a lot 116 of work has been done on fault detection and connectivity 117 verification, while a minor effort has been dedicated so far to 118 performance monitoring. The IPPM WG has defined standard metrics to 119 measure network performance; however, the methods developed in the WG 120 mainly refer to active measurement techniques. More recently, the 121 MPLS WG has defined mechanisms for measuring packet loss, one-way and 122 two-way delay, and delay variation in MPLS networks[RFC6374], but 123 their applicability to passive measurements has some limitations, 124 especially for pure connection-less networks. 126 The lack of adequate tools to measure packet loss with the desired 127 accuracy drove an effort to design a new method for the performance 128 monitoring of live traffic, possibly easy to implement and deploy. 129 The effort led to the method described in this document: basically, 130 it is a passive performance monitoring technique, potentially 131 applicable to any kind of packet based traffic, including Ethernet, 132 IP, and MPLS, both unicast and multicast. The method addresses 133 primarily packet loss measurement, but it can be easily extended to 134 one-way delay and delay variation measurements as well. It doesn't 135 require any protocol extension or interaction with existing 136 protocols, thus avoiding any interoperability issue. Even if the 137 method doesn't raise any specific need for standardization, it could 138 be further improved by means of some extension to existing protocols, 139 but this aspect is left for further study and it is out of the scope 140 of this document. 142 The method has been explicitly designed for passive measurements but 143 it can also be used with active probes. Passive measurements are 144 usually more easily understood by customers and provide a much better 145 accuracy, especially for packet loss measurements. 147 The method described in this document, also called PNPM (Packet 148 Network Performance Monitoring), has been invented and engineered in 149 Telecom Italia and it's currently being used in Telecom Italia's 150 network. The previous IETF drafts about this technique were: 151 [I-D.cociglio-mboned-multicast-pm] and [I-D.tempia-opsawg-p3m]. 152 There are some references to this methodology in other IETF works 153 (e.g. [I-D.ietf-mpls-flow-ident], [I-D.bryant-mpls-sfl-framework] 154 [I-D.bryant-mpls-rfc6374-sfl], [I-D.ietf-bier-mpls-encapsulation], 155 [I-D.mirsky-bier-pmmm-oam] 156 [I-D.chen-ippm-coloring-based-ipfpm-framework]). 158 This document is organized as follows: 160 o Section 2 gives an overview of the method, including a comparison 161 with different measurement strategies; 163 o Section 3 describes the method in detail; 165 o Section 4 reports considerations about synchronization, data 166 correlation and packet re-ordering; 168 o Section 5 reports examples of implementation and deployment of the 169 method. Furthermore the operational experiment done at Telecom 170 Italia is described; 172 o Section 8 includes some security aspects; 174 o Section 9 finally summarizes some concluding remarks. 176 2. Overview of the method 178 In order to perform packet loss measurements on a live traffic flow, 179 different approaches exist. The most intuitive one consists in 180 numbering the packets, so that each router that receives the flow can 181 immediately detect a packet missing. This approach, though very 182 simple in theory, is not simple to achieve: it requires the insertion 183 of a sequence number into each packet and the devices must be able to 184 extract the number and check it in real time. Such a task can be 185 difficult to implement on live traffic: if UDP is used as the 186 transport protocol, the sequence number is not available; on the 187 other hand, if a higher layer sequence number (e.g. in the RTP 188 header) is used, extracting that information from each packet and 189 process it in real time could overload the device. 191 An alternate approach is to count the number of packets sent on one 192 end, the number of packets received on the other end, and to compare 193 the two values. This operation is much simpler to implement, but 194 requires that the devices performing the measurement are in sync: in 195 order to compare two counters it is required that they refer exactly 196 to the same set of packets. Since a flow is continuous and cannot be 197 stopped when a counter has to be read, it could be difficult to 198 determine exactly when to read the counter. A possible solution to 199 overcome this problem is to virtually split the flow in consecutive 200 blocks by inserting periodically a delimiter so that each counter 201 refers exactly to the same block of packets. The delimiter could be 202 for example a special packet inserted artificially into the flow. 203 However, delimiting the flow using specific packets has some 204 limitations. First, it requires generating additional packets within 205 the flow and requires the equipment to be able to process those 206 packets. In addition, the method is vulnerable to out of order 207 reception of delimiting packets and, to a lesser extent, to their 208 loss. 210 The method proposed in this document follows the second approach, but 211 it doesn't use additional packets to virtually split the flow in 212 blocks. Instead, it "colors" the packets so that the packets 213 belonging to the same block will have the same color, whilst 214 consecutive blocks will have different colors. Each change of color 215 represents a sort of auto-synchronization signal that guarantees the 216 consistency of measurements taken by different devices along the 217 path. 219 Figure 1 represents a very simple network and shows how the method 220 can be used to measure packet loss on different network segments: by 221 enabling the measurement on several interfaces along the path, it is 222 possible to perform link monitoring, node monitoring or end-to-end 223 monitoring. The method is flexible enough to measure packet loss on 224 any segment of the network and can be used to isolate the faulty 225 element. 227 Traffic flow 228 ========================================================> 229 +------+ +------+ +------+ +------+ 230 ---<> R1 <>-----<> R2 <>-----<> R3 <>-----<> R4 <>--- 231 +------+ +------+ +------+ +------+ 232 . . . . . . 233 . . . . . . 234 . <------> <-------> . 235 . Node Packet Loss Link Packet Loss . 236 . . 237 <---------------------------------------------------> 238 End-to-End Packet loss 240 Figure 1: Available measurements 242 3. Detailed description of the method 244 This section describes in detail how the method operate. A special 245 emphasis is given to the measurement of packet loss, that represents 246 the core application of the method, but applicability to delay and 247 jitter measurements is also considered. 249 3.1. Packet loss measurement 251 The basic idea is to virtually split traffic flows into consecutive 252 blocks: each block represents a measurable entity unambiguously 253 recognizable by all network devices along the path. By counting the 254 number of packets in each block and comparing the values measured by 255 different network devices along the path, it is possible to measure 256 packet loss occurred in any single block between any two points. 258 As discussed in the previous section, a simple way to create the 259 blocks is to "color" the traffic (two colors are sufficient) so that 260 packets belonging to different consecutive blocks will have different 261 colors. Whenever the color changes, the previous block terminates 262 and the new one begins. Hence, all the packets belonging to the same 263 block will have the same color and packets of different consecutive 264 blocks will have different colors. The number of packets in each 265 block depends on the criterion used to create the blocks: if the 266 color is switched after a fixed number of packets, then each block 267 will contain the same number of packets (except for any losses); but 268 if the color is switched according to a fixed timer, then the number 269 of packets may be different in each block depending on the packet 270 rate. 272 The following figure shows how a flow looks like when it is split in 273 traffic blocks with colored packets. 275 A: packet with A coloring 276 B: packet with B coloring 278 | | | | | 279 | | Traffic flow | | 280 -------------------------------------------------------------------> 281 BBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA 282 -------------------------------------------------------------------> 283 ... | Block 5 | Block 4 | Block 3 | Block 2 | Block 1 284 | | | | | 286 Figure 2: Traffic coloring 288 Figure 3 shows how the method can be used to measure link packet loss 289 between two adjacent nodes. 291 Referring to the figure, let's assume we want to monitor the packet 292 loss on the link between two routers: router R1 and router R2. 293 According to the method, the traffic is colored alternatively with 294 two different colors, A and B. Whenever the color changes, the 295 transition generates a sort of square-wave signal, as depicted in the 296 following figure. 298 Color A ----------+ +-----------+ +---------- 299 | | | | 300 Color B +-----------+ +-----------+ 301 Block n ... Block 3 Block 2 Block 1 302 <---------> <---------> <---------> <---------> <---------> 304 Traffic flow 305 ===========================================================> 306 Color ...AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA... 307 ===========================================================> 309 Figure 3: Computation of link packet loss 311 Traffic coloring could be done by R1 itself or by an upward router. 312 R1 needs two counters, C(A)R1 and C(B)R1, on its egress interface: 313 C(A)R1 counts the packets with color A and C(B)R1 counts those with 314 color B. As long as traffic is colored A, only counter C(A)R1 will 315 be incremented, while C(B)R1 is not incremented; vice versa, when the 316 traffic is colored as B, only C(B)R1 is incremented. C(A)R1 and 317 C(B)R1 can be used as reference values to determine the packet loss 318 from R1 to any other measurement point down the path. Router R2, 319 similarly, will need two counters on its ingress interface, C(A)R2 320 and C(B)R2, to count the packets received on that interface and 321 colored with color A and B respectively. When an A block ends, it is 322 possible to compare C(A)R1 and C(A)R2 and calculate the packet loss 323 within the block; similarly, when the successive B block terminates, 324 it is possible to compare C(B)R1 with C(B)R2, and so on for every 325 successive block. 327 Likewise, by using two counters on R2 egress interface it is possible 328 to count the packets sent out of R2 interface and use them as 329 reference values to calculate the packet loss from R2 to any 330 measurement point down R2. 332 Using a fixed timer for color switching offers a better control over 333 the method: the (time) length of the blocks can be chosen large 334 enough to simplify the collection and the comparison of measures 335 taken by different network devices. It's preferable to read the 336 value of the counters not immediately after the color switch: some 337 packets could arrive out of order and increment the counter 338 associated to the previous block (color), so it is worth waiting for 339 some time. A safe choice is to wait L/2 time units (where L is the 340 duration for each block) after the color switch, to read the still 341 counter of the previous color, so the possibility to read a running 342 counter instead of a still one is minimized. The drawback is that 343 the longer the duration of the block, the less frequent the 344 measurement can be taken. 346 The following table shows how the counters can be used to calculate 347 the packet loss between R1 and R2. The first column lists the 348 sequence of traffic blocks while the other columns contain the 349 counters of A-colored packets and B-colored packets for R1 and R2. 350 In this example, we assume that the values of the counters are reset 351 to zero whenever a block ends and its associated counter has been 352 read: with this assumption, the table shows only relative values, 353 that is the exact number of packets of each color within each block. 354 If the values of the counters were not reset, the table would contain 355 cumulative values, but the relative values could be determined simply 356 by difference from the value of the previous block of the same color. 358 The color is switched on the basis of a fixed timer (not shown in the 359 table), so the number of packets in each block is different. 361 +-------+--------+--------+--------+--------+------+ 362 | Block | C(A)R1 | C(B)R1 | C(A)R2 | C(B)R2 | Loss | 363 +-------+--------+--------+--------+--------+------+ 364 | 1 | 375 | 0 | 375 | 0 | 0 | 365 | | | | | | | 366 | 2 | 0 | 388 | 0 | 388 | 0 | 367 | | | | | | | 368 | 3 | 382 | 0 | 381 | 0 | 1 | 369 | | | | | | | 370 | 4 | 0 | 377 | 0 | 374 | 3 | 371 | | | | | | | 372 | ... | ... | ... | ... | ... | ... | 373 | | | | | | | 374 | n | 0 | 387 | 0 | 387 | 0 | 375 | | | | | | | 376 | n+1 | 379 | 0 | 377 | 0 | 2 | 377 +-------+--------+--------+--------+--------+------+ 379 Table 1: Evaluation of counters for packet loss measurements 381 During an A block (blocks 1, 3 and n+1), all the packets are 382 A-colored, therefore the C(A) counters are incremented to the number 383 seen on the interface, while C(B) counters are zero. Vice versa, 384 during a B block (blocks 2, 4 and n), all the packets are B-colored: 385 C(A) counters are zero, while C(B) counters are incremented. 387 When a block ends (because of color switching) the relative counters 388 stop incrementing and it is possible to read them, compare the values 389 measured on router R1 and R2 and calculate the packet loss within 390 that block. 392 For example, looking at the table above, during the first block 393 (A-colored), C(A)R1 and C(A)R2 have the same value (375), which 394 corresponds to the exact number of packets of the first block (no 395 loss). Also during the second block (B-colored) R1 and R2 counters 396 have the same value (388), which corresponds to the number of packets 397 of the second block (no loss). During blocks three and four, R1 and 398 R2 counters are different, meaning that some packets have been lost: 399 in the example, one single packet (382-381) was lost during block 400 three and three packets (377-374) were lost during block four. 402 R1 and R2 require a clock error less than +/-L/2 time units, where L 403 is the time duration of the block. In this way each colored packet 404 can be assigned to the right block by each router. This is because 405 the minimum time distance between two packets of the same color but 406 belonging to different blocks is L time units. 408 The method applied to R1 and R2 can be extended to any other router 409 and applied to more complex networks, as far as the measurement is 410 enabled on the path followed by the traffic flow(s) being observed. 412 3.2. One-way delay measurement 414 The same principle used to measure packet loss can be applied also to 415 one-way delay measurement. There are three alternatives, as 416 described hereinafter. 418 3.2.1. Single marking methodology 420 The alternation of colors can be used as a time reference to 421 calculate the delay. Whenever the color changes (that means that a 422 new block has started) a network device can store the timestamp of 423 the first packet of the new block; that timestamp can be compared 424 with the timestamp of the same packet on a second router to compute 425 packet delay. Considering Figure 4, R1 stores a timestamp TS(A1)R1 426 when it sends the first packet of block 1 (A-colored), a timestamp 427 TS(B2)R1 when it sends the first packet of block 2 (B-colored) and so 428 on for every other block. R2 performs the same operation on the 429 receiving side, recording TS(A1)R2, TS(B2)R2 and so on. Since the 430 timestamps refer to specific packets (the first packet of each block) 431 we are sure that timestamps compared to compute delay refer to the 432 same packets. By comparing TS(A1)R1 with TS(A1)R2 (and similarly 433 TS(B2)R1 with TS(B2)R2 and so on) it is possible to measure the delay 434 between R1 and R2. In order to have more measurements, it is 435 possible to take and store more timestamps, referring to other 436 packets within each block. 438 In order to coherently compare timestamps collected on different 439 routers, the network nodes must be in sync. Furthermore, a 440 measurement is valid only if no packet loss occurs and if packet 441 misordering can be avoided, otherwise the first packet of a block on 442 R1 could be different from the first packet of the same block on R2 443 (f.i. if that packet is lost between R1 and R2 or it arrives after 444 the next one). 446 The following table shows how timestamps can be used to calculate the 447 delay between R1 and R2. The first column lists the sequence of 448 blocks while other columns contain the timestamp referring to the 449 first packet of each block on R1 and R2. The delay is computed as a 450 difference between timestamps. For the sake of simplicity, all the 451 values are expressed in milliseconds. 453 +-------+---------+---------+---------+---------+-------------+ 454 | Block | TS(A)R1 | TS(B)R1 | TS(A)R2 | TS(B)R2 | Delay R1-R2 | 455 +-------+---------+---------+---------+---------+-------------+ 456 | 1 | 12.483 | - | 15.591 | - | 3.108 | 457 | | | | | | | 458 | 2 | - | 6.263 | - | 9.288 | 3.025 | 459 | | | | | | | 460 | 3 | 27.556 | - | 30.512 | - | 2.956 | 461 | | | | | | | 462 | | - | 18.113 | - | 21.269 | 3.156 | 463 | | | | | | | 464 | ... | ... | ... | ... | ... | ... | 465 | | | | | | | 466 | n | 77.463 | - | 80.501 | - | 3.038 | 467 | | | | | | | 468 | n+1 | - | 24.333 | - | 27.433 | 3.100 | 469 +-------+---------+---------+---------+---------+-------------+ 471 Table 2: Evaluation of timestamps for delay measurements 473 The first row shows timestamps taken on R1 and R2 respectively and 474 referring to the first packet of block 1 (which is A-colored). Delay 475 can be computed as a difference between the timestamp on R2 and the 476 timestamp on R1. Similarly, the second row shows timestamps (in 477 milliseconds) taken on R1 and R2 and referring to the first packet of 478 block 2 (which is B-colored). Comparing timestamps taken on 479 different nodes in the network and referring to the same packets 480 (identified using the alternation of colors) it is possible to 481 measure delay on different network segments. 483 For the sake of simplicity, in the above example a single measurement 484 is provided within a block, taking into account only the first packet 485 of each block. The number of measurements can be easily increased by 486 considering multiple packets in the block: for instance, a timestamp 487 could be taken every N packets, thus generating multiple delay 488 measurements. Taking this to the limit, in principle the delay could 489 be measured for each packet, by taking and comparing the 490 corresponding timestamps (possible but impractical from an 491 implementation point of view). 493 3.2.2. Average delay 495 As mentioned before, the method previously exposed for measuring the 496 delay is sensitive to out of order reception of packets. In order to 497 overcome this problem, a different approach has been considered: it 498 is based on the concept of average delay. The average delay is 499 calculated by considering the average arrival time of the packets 500 within a single block. The network device locally stores a timestamp 501 for each packet received within a single block: summing all the 502 timestamps and dividing by the total number of packets received, the 503 average arrival time for that block of packets can be calculated. By 504 subtracting the average arrival times of two adjacent devices it is 505 possible to calculate the average delay between those nodes. This 506 method is robust to out of order packets and also to packet loss 507 (only a small error is introduced). Moreover, it greatly reduces the 508 number of timestamps (only one per block for each network device) 509 that have to be collected by the management system. On the other 510 hand, it only gives one measure for the duration of the block (f.i. 5 511 minutes), and it doesn't give the minimum, maximum and median delay 512 values (RFC 6703 [RFC6703]). This limitation could be overcome by 513 reducing the duration of the block (f.i. from 5 minutes to a few 514 seconds) by means of an highly optimized implementation of the 515 method. 517 By summing the average delays of the two directions of a path, it is 518 also possible to measure the two-way delay (round-trip delay). 520 3.2.3. Double marking methodology 522 The Single marking methodology for one-way delay measurement is 523 sensitive to out of order reception of packets. The first approach 524 to overcome this problem is described before and is based on the 525 concept of average delay. But the limitation of average delay is 526 that it doesn't give information about the delay values distribution 527 for the duration of the block. Additionally it may be useful to have 528 not only the average delay but also the minimum and maximum delay 529 values and, in wider terms, to know more about the statistic 530 distribution of delay values. So in order to have more information 531 about the delay and to overcome out of order issues, a different 532 approach can be introduced: it is based on double marking 533 methodology. 535 Basically, the idea is to use the first marking to create the 536 alternate flow and, within this colored flow, a second marking to 537 select the packets for measuring delay/jitter. The first marking is 538 needed for packet loss and average delay measurement. The second 539 marking creates a new set of marked packets that are fully identified 540 over the network, so that a network device can store the timestamps 541 of these packets; these timestamps can be compared with the 542 timestamps of the same packets on a second router to compute packet 543 delay values for each packet. The number of measurements can be 544 easily increased by changing the frequency of the second marking. 545 But the frequency of the second marking must be not too high in order 546 to avoid out of order issues. Between packets with the second 547 marking there should be a security time gap (e.g. this gap could be, 548 at the minimum, the average network delay calculated with the 549 previous methodology) to avoid out of order issues and also to have a 550 number of measurement packets that is rate independent. If a second 551 marking packet is lost, the delay measurement for the considered 552 block is corrupted and should be discarded. 554 3.3. Delay variation measurement 556 Similarly to one-way delay measurement (both for single marking and 557 double marking), the method can also be used to measure the inter- 558 arrival jitter. The alternation of colors can be used as a time 559 reference to measure delay variations. Considering the example 560 depicted in Figure 4, R1 stores a timestamp TS(A)R1 whenever it sends 561 the first packet of a block and R2 stores a timestamp TS(B)R2 562 whenever it receives the first packet of a block. The inter-arrival 563 jitter can be easily derived from one-way delay measurement, by 564 evaluating the delay variation of consecutive samples. 566 The concept of average delay can also be applied to delay variation, 567 by evaluating the variation of average interval between consecutive 568 packets of the flow from R1 to R2. 570 4. Considerations 572 This section highlights some considerations about the methodology. 574 4.1. Synchronization 576 There are two mechanisms in Alternate Marking technique that require 577 network devices to have synchronized clocks: packet loss and one-way 578 delay measurement. 580 If the length of the measurement period is L time units, then all 581 network devices must be synchronized to the same clock reference with 582 an accuracy of +/- L/2 time units. This level of accuracy guarantees 583 that all network devices consistently match the color bit to the 584 correct block. For example, if the color is toggeled every second (L 585 = 1 second), then clocks must be synchronized with an accuracy of +/- 586 0.5 second to a common time reference. 588 The synchronization requirement can be satisfied even with a 589 relatively inaccurate synchronization method. 591 Notably, two-way delay measurement does not require the network 592 devices to be time synchronized. Therefore, a system that uses only 593 two-way delay measurement does not require synchronization. This is 594 because the value of the clocks of network devices does not affect 595 the computation of the two-way delay measurement, and synchronization 596 is not required. 598 4.2. Data Correlation 600 Data Correlation could be performed in several ways depending on the 601 the alternate marking application and use case. 603 o A possibility is to use a centralized solution using Network 604 Management System (NMS) to correlate data; 606 o Another possibility is to define a protocol based distributed 607 solution, by defining a new protocol or by extending the existing 608 protocols (e.g. RFC6374, TWAMP, OWAMP) in order to communicate 609 the counters and timestamps between nodes. 611 In the following paragraphs an example data correlation mechanism is 612 explained and could be use independently of the adopted solutions. 614 When data is collected on the upstream and downstream node, e.g., 615 packet counts for packet loss measurement or timestamps for packet 616 delay measurement, and periodically reported to or pulled by other 617 nodes or NMS, a certain data correlation mechanism SHOULD be in use 618 to help the nodes or NMS to tell whether any two or more packet 619 counts are related to the same block of markers, or any two 620 timestamps are related to the same marked packet. 622 The alternate marking method described in this document literally 623 split the packets of the measured flow into different measurement 624 blocks, in addition a Block Number could be assigned to each of such 625 measurement block. The BN is generated each time a node reads the 626 data (packet counts or timestamps), and is associated with each 627 packet count and timestamp reported to or pulled by other nodes or 628 NMS. The value of BN could be calculated as the modulo of the local 629 time (when the data are read) and the interval of the marking time 630 period. 632 When the nodes or NMS see, for example, same BNs associated with two 633 packet counts from an upstream and a downstream node respectively, it 634 considers that these two packet counts corresponding to the same 635 block, i.e. that these two packet counts belong to the same block of 636 markers from the upstream and downstream node. The assumption of 637 this BN mechanism is that the measurement nodes are time 638 synchronized. This requires the measurement nodes to have a certain 639 time synchronization capability (e.g., the Network Time Protocol 640 (NTP) [RFC5905], or the IEEE 1588 Precision Time Protocol (PTP) 641 [IEEE1588]). Synchronization aspects are further discussed in 642 Section 4. 644 4.3. Packet Re-ordering 646 Due to ECMP, packet re-ordering is very common in IP network. The 647 accuracy of marking based PM, especially packet loss measurement, may 648 be affected by packet re-ordering. Take a look at the following 649 example: 651 Block : 1 | 2 | 3 | 4 | 5 |... 652 --------|---------|---------|---------|---------|---------|--- 653 Node R1 : AAAAAAA | BBBBBBB | AAAAAAA | BBBBBBB | AAAAAAA |... 654 Node R2 : AAAAABB | AABBBBA | AAABAAA | BBBBBBA | ABAAABA |... 656 Figure 4: Packet Reordering 658 In the following paragraphs an example data correlation mechanism is 659 explained and could be use independently of the adopted solutions. 661 Most of the packet re-ordering occur at the edge of adjacent blocks, 662 and they are easy to handle if the interval of each block is 663 sufficient large. Then, it can assume that the packets with 664 different marker belong to the block that they are more close to. If 665 the interval is small, it is difficult and sometime impossible to 666 determine to which block a packet belongs. See above example, the 667 packet with the marker of "B" in block 3, there is no safe way to 668 tell whether the packet belongs to block 2 or block 4. 670 To choose a proper interval is important and how to choose a proper 671 interval is out of the scope of this document. But an implementation 672 SHOULD provide a way to configure the interval and allow a certain 673 degree of packet re-ordering. 675 5. Implementation and deployment 677 The methodology described in the previous sections can be applied in 678 various situations. Basically Alternate Marking technique could be 679 used in many cases for performance measurement. The only requirement 680 is to select and mark the flow to be monitored; in this way packets 681 are batched by the sender and each batch is alternately marked such 682 that can be easily recognized by the receiver. 684 An example of implementation and deployment is explained in the next 685 section, just to clarify how the method can work. 687 5.1. Report on the operational experiment at Telecom Italia 689 The methodology has been applied in Telecom Italia by leveraging 690 functions and tools available on IP routers and it's currently being 691 used to monitor packet loss in some portions of Telecom Italia's 692 network. The application of the method to delay measurement is 693 currently being evaluated in Telecom Italia's labs. This section 694 describes how the features currently available on existing routing 695 platforms can be used to apply the method, in order to give an 696 example of implementation and deployment. 698 The fundamental steps for this implementation of the method can be 699 summarized in the following items: 701 o coloring the packets; 703 o counting the packets; 705 o collecting data and calculating the packet loss. 707 o metric transparency. 709 Before going deeper into the implementation details, it's worth 710 mentioning two different strategies that can be used when 711 implementing the method: 713 o flow-based: the flow-based strategy is used when only a limited 714 number of traffic flows need to be monitored. This could be the 715 case, for example, of IPTV channels or other specific applications 716 traffic with high QoS requirements (i.e. Mobile Backhauling 717 traffic). According to this strategy, only a subset of the flows 718 is colored. Counters for packet loss measurements can be 719 instantiated for each single flow, or for the set as a whole, 720 depending on the desired granularity. A relevant problem with 721 this approach is the necessity to know in advance the path 722 followed by flows that are subject to measurement. Path rerouting 723 and traffic load-balancing increase the issue complexity, 724 especially for unicast traffic. The problem is easier to solve 725 for multicast traffic where load balancing is seldom used, 726 especially for IPTV traffic where static joins are frequently used 727 to force traffic forwarding and replication. Another application 728 is on Mobile Backhauling, implemented with a VPN MPLS in Telecom 729 Italia's network; in this case the problem with unicast traffic is 730 overcome by monitoring just the two Provider Edge nodes of the VPN 731 MPLS. 733 o link-based: measurements are performed on all the traffic on a 734 link by link basis. The link could be a physical link or a 735 logical link (for instance an Ethernet VLAN or a MPLS PW). 736 Counters could be instantiated for the traffic as a whole or for 737 each traffic class (in case it is desired to monitor each class 738 separately), but in the second case a couple of counters is needed 739 for each class. 741 The current implementation in Telecom Italia uses the first strategy. 742 As mentioned, the flow-based measurement requires the identification 743 of the flow to be monitored and the discovery of the path followed by 744 the selected flow. It is possible to monitor a single flow or 745 multiple flows grouped together, but in this case measurement is 746 consistent only if all the flows in the group follow the same path. 747 Moreover, a Service Provider should be aware that, if a measurement 748 is performed by grouping many flows, it is not possible to determine 749 exactly which flow was affected by packets loss. In order to have 750 measures per single flow it is necessary to configure counters for 751 each specific flow. Once the flow(s) to be monitored have been 752 identified, it is necessary to configure the monitoring on the proper 753 nodes. Configuring the monitoring means configuring the policy to 754 intercept the traffic and configuring the counters to count the 755 packets. To have just an end-to-end monitoring, it is sufficient to 756 enable the monitoring on the first and the last hop routers of the 757 path: the mechanism is completely transparent to intermediate nodes 758 and independent from the path followed by traffic flows. On the 759 contrary, to monitor the flow on a hop-by-hop basis along its whole 760 path it is necessary to enable the monitoring on every node from the 761 source to the destination. In case the exact path followed by the 762 flow is not known a priori (i.e. the flow has multiple paths to reach 763 the destination) it is necessary to enable the monitoring system on 764 every path: counters on interfaces traversed by the flow will report 765 packet count, counters on other interfaces will be null. 767 5.1.1. Coloring the packets 769 The coloring operation is fundamental in order to create packet 770 blocks. This implies choosing where to activate the coloring and how 771 to color the packets. 773 In case of flow-based measurements, it is desirable, in general, to 774 have a single coloring node because it is easier to manage and 775 doesn't rise any risk of conflict (consider the case where two nodes 776 color the same flow). Thus it is necessary to color the flow as 777 close as possible to the source. In addition, coloring a flow close 778 to the source allows an end-to-end measure if a measurement point is 779 enabled on the last-hop router as well. The only requirement is that 780 the coloring must change periodically and every node along the path 781 must be able to identify unambiguously the colored packets. For 782 link-based measurements, all traffic needs to be colored when 783 transmitted on the link. If the traffic had already been colored, 784 then it has to be re-colored because the color must be consistent on 785 the link. This means that each hop along the path must (re-)color 786 the traffic; the color is not required to be consistent along 787 different links. 789 Traffic coloring can be implemented by setting a specific bit in the 790 packet header and changing the value of that bit periodically. With 791 current router implementations, only QoS related fields and features 792 offer the required flexibility to set bits in the packet header. In 793 case a Service Provider only uses the three most significant bits of 794 the DSCP field (corresponding to IP Precedence) for QoS 795 classification and queuing, it is possible to use the two less 796 significant bits of the DSCP field (bit 0 and bit 1) to implement the 797 method without affecting QoS policies. One of the two bits (bit 0) 798 could be used to identify flows subject to traffic monitoring (set to 799 1 if the flow is under monitoring, otherwise it is set to 0), while 800 the second (bit 1) can be used for coloring the traffic (switching 801 between values 0 and 1, corresponding to color A and B) and creating 802 the blocks. 804 In practice, coloring the traffic using the DSCP field can be 805 implemented by configuring on the router output interface an access 806 list that intercepts the flow(s) to be monitored and applies to them 807 a policy that sets the DSCP field accordingly. Since traffic 808 coloring has to be switched between the two values over time, the 809 policy needs to be modified periodically: an automatic script ca be 810 used perform this task on the basis of a fixed timer. In Telecom 811 Italia's implementation this timer is set to 5 minutes: this value 812 showed to be a good compromise between measurement frequency and 813 stability of the measurement (i.e. possibility to collect all the 814 measures referring to the same block). 816 5.1.2. Counting the packets 818 Assuming that the coloring of the packets is performed only by the 819 source node, the nodes between source and destination (included) have 820 to count the colored packets that they receive and forward: this 821 operation can be enabled on every router along the path or only on a 822 subset, depending on which network segment is being monitored (a 823 single link, a particular metro area, the backbone, the whole path). 825 Since the color switches periodically between two values, two 826 counters (one for each value) are needed: one counter for packets 827 with color A and one counter for packets with color B. For each flow 828 (or group of flows) being monitored and for every interface where the 829 monitoring is active, a couple od counters is needed. For example, 830 in order to monitor separately 3 flows on a router with 4 interfaces 831 involved, 24 counters are needed (2 counters for each of the 3 flows 832 on each of the 4 interfaces). If traffic is colored using the DSCP 833 field, as in Telecom Italia's implementation, an access-list that 834 matches specific DSCP values can be used to count the packets of the 835 flow(s) being monitored. 837 In case of link-based measurements the behaviour is similar except 838 that coloring and counting operations are performed on a link by link 839 basis at each endpoint of the link. 841 Another important aspect to take into consideration is when to read 842 the counters: in order to count the exact number of packets of a 843 block the routers must perform this operation when that block has 844 ended: in other words, the counter for color A must be read when the 845 current block has color B, in order to be sure that the value of the 846 counter is stable. This task can be accomplished in two ways. The 847 general approach suggests to read the counters periodically, many 848 times during a block duration, and to compare these successive 849 readings: when the counter stops incrementing means that the current 850 block has ended and its value can be elaborated safely. 851 Alternatively, if the coloring operation is performed on the basis of 852 a fixed timer, it is possible to configure the reading of the 853 counters according to that timer: for example, if each block is 5 854 minutes long, reading the counter for color A every 5 minute in the 855 middle of the subsequent block (with color B) is a safe choice. A 856 sufficient margin should be considered between the end of a block and 857 the reading of the counter, in order to take into account any out-of- 858 order packets. The choice of a 5 minutes timer for colore switching 859 was also inspired by these considerations. 861 5.1.3. Collecting data and calculating packet loss 863 The nodes enabled to perform performance monitoring collect the value 864 of the counters, but they are not able to directly use this 865 information to measure packet loss, because they only have their own 866 samples. For this reason, an external Network Management System 867 (NMS) is required to collect and elaborate data and to perform packet 868 loss calculation. The NMS compares the values of counters from 869 different nodes and can calculate if some packets were lost (even a 870 single packet) and also where packets were lost. 872 The value of the counters needs to be transmitted to the NMS as soon 873 as it has been read. This can be accomplished by using SNMP or FTP 874 and can be done in Push Mode or Polling Mode. In the first case, 875 each router periodically sends the information to the NMS, in the 876 latter case it is the NMS that periodically polls routers to collect 877 information. In any case, the NMS has to collect all the relevant 878 values from all the routers within one cycle of the timer (5 879 minutes). 881 If link-based measurement is used, it would be possible to use a 882 protocol to exchange values of counters between the two endpoints in 883 order to let them perform the packet loss calculation for each 884 traffic direction. A similar approach could be complicated if 885 applied to a flow-based measurement. 887 5.1.4. Metric transparency 889 In Telecom Italia's implementation the source node colors the packets 890 with a policy that is modified periodically via an automatic script 891 in order to alternate the DSCP field of the packets. The nodes 892 between source and destination (included) have to count with an 893 access-list the colored packets that they receive and forward. 895 Moreover the destination node has an important role: the colored 896 packets are intercepted and a policy restores and sets the DSCP field 897 of all the packets to the initial value. In this way the metric is 898 transparent because outside the section of the network under 899 monitoring the traffic flow is unchanged. 901 In such a case, thanks to this restoring technique, network elements 902 outside the Alternate Marking monitoring domain (e.g. the two 903 Provider Edge nodes of the Mobile Backhauling VPN MPLS) are totally 904 anaware that packets were marked. So this restoring technique makes 905 Alternate Marking completely transparent outside its monitoring 906 domain. 908 5.2. IP flow performance measurement (IPFPM) 910 This application of marking method is described in 911 [I-D.chen-ippm-coloring-based-ipfpm-framework]. 913 5.3. Performance Measurement Marking Method in BIER Domain 915 In [I-D.ietf-bier-mpls-encapsulation] two OAM bits from Bit Index 916 Explicit Replication (BIER) Header are reserved for the passive 917 performance measurement marking method. [I-D.mirsky-bier-pmmm-oam] 918 details the measurement for multicast service over BIER domain. 920 5.4. Overlay OAM Passive Performance Measurement 922 The Overlay OAM Design Team is considering the preliminary OAM 923 requirements from NVO3, BIER, and SFC. Marking Method is the 924 preferred passive method to measure performance. 925 [I-D.ooamdt-rtgwg-ooam-requirement] and 926 [I-D.ooamdt-rtgwg-oam-gap-analysis] explain in deep this item. 928 5.5. RFC6374 Use Case 930 RFC6374 [RFC6374] uses the LM packet as the packet accounting 931 demarcation point. Unfortunately this gives rise to a number of 932 problems that may lead to significant packet accounting errors in 933 certain situations. [I-D.ietf-mpls-flow-ident] discusses the desired 934 capabilities for MPLS flow identification in order to perform a 935 better in-band performance monitoring of user data packets. A method 936 of accomplishing identification is Synonymous Flow Labels (SFL) 937 introduced in [I-D.bryant-mpls-sfl-framework], while 938 [I-D.bryant-mpls-rfc6374-sfl] describes RFC6374 performance 939 measurements with SFL. 941 5.6. Application to active performance measurement 943 [I-D.fioccola-ippm-rfc6812-alt-mark-ext] describes an extension to 944 the Cisco SLA Protocol Measurement-Type UDP-Measurement, in order to 945 implement alternate marking methodology. 947 6. Hybrid measurement 949 The method has been explicitly designed for passive measurements but 950 it can also be used with active measurements. In order to have both 951 end to end measurements and intermediate measurements (hybrid 952 measurements) two end points can exchanges artificial traffic flows 953 and apply alternate marking over these flows. In the intermediate 954 points artificial traffic is managed in the same way as real traffic 955 and measured as specified before. 957 7. Compliance with RFC6390 guidelines 959 RFC6390 [RFC6390] defines a framework and a process for developing 960 Performance Metrics for protocols above and below the IP layer (such 961 as IP-based applications that operate over reliable or datagram 962 transport protocols). 964 This document doesn't aim to propose a new Performance Metric but a 965 new method of measurement for a few Performance Metrics that have 966 already been standardized. Nevertheless, it's worth applying 967 [RFC6390] guidelines to the present document, in order to provide a 968 more complete and coherent description of the proposed method. We 969 used a subset of the Performance Metric Definition template defined 970 by [RFC6390]. 972 o Metric name and description: as already stated, this document 973 doesn't propose any new Performance Metric. On the contrary, it 974 describes a novel method for measuring packet loss [RFC2680]. The 975 same concept, with small differences, can also be used to measure 976 delay [RFC2679], and jitter [RFC3393]. The document mainly 977 describes the applicability to packet loss measurement. 979 o Method of Measurement or Calculation: according to the method 980 described in the previous sections, the number of packets lost is 981 calculated by subtracting the value of the counter on the source 982 node from the value of the counter on the destination node. Both 983 counters must refer to the same color. The calculation is 984 performed when the value of the counters is in a steady state. 986 o Units of Measurement: the method calculates and reports the exact 987 number of packets sent by the source node and not received by the 988 destination node. 990 o Measurement Points: the measurement can be performed between 991 adjacent nodes, on a per-link basis, or along a multi-hop path, 992 provided that the traffic under measurement follows that path. In 993 case of a multi-hop path, the measurements can be performed both 994 end-to-end and hop-by-hop. 996 o Measurement Timing: the method have a constraint on the frequency 997 of measurements. In order to perform a measure, the counter must 998 be in a steady state: this happens when the traffic is being 999 colored with the alternate color; for example in the Telecom 1000 Italia application of the method the time interval is set to 5 1001 minutes. 1003 o Implementation: the Telecom Italia application of the method uses 1004 two encodings of the DSCP field to color the packets; this enables 1005 the use of policy configurations on the router to color the 1006 packets and accordingly configure the counter for each color. The 1007 path followed by traffic being measured should be known in advance 1008 in order to configure the counters along the path and be able to 1009 compare the correct values. 1011 o Use and Applications: the method can be used to measure packet 1012 loss with high precision on live traffic; moreover, by combining 1013 end-to-end and per-link measurements, the method is useful to 1014 pinpoint the single link that is experiencing loss events. 1016 o Reporting Model: the value of the counters has to be sent to a 1017 centralized management system that perform the calculations; such 1018 samples must contain a reference to the time interval they refer 1019 to, so that the management system can perform the correct 1020 correlation; the samples have to be sent while the corresponding 1021 counter is in a steady state (within a time interval), otherwise 1022 the value of the sample should be stored locally. 1024 o Dependencies: the values of the counters have to be correlated to 1025 the time interval they refer to; moreover, as far the Telecom 1026 Italia application of the method is based on DSCP values, there 1027 are significant dependencies on the usage of the DSCP field: it 1028 must be possible to rely on unused DSCP values without affecting 1029 QoS-related configuration and behavior; moreover, the intermediate 1030 nodes must not change the value of the DSCP field not to alter the 1031 measurement. 1033 o Organization of Results: the method of measurement produces 1034 singletons. 1036 o Parameters: currently, the main parameter of the method is the 1037 time interval used to alternate the colors and read the counters. 1039 8. Security Considerations 1041 This document specifies a method to perform measurements in the 1042 context of a Service Provider's network and has not been developed to 1043 conduct Internet measurements, so it does not directly affect 1044 Internet security nor applications which run on the Internet. 1045 However, implementation of this method must be mindful of security 1046 and privacy concerns. 1048 There are two types of security concerns: potential harm caused by 1049 the measurements and potential harm to the measurements. For what 1050 concerns the first point, the measurements described in this document 1051 are passive, so there are no packets injected into the network 1052 causing potential harm to the network itself and to data traffic. 1053 Nevertheless, the method implies modifications on the fly to the IP 1054 header of data packets: this must be performed in a way that doesn't 1055 alter the quality of service experienced by packets subject to 1056 measurements and that preserve stability and performance of routers 1057 doing the measurements. The measurements themselves could be harmed 1058 by routers altering the marking of the packets, or by an attacker 1059 injecting artificial traffic. Authentication techniques, such as 1060 digital signatures, may be used where appropriate to guard against 1061 injected traffic attacks. 1063 The privacy concerns of network measurement are limited because the 1064 method only relies on information contained in the IP header without 1065 any release of user data. 1067 The measurement itself may be affected by routers (or other network 1068 devices) along the path of IP packets intentionally altering the 1069 value of marking bits of packets. As mentioned above, the mechanism 1070 specified in this document is just in the context of one Service 1071 Provider's network, and thus the routers (or other network devices) 1072 are locally administered and this type of attack can be avoided. 1074 One of the main security threats in OAM protocols is network 1075 reconnaissance; an attacker can gather information about the network 1076 performance by passively eavesdropping to OAM messages. The 1077 advantage of the methods described in this document is that the 1078 marking bits are the only information that is exchanged between the 1079 network devices. Therefore, passive eavesdropping to data plane 1080 traffic does not allow attackers to gain information about the 1081 network performance. 1083 Delay attacks are another potential threat in the context of this 1084 document. Delay measurement is performed using a specific packet in 1085 each block, marked by a dedicated color bit. Therefore, a man-in- 1086 the-middle attacker can selectively induce synthetic delay only to 1087 delay-colored packets, causing systematic error in the delay 1088 measurements. As discussed in previous sections, the methods 1089 described in this document rely on an underlying time synchronization 1090 protocol. Thus, by attacking the time protocol an attacker can 1091 potentially compromise the integrity of the measurement. A detailed 1092 discussion about the threats against time protocols and how to 1093 mitigate them is presented in RFC 7384 [RFC7384]. 1095 9. Conclusions 1097 The advantages of the method described in this document are: 1099 o easy implementation: it can be implemented using features already 1100 available on major routing platforms; 1102 o low computational effort: the additional load on processing is 1103 negligible; 1105 o accurate packet loss measurement: single packet loss granularity 1106 is achieved with a passive measurement; 1108 o potential applicability to any kind of packet/frame -based 1109 traffic: Ethernet, IP, MPLS, etc., both unicast and multicast; 1111 o robustness: the method can tolerate out of order packets and it's 1112 not based on "special" packets whose loss could have a negative 1113 impact; 1115 o no interoperability issues: the features required to implement the 1116 method are available on all current routing platforms. 1118 The method doesn't raise any specific need for standardization, but 1119 it could be further improved by means of some extension to existing 1120 protocols. Specifically, the use of DiffServ bits for coloring the 1121 packets could not be a viable solution in some cases: a standard 1122 method to color the packets for this specific application could be 1123 beneficial. 1125 10. IANA Considerations 1127 There are no IANA actions required. 1129 11. Acknowledgements 1131 The authors would like to thank Domenico Laforgia, Daniele Accetta 1132 and Mario Bianchetti for their contribution to the definition and the 1133 implementation of the method. 1135 12. References 1137 12.1. Normative References 1139 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1140 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 1141 September 1999, . 1143 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1144 Packet Loss Metric for IPPM", RFC 2680, 1145 DOI 10.17487/RFC2680, September 1999, 1146 . 1148 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1149 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1150 DOI 10.17487/RFC3393, November 2002, 1151 . 1153 12.2. Informative References 1155 [I-D.bryant-mpls-rfc6374-sfl] 1156 Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, 1157 M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft- 1158 bryant-mpls-rfc6374-sfl-00 (work in progress), October 1159 2015. 1161 [I-D.bryant-mpls-sfl-framework] 1162 Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, 1163 M., and Z. Li, "Synonymous Flow Label Framework", draft- 1164 bryant-mpls-sfl-framework-01 (work in progress), June 1165 2016. 1167 [I-D.chen-ippm-coloring-based-ipfpm-framework] 1168 Chen, M., Zheng, L., Mirsky, G., Fioccola, G., and T. 1169 Mizrahi, "IP Flow Performance Measurement Framework", 1170 draft-chen-ippm-coloring-based-ipfpm-framework-06 (work in 1171 progress), March 2016. 1173 [I-D.cociglio-mboned-multicast-pm] 1174 Cociglio, M., Capello, A., Bonda, A., and L. Castaldelli, 1175 "A method for IP multicast performance monitoring", draft- 1176 cociglio-mboned-multicast-pm-01 (work in progress), 1177 October 2010. 1179 [I-D.fioccola-ippm-rfc6812-alt-mark-ext] 1180 Fioccola, G., Clemm, A., Cociglio, M., Chandramouli, M., 1181 and A. Capello, "Alternate Marking Extension to Cisco SLA 1182 Protocol RFC6812", draft-fioccola-ippm-rfc6812-alt-mark- 1183 ext-01 (work in progress), March 2016. 1185 [I-D.ietf-bier-mpls-encapsulation] 1186 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and 1187 S. Aldrin, "Encapsulation for Bit Index Explicit 1188 Replication in MPLS Networks", draft-ietf-bier-mpls- 1189 encapsulation-04 (work in progress), April 2016. 1191 [I-D.ietf-mpls-flow-ident] 1192 Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. 1193 Mirsky, "MPLS Flow Identification Considerations", draft- 1194 ietf-mpls-flow-ident-01 (work in progress), June 2016. 1196 [I-D.mirsky-bier-pmmm-oam] 1197 Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, 1198 "Performance Measurement (PM) with Marking Method in Bit 1199 Index Explicit Replication (BIER) Layer", draft-mirsky- 1200 bier-pmmm-oam-01 (work in progress), March 2016. 1202 [I-D.ooamdt-rtgwg-oam-gap-analysis] 1203 Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., Kumar, 1204 D., Chen, M., Mozes, D., and J. Networks, "Operations, 1205 Administration and Maintenance (OAM) for Overlay Networks: 1206 Gap Analysis", draft-ooamdt-rtgwg-oam-gap-analysis-01 1207 (work in progress), March 2016. 1209 [I-D.ooamdt-rtgwg-ooam-requirement] 1210 Kumar, N., Pignataro, C., Kumar, D., Mirsky, G., Chen, M., 1211 Nordmark, E., Networks, J., and D. Mozes, "Overlay OAM 1212 Requirements", draft-ooamdt-rtgwg-ooam-requirement-00 1213 (work in progress), March 2016. 1215 [I-D.tempia-opsawg-p3m] 1216 Capello, A., Cociglio, M., Castaldelli, L., and A. Bonda, 1217 "A packet based method for passive performance 1218 monitoring", draft-tempia-opsawg-p3m-04 (work in 1219 progress), February 2014. 1221 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1222 Measurement for MPLS Networks", RFC 6374, 1223 DOI 10.17487/RFC6374, September 2011, 1224 . 1226 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 1227 Performance Metric Development", BCP 170, RFC 6390, 1228 DOI 10.17487/RFC6390, October 2011, 1229 . 1231 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 1232 IP Network Performance Metrics: Different Points of View", 1233 RFC 6703, DOI 10.17487/RFC6703, August 2012, 1234 . 1236 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1237 Weingarten, "An Overview of Operations, Administration, 1238 and Maintenance (OAM) Tools", RFC 7276, 1239 DOI 10.17487/RFC7276, June 2014, 1240 . 1242 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 1243 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 1244 October 2014, . 1246 Authors' Addresses 1248 Giuseppe Fioccola (editor) 1249 Telecom Italia 1250 Via Reiss Romoli, 274 1251 Torino 10148 1252 Italy 1254 Email: giuseppe.fioccola@telecomitalia.it 1255 Alessandro Capello (editor) 1256 Telecom Italia 1257 Via Reiss Romoli, 274 1258 Torino 10148 1259 Italy 1261 Email: alessandro.capello@telecomitalia.it 1263 Mauro Cociglio 1264 Telecom Italia 1265 Via Reiss Romoli, 274 1266 Torino 10148 1267 Italy 1269 Email: mauro.cociglio@telecomitalia.it 1271 Luca Castaldelli 1272 Telecom Italia 1273 Via Reiss Romoli, 274 1274 Torino 10148 1275 Italy 1277 Email: luca.castaldelli@telecomitalia.it 1279 Mach(Guoyi) Chen (editor) 1280 Huawei Technologies 1282 Email: mach.chen@huawei.com 1284 Lianshu Zheng (editor) 1285 Huawei Technologies 1287 Email: vero.zheng@huawei.com 1289 Greg Mirsky (editor) 1290 Ericsson 1291 USA 1293 Email: gregory.mirsky@ericsson.com 1294 Tal Mizrahi (editor) 1295 Marvell 1296 6 Hamada st. 1297 Yokneam 1298 Israel 1300 Email: talmi@marvell.com