idnits 2.17.1 draft-tempia-ippm-p3m-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.tempia-opsawg-p3m], [I-D.cociglio-mboned-multicast-pm]), 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 date (March 21, 2016) is 2955 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.bryant-mpls-synonymous-flow-labels' is defined on line 1011, but no explicit reference was found in the text ** 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-00 == Outdated reference: A later version (-01) exists of draft-fioccola-ippm-rfc6812-alt-mark-ext-00 == Outdated reference: A later version (-12) exists of draft-ietf-bier-mpls-encapsulation-03 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-flow-ident-00 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Capello 3 Internet-Draft M. Cociglio 4 Intended status: Experimental G. Fioccola 5 Expires: September 22, 2016 L. Castaldelli 6 Telecom Italia 7 A. Tempia Bonda 8 March 21, 2016 10 A packet based method for passive performance monitoring 11 draft-tempia-ippm-p3m-03 13 Abstract 15 This document describes a passive method to perform packet loss, 16 delay and jitter measurements on live traffic. This method is based 17 on Alternate Marking (Coloring) technique. A report on the 18 operational experiment done at Telecom Italia is explained in order 19 to give an example and show the method applicability. This technique 20 can be applied in various situations as detailed in this document. 21 The previous IETF drafts about this technique were: 22 [I-D.cociglio-mboned-multicast-pm] and [I-D.tempia-opsawg-p3m]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 22, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Overview of the method . . . . . . . . . . . . . . . . . . . 4 57 3. Detailed description of the method . . . . . . . . . . . . . 5 58 3.1. Packet loss measurement . . . . . . . . . . . . . . . . . 5 59 3.2. One-way delay measurement . . . . . . . . . . . . . . . . 9 60 3.2.1. Single marking methodology . . . . . . . . . . . . . 9 61 3.2.2. Average delay . . . . . . . . . . . . . . . . . . . . 11 62 3.2.3. Double marking methodology . . . . . . . . . . . . . 11 63 3.3. Delay variation measurement . . . . . . . . . . . . . . . 12 64 4. Implementation and deployment . . . . . . . . . . . . . . . . 12 65 4.1. Report on the operational experiment at Telecom Italia . 13 66 4.1.1. Coloring the packets . . . . . . . . . . . . . . . . 14 67 4.1.2. Counting the packets . . . . . . . . . . . . . . . . 15 68 4.1.3. Collecting data and calculating packet loss . . . . . 16 69 4.1.4. Metric transparency . . . . . . . . . . . . . . . . . 17 70 4.2. IP flow performance measurement (IPFPM) . . . . . . . . . 17 71 4.3. Performance Measurement Marking Method in BIER Domain . . 17 72 4.4. RFC6374 Use Case . . . . . . . . . . . . . . . . . . . . 17 73 4.5. Application to active performance measurement . . . . . . 18 74 5. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 18 75 6. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 18 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 77 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 79 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 82 11.2. Informative References . . . . . . . . . . . . . . . . . 22 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 85 1. Introduction 87 Nowadays, most of the traffic in Service Providers' networks carries 88 real time content. These contents are highly sensitive to packet 89 loss [RFC2680], while interactive contents are sensitive to delay 90 [RFC2679], and jitter [RFC3393]. 92 In view of this scenario, Service Providers need methodologies and 93 tools to monitor and measure network performances with an adequate 94 accuracy, in order to constantly control the quality of experience 95 perceived by their customers. On the other hand, performance 96 monitoring provides useful information for improving network 97 management (e.g. isolation of network problems, troubleshooting, 98 etc.). 100 A lot of work related to OAM, that includes also performance 101 monitoring techniques, has been done by Standards Developing 102 Organizations: [RFC7276] provides a good overview of existing OAM 103 mechanisms defined in IETF, ITU-T and IEEE. Considering IETF, a lot 104 of work has been done on fault detection and connectivity 105 verification, while a minor effort has been dedicated so far to 106 performance monitoring. The IPPM WG has defined standard metrics to 107 measure network performance; however, the methods developed in the WG 108 mainly refer to active measurement techniques. More recently, the 109 MPLS WG has defined mechanisms for measuring packet loss, one-way and 110 two-way delay, and delay variation in MPLS networks[RFC6374], but 111 their applicability to passive measurements has some limitations, 112 especially for pure connection-less networks. 114 The lack of adequate tools to measure packet loss with the desired 115 accuracy drove an effort to design a new method for the performance 116 monitoring of live traffic, possibly easy to implement and deploy. 117 The effort led to the method described in this document: basically, 118 it is a passive performance monitoring technique, potentially 119 applicable to any kind of packet based traffic, including Ethernet, 120 IP, and MPLS, both unicast and multicast. The method addresses 121 primarily packet loss measurement, but it can be easily extended to 122 one-way delay and delay variation measurements as well. It doesn't 123 require any protocol extension or interaction with existing 124 protocols, thus avoiding any interoperability issue. Even if the 125 method doesn't raise any specific need for standardization, it could 126 be further improved by means of some extension to existing protocols, 127 but this aspect is left for further study and it is out of the scope 128 of this document. 130 The method has been explicitly designed for passive measurements but 131 it can also be used with active probes. Passive measurements are 132 usually more easily understood by customers and provide a much better 133 accuracy, especially for packet loss measurements. 135 The method described in this document, also called PNPM (Packet 136 Network Performance Monitoring), has been invented and engineered in 137 Telecom Italia and it's currently being used in Telecom Italia's 138 network. The previous IETF drafts about this technique were: 139 [I-D.cociglio-mboned-multicast-pm] and [I-D.tempia-opsawg-p3m]. 140 There are some references to this methodology in other IETF works 141 (e.g. [I-D.ietf-mpls-flow-ident], [I-D.bryant-mpls-sfl-framework] 142 [I-D.bryant-mpls-rfc6374-sfl], [I-D.ietf-bier-mpls-encapsulation], 143 [I-D.mirsky-bier-pmmm-oam] 144 [I-D.chen-ippm-coloring-based-ipfpm-framework]). 146 This document is organized as follows: 148 o Section 2 gives an overview of the method, including a comparison 149 with different measurement strategies; 151 o Section 3 describes the method in detail; 153 o Section 4 reports examples of implementation and deployment of the 154 method. Furthermore the operational experiment done at Telecom 155 Italia is described; 157 o Section 5 includes some considerations about security aspects; 159 o Section 6 finally summarizes some concluding remarks. 161 2. Overview of the method 163 In order to perform packet loss measurements on a live traffic flow, 164 different approaches exist. The most intuitive one consists in 165 numbering the packets, so that each router that receives the flow can 166 immediately detect a packet missing. This approach, though very 167 simple in theory, is not simple to achieve: it requires the insertion 168 of a sequence number into each packet and the devices must be able to 169 extract the number and check it in real time. Such a task can be 170 difficult to implement on live traffic: if UDP is used as the 171 transport protocol, the sequence number is not available; on the 172 other hand, if a higher layer sequence number (e.g. in the RTP 173 header) is used, extracting that information from each packet and 174 process it in real time could overload the device. 176 An alternate approach is to count the number of packets sent on one 177 end, the number of packets received on the other end, and to compare 178 the two values. This operation is much simpler to implement, but 179 requires that the devices performing the measurement are in sync: in 180 order to compare two counters it is required that they refer exactly 181 to the same set of packets. Since a flow is continuous and cannot be 182 stopped when a counter has to be read, it could be difficult to 183 determine exactly when to read the counter. A possible solution to 184 overcome this problem is to virtually split the flow in consecutive 185 blocks by inserting periodically a delimiter so that each counter 186 refers exactly to the same block of packets. The delimiter could be 187 for example a special packet inserted artificially into the flow. 188 However, delimiting the flow using specific packets has some 189 limitations. First, it requires generating additional packets within 190 the flow and requires the equipment to be able to process those 191 packets. In addition, the method is vulnerable to out of order 192 reception of delimiting packets and, to a lesser extent, to their 193 loss. 195 The method proposed in this document follows the second approach, but 196 it doesn't use additional packets to virtually split the flow in 197 blocks. Instead, it "colors" the packets so that the packets 198 belonging to the same block will have the same color, whilst 199 consecutive blocks will have different colors. Each change of color 200 represents a sort of auto-synchronization signal that guarantees the 201 consistency of measurements taken by different devices along the 202 path. 204 Figure 1 represents a very simple network and shows how the method 205 can be used to measure packet loss on different network segments: by 206 enabling the measurement on several interfaces along the path, it is 207 possible to perform link monitoring, node monitoring or end-to-end 208 monitoring. The method is flexible enough to measure packet loss on 209 any segment of the network and can be used to isolate the faulty 210 element. 212 Traffic flow 213 ========================================================> 214 +------+ +------+ +------+ +------+ 215 ---<> R1 <>-----<> R2 <>-----<> R3 <>-----<> R4 <>--- 216 +------+ +------+ +------+ +------+ 217 . . . . . . 218 . . . . . . 219 . <------> <-------> . 220 . Node Packet Loss Link Packet Loss . 221 . . 222 <---------------------------------------------------> 223 End-to-End Packet loss 225 Figure 1: Available measurements 227 3. Detailed description of the method 229 This section describes in detail how the method operate. A special 230 emphasis is given to the measurement of packet loss, that represents 231 the core application of the method, but applicability to delay and 232 jitter measurements is also considered. 234 3.1. Packet loss measurement 236 The basic idea is to virtually split traffic flows into consecutive 237 blocks: each block represents a measurable entity unambiguously 238 recognizable by all network devices along the path. By counting the 239 number of packets in each block and comparing the values measured by 240 different network devices along the path, it is possible to measure 241 packet loss occurred in any single block between any two points. 243 As discussed in the previous section, a simple way to create the 244 blocks is to "color" the traffic (two colors are sufficient) so that 245 packets belonging to different consecutive blocks will have different 246 colors. Whenever the color changes, the previous block terminates 247 and the new one begins. Hence, all the packets belonging to the same 248 block will have the same color and packets of different consecutive 249 blocks will have different colors. The number of packets in each 250 block depends on the criterion used to create the blocks: if the 251 color is switched after a fixed number of packets, then each block 252 will contain the same number of packets (except for any losses); but 253 if the color is switched according to a fixed timer, then the number 254 of packets may be different in each block depending on the packet 255 rate. 257 The following figure shows how a flow looks like when it is split in 258 traffic blocks with colored packets. 260 A: packet with A coloring 261 B: packet with B coloring 263 | | | | | 264 | | Traffic flow | | 265 -------------------------------------------------------------------> 266 BBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA 267 -------------------------------------------------------------------> 268 ... | Block 5 | Block 4 | Block 3 | Block 2 | Block 1 269 | | | | | 271 Figure 2: Traffic coloring 273 Figure 3 shows how the method can be used to measure link packet loss 274 between two adjacent nodes. 276 Referring to the figure, let's assume we want to monitor the packet 277 loss on the link between two routers: router R1 and router R2. 278 According to the method, the traffic is colored alternatively with 279 two different colors, A and B. Whenever the color changes, the 280 transition generates a sort of square-wave signal, as depicted in the 281 following figure. 283 Color A ----------+ +-----------+ +---------- 284 | | | | 285 Color B +-----------+ +-----------+ 286 Block n ... Block 3 Block 2 Block 1 287 <---------> <---------> <---------> <---------> <---------> 289 Traffic flow 290 ===========================================================> 291 Color ... AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA... 292 ===========================================================> 294 Figure 3: Application of the method to compute link packet loss 296 Traffic coloring could be done by R1 itself or by an upward router. 297 R1 needs two counters, C(A)R1 and C(B)R1, on its egress interface: 298 C(A)R1 counts the packets with color A and C(B)R1 counts those with 299 color B. As long as traffic is colored A, only counter C(A)R1 will 300 be incremented, while C(B)R1 is not incremented; vice versa, when the 301 traffic is colored as B, only C(B)R1 is incremented. C(A)R1 and 302 C(B)R1 can be used as reference values to determine the packet loss 303 from R1 to any other measurement point down the path. Router R2, 304 similarly, will need two counters on its ingress interface, C(A)R2 305 and C(B)R2, to count the packets received on that interface and 306 colored with color A and B respectively. When an A block ends, it is 307 possible to compare C(A)R1 and C(A)R2 and calculate the packet loss 308 within the block; similarly, when the successive B block terminates, 309 it is possible to compare C(B)R1 with C(B)R2, and so on for every 310 successive block. 312 Likewise, by using two counters on R2 egress interface it is possible 313 to count the packets sent out of R2 interface and use them as 314 reference values to calculate the packet loss from R2 to any 315 measurement point down R2. 317 Using a fixed timer for color switching offers a better control over 318 the method: the (time) length of the blocks can be chosen large 319 enough to simplify the collection and the comparison of measures 320 taken by different network devices. It's preferable to read the 321 value of the counters not immediately after the color switch: some 322 packets could arrive out of order and increment the counter 323 associated to the previous block (color), so it is worth waiting for 324 some time. A safe choice is to wait L/2 time units (where L is the 325 duration for each block) after the color switch, to read the still 326 counter of the previous color, so the possibility to read a running 327 counter instead of a still one is minimized. The drawback is that 328 the longer the duration of the block, the less frequent the 329 measurement can be taken. 331 The following table shows how the counters can be used to calculate 332 the packet loss between R1 and R2. The first column lists the 333 sequence of traffic blocks while the other columns contain the 334 counters of A-colored packets and B-colored packets for R1 and R2. 335 In this example, we assume that the values of the counters are reset 336 to zero whenever a block ends and its associated counter has been 337 read: with this assumption, the table shows only relative values, 338 that is the exact number of packets of each color within each block. 339 If the values of the counters were not reset, the table would contain 340 cumulative values, but the relative values could be determined simply 341 by difference from the value of the previous block of the same color. 343 The color is switched on the basis of a fixed timer (not shown in the 344 table), so the number of packets in each block is different. 346 +-------+--------+--------+--------+--------+------+ 347 | Block | C(A)R1 | C(B)R1 | C(A)R2 | C(B)R2 | Loss | 348 +-------+--------+--------+--------+--------+------+ 349 | 1 | 375 | 0 | 375 | 0 | 0 | 350 | | | | | | | 351 | 2 | 0 | 388 | 0 | 388 | 0 | 352 | | | | | | | 353 | 3 | 382 | 0 | 381 | 0 | 1 | 354 | | | | | | | 355 | 4 | 0 | 377 | 0 | 374 | 3 | 356 | | | | | | | 357 | ... | ... | ... | ... | ... | ... | 358 | | | | | | | 359 | n | 0 | 387 | 0 | 387 | 0 | 360 | | | | | | | 361 | n+1 | 379 | 0 | 377 | 0 | 2 | 362 +-------+--------+--------+--------+--------+------+ 364 Table 1: Evaluation of counters for packet loss measurements 366 During an A block (blocks 1, 3 and n+1), all the packets are 367 A-colored, therefore the C(A) counters are incremented to the number 368 seen on the interface, while C(B) counters are zero. Vice versa, 369 during a B block (blocks 2, 4 and n), all the packets are B-colored: 370 C(A) counters are zero, while C(B) counters are incremented. 372 When a block ends (because of color switching) the relative counters 373 stop incrementing and it is possible to read them, compare the values 374 measured on router R1 and R2 and calculate the packet loss within 375 that block. 377 For example, looking at the table above, during the first block 378 (A-colored), C(A)R1 and C(A)R2 have the same value (375), which 379 corresponds to the exact number of packets of the first block (no 380 loss). Also during the second block (B-colored) R1 and R2 counters 381 have the same value (388), which corresponds to the number of packets 382 of the second block (no loss). During blocks three and four, R1 and 383 R2 counters are different, meaning that some packets have been lost: 384 in the example, one single packet (382-381) was lost during block 385 three and three packets (377-374) were lost during block four. 387 R1 and R2 require a clock error less than +/-L/2 time units, where L 388 is the time duration of the block. In this way each colored packet 389 can be assigned to the right block by each router. This is because 390 the minimum time distance between two packets of the same color but 391 belonging to different blocks is L time units. 393 The method applied to R1 and R2 can be extended to any other router 394 and applied to more complex networks, as far as the measurement is 395 enabled on the path followed by the traffic flow(s) being observed. 397 3.2. One-way delay measurement 399 The same principle used to measure packet loss can be applied also to 400 one-way delay measurement. There are three alternatives, as 401 described hereinafter. 403 3.2.1. Single marking methodology 405 The alternation of colors can be used as a time reference to 406 calculate the delay. Whenever the color changes (that means that a 407 new block has started) a network device can store the timestamp of 408 the first packet of the new block; that timestamp can be compared 409 with the timestamp of the same packet on a second router to compute 410 packet delay. Considering Figure 4, R1 stores a timestamp TS(A1)R1 411 when it sends the first packet of block 1 (A-colored), a timestamp 412 TS(B2)R1 when it sends the first packet of block 2 (B-colored) and so 413 on for every other block. R2 performs the same operation on the 414 receiving side, recording TS(A1)R2, TS(B2)R2 and so on. Since the 415 timestamps refer to specific packets (the first packet of each block) 416 we are sure that timestamps compared to compute delay refer to the 417 same packets. By comparing TS(A1)R1 with TS(A1)R2 (and similarly 418 TS(B2)R1 with TS(B2)R2 and so on) it is possible to measure the delay 419 between R1 and R2. In order to have more measurements, it is 420 possible to take and store more timestamps, referring to other 421 packets within each block. 423 In order to coherently compare timestamps collected on different 424 routers, the network nodes must be in sync. Furthermore, a 425 measurement is valid only if no packet loss occurs and if packet 426 misordering can be avoided, otherwise the first packet of a block on 427 R1 could be different from the first packet of the same block on R2 428 (f.i. if that packet is lost between R1 and R2 or it arrives after 429 the next one). 431 The following table shows how timestamps can be used to calculate the 432 delay between R1 and R2. The first column lists the sequence of 433 blocks while other columns contain the timestamp referring to the 434 first packet of each block on R1 and R2. The delay is computed as a 435 difference between timestamps. For the sake of simplicity, all the 436 values are expressed in milliseconds. 438 +-------+---------+---------+---------+---------+-------------+ 439 | Block | TS(A)R1 | TS(B)R1 | TS(A)R2 | TS(B)R2 | Delay R1-R2 | 440 +-------+---------+---------+---------+---------+-------------+ 441 | 1 | 12.483 | - | 15.591 | - | 3.108 | 442 | | | | | | | 443 | 2 | - | 6.263 | - | 9.288 | 3.025 | 444 | | | | | | | 445 | 3 | 27.556 | - | 30.512 | - | 2.956 | 446 | | | | | | | 447 | | - | 18.113 | - | 21.269 | 3.156 | 448 | | | | | | | 449 | ... | ... | ... | ... | ... | ... | 450 | | | | | | | 451 | n | 77.463 | - | 80.501 | - | 3.038 | 452 | | | | | | | 453 | n+1 | - | 24.333 | - | 27.433 | 3.100 | 454 +-------+---------+---------+---------+---------+-------------+ 456 Table 2: Evaluation of timestamps for delay measurements 458 The first row shows timestamps taken on R1 and R2 respectively and 459 referring to the first packet of block 1 (which is A-colored). Delay 460 can be computed as a difference between the timestamp on R2 and the 461 timestamp on R1. Similarly, the second row shows timestamps (in 462 milliseconds) taken on R1 and R2 and referring to the first packet of 463 block 2 (which is B-colored). Comparing timestamps taken on 464 different nodes in the network and referring to the same packets 465 (identified using the alternation of colors) it is possible to 466 measure delay on different network segments. 468 For the sake of simplicity, in the above example a single measurement 469 is provided within a block, taking into account only the first packet 470 of each block. The number of measurements can be easily increased by 471 considering multiple packets in the block: for instance, a timestamp 472 could be taken every N packets, thus generating multiple delay 473 measurements. Taking this to the limit, in principle the delay could 474 be measured for each packet, by taking and comparing the 475 corresponding timestamps (possible but impractical from an 476 implementation point of view). 478 3.2.2. Average delay 480 As mentioned before, the method previously exposed for measuring the 481 delay is sensitive to out of order reception of packets. In order to 482 overcome this problem, a different approach has been considered: it 483 is based on the concept of average delay. The average delay is 484 calculated by considering the average arrival time of the packets 485 within a single block. The network device locally stores a timestamp 486 for each packet received within a single block: summing all the 487 timestamps and dividing by the total number of packets received, the 488 average arrival time for that block of packets can be calculated. By 489 subtracting the average arrival times of two adjacent devices it is 490 possible to calculate the average delay between those nodes. This 491 method is robust to out of order packets and also to packet loss 492 (only a small error is introduced). Moreover, it greatly reduces the 493 number of timestamps (only one per block for each network device) 494 that have to be collected by the management system. On the other 495 hand, it only gives one measure for the duration of the block (f.i. 5 496 minutes), and it doesn't give the minimum, maximum and median delay 497 values (RFC 6703 [RFC6703]). This limitation could be overcome by 498 reducing the duration of the block (f.i. from 5 minutes to a few 499 seconds) by means of an highly optimized implementation of the 500 method. 502 By summing the average delays of the two directions of a path, it is 503 also possible to measure the two-way delay (round-trip delay). 505 3.2.3. Double marking methodology 507 The Single marking methodology for one-way delay measurement is 508 sensitive to out of order reception of packets. The first approach 509 to overcome this problem is described before and is based on the 510 concept of average delay. But the limitation of average delay is 511 that it doesn't give information about the delay values distribution 512 for the duration of the block. Additionally it may be useful to have 513 not only the average delay but also the minimum and maximum delay 514 values and, in wider terms, to know more about the statistic 515 distribution of delay values. So in order to have more information 516 about the delay and to overcome out of order issues, a different 517 approach can be introduced: it is based on double marking 518 methodology. 520 Basically, the idea is to use the first marking to create the 521 alternate flow and, within this colored flow, a second marking to 522 select the packets for measuring delay/jitter. The first marking is 523 needed for packet loss and average delay measurement. The second 524 marking creates a new set of marked packets that are fully identified 525 over the network, so that a network device can store the timestamps 526 of these packets; these timestamps can be compared with the 527 timestamps of the same packets on a second router to compute packet 528 delay values for each packet. The number of measurements can be 529 easily increased by changing the frequency of the second marking. 530 But the frequency of the second marking must be not too high in order 531 to avoid out of order issues. Between packets with the second 532 marking there should be a security time gap (e.g. this gap could be, 533 at the minimum, the average network delay calculated with the 534 previous methodology) to avoid out of order issues and also to have a 535 number of measurement packets that is rate independent. If a second 536 marking packet is lost, the delay measurement for the considered 537 block is corrupted and should be discarded. 539 3.3. Delay variation measurement 541 Similarly to one-way delay measurement (both for single marking and 542 double marking), the method can also be used to measure the inter- 543 arrival jitter. The alternation of colors can be used as a time 544 reference to measure delay variations. Considering the example 545 depicted in Figure 4, R1 stores a timestamp TS(A)R1 whenever it sends 546 the first packet of a block and R2 stores a timestamp TS(B)R2 547 whenever it receives the first packet of a block. The inter-arrival 548 jitter can be easily derived from one-way delay measurement, by 549 evaluating the delay variation of consecutive samples. 551 The concept of average delay can also be applied to delay variation, 552 by evaluating the variation of average interval between consecutive 553 packets of the flow from R1 to R2. 555 4. Implementation and deployment 557 The methodology described in the previous sections can be applied in 558 various situations. Basically Alternate Marking technique could be 559 used in many cases for performance measurement. The only requirement 560 is to select and mark the flow to be monitored; in this way packets 561 are batched by the sender and each batch is alternately marked such 562 that can be easily recognized by the receiver. 564 An example of implementation and deployment is explained in the next 565 section, just to clarify how the method can work. 567 4.1. Report on the operational experiment at Telecom Italia 569 The methodology has been applied in Telecom Italia by leveraging 570 functions and tools available on IP routers and it's currently being 571 used to monitor packet loss in some portions of Telecom Italia's 572 network. The application of the method to delay measurement is 573 currently being evaluated in Telecom Italia's labs. This section 574 describes how the features currently available on existing routing 575 platforms can be used to apply the method, in order to give an 576 example of implementation and deployment. 578 The fundamental steps for this implementation of the method can be 579 summarized in the following items: 581 o coloring the packets; 583 o counting the packets; 585 o collecting data and calculating the packet loss. 587 o metric transparency. 589 Before going deeper into the implementation details, it's worth 590 mentioning two different strategies that can be used when 591 implementing the method: 593 o flow-based: the flow-based strategy is used when only a limited 594 number of traffic flows need to be monitored. This could be the 595 case, for example, of IPTV channels or other specific applications 596 traffic with high QoS requirements (i.e. Mobile Backhauling 597 traffic). According to this strategy, only a subset of the flows 598 is colored. Counters for packet loss measurements can be 599 instantiated for each single flow, or for the set as a whole, 600 depending on the desired granularity. A relevant problem with 601 this approach is the necessity to know in advance the path 602 followed by flows that are subject to measurement. Path rerouting 603 and traffic load-balancing increase the issue complexity, 604 especially for unicast traffic. The problem is easier to solve 605 for multicast traffic where load balancing is seldom used, 606 especially for IPTV traffic where static joins are frequently used 607 to force traffic forwarding and replication. Another application 608 is on Mobile Backhauling, implemented with a VPN MPLS in Telecom 609 Italia's network; in this case the problem with unicast traffic is 610 overcome by monitoring just the two Provider Edge nodes of the VPN 611 MPLS. 613 o link-based: measurements are performed on all the traffic on a 614 link by link basis. The link could be a physical link or a 615 logical link (for instance an Ethernet VLAN or a MPLS PW). 616 Counters could be instantiated for the traffic as a whole or for 617 each traffic class (in case it is desired to monitor each class 618 separately), but in the second case a couple of counters is needed 619 for each class. 621 The current implementation in Telecom Italia uses the first strategy. 622 As mentioned, the flow-based measurement requires the identification 623 of the flow to be monitored and the discovery of the path followed by 624 the selected flow. It is possible to monitor a single flow or 625 multiple flows grouped together, but in this case measurement is 626 consistent only if all the flows in the group follow the same path. 627 Moreover, a Service Provider should be aware that, if a measurement 628 is performed by grouping many flows, it is not possible to determine 629 exactly which flow was affected by packets loss. In order to have 630 measures per single flow it is necessary to configure counters for 631 each specific flow. Once the flow(s) to be monitored have been 632 identified, it is necessary to configure the monitoring on the proper 633 nodes. Configuring the monitoring means configuring the policy to 634 intercept the traffic and configuring the counters to count the 635 packets. To have just an end-to-end monitoring, it is sufficient to 636 enable the monitoring on the first and the last hop routers of the 637 path: the mechanism is completely transparent to intermediate nodes 638 and independent from the path followed by traffic flows. On the 639 contrary, to monitor the flow on a hop-by-hop basis along its whole 640 path it is necessary to enable the monitoring on every node from the 641 source to the destination. In case the exact path followed by the 642 flow is not known a priori (i.e. the flow has multiple paths to reach 643 the destination) it is necessary to enable the monitoring system on 644 every path: counters on interfaces traversed by the flow will report 645 packet count, counters on other interfaces will be null. 647 4.1.1. Coloring the packets 649 The coloring operation is fundamental in order to create packet 650 blocks. This implies choosing where to activate the coloring and how 651 to color the packets. 653 In case of flow-based measurements, it is desirable, in general, to 654 have a single coloring node because it is easier to manage and 655 doesn't rise any risk of conflict (consider the case where two nodes 656 color the same flow). Thus it is necessary to color the flow as 657 close as possible to the source. In addition, coloring a flow close 658 to the source allows an end-to-end measure if a measurement point is 659 enabled on the last-hop router as well. The only requirement is that 660 the coloring must change periodically and every node along the path 661 must be able to identify unambiguously the colored packets. For 662 link-based measurements, all traffic needs to be colored when 663 transmitted on the link. If the traffic had already been colored, 664 then it has to be re-colored because the color must be consistent on 665 the link. This means that each hop along the path must (re-)color 666 the traffic; the color is not required to be consistent along 667 different links. 669 Traffic coloring can be implemented by setting a specific bit in the 670 packet header and changing the value of that bit periodically. With 671 current router implementations, only QoS related fields and features 672 offer the required flexibility to set bits in the packet header. In 673 case a Service Provider only uses the three most significant bits of 674 the DSCP field (corresponding to IP Precedence) for QoS 675 classification and queuing, it is possible to use the two less 676 significant bits of the DSCP field (bit 0 and bit 1) to implement the 677 method without affecting QoS policies. One of the two bits (bit 0) 678 could be used to identify flows subject to traffic monitoring (set to 679 1 if the flow is under monitoring, otherwise it is set to 0), while 680 the second (bit 1) can be used for coloring the traffic (switching 681 between values 0 and 1, corresponding to color A and B) and creating 682 the blocks. 684 In practice, coloring the traffic using the DSCP field can be 685 implemented by configuring on the router output interface an access 686 list that intercepts the flow(s) to be monitored and applies to them 687 a policy that sets the DSCP field accordingly. Since traffic 688 coloring has to be switched between the two values over time, the 689 policy needs to be modified periodically: an automatic script ca be 690 used perform this task on the basis of a fixed timer. In Telecom 691 Italia's implementation this timer is set to 5 minutes: this value 692 showed to be a good compromise between measurement frequency and 693 stability of the measurement (i.e. possibility to collect all the 694 measures referring to the same block). 696 4.1.2. Counting the packets 698 Assuming that the coloring of the packets is performed only by the 699 source node, the nodes between source and destination (included) have 700 to count the colored packets that they receive and forward: this 701 operation can be enabled on every router along the path or only on a 702 subset, depending on which network segment is being monitored (a 703 single link, a particular metro area, the backbone, the whole path). 705 Since the color switches periodically between two values, two 706 counters (one for each value) are needed: one counter for packets 707 with color A and one counter for packets with color B. For each flow 708 (or group of flows) being monitored and for every interface where the 709 monitoring is active, a couple od counters is needed. For example, 710 in order to monitor separately 3 flows on a router with 4 interfaces 711 involved, 24 counters are needed (2 counters for each of the 3 flows 712 on each of the 4 interfaces). If traffic is colored using the DSCP 713 field, as in Telecom Italia's implementation, an access-list that 714 matches specific DSCP values can be used to count the packets of the 715 flow(s) being monitored. 717 In case of link-based measurements the behaviour is similar except 718 that coloring and counting operations are performed on a link by link 719 basis at each endpoint of the link. 721 Another important aspect to take into consideration is when to read 722 the counters: in order to count the exact number of packets of a 723 block the routers must perform this operation when that block has 724 ended: in other words, the counter for color A must be read when the 725 current block has color B, in order to be sure that the value of the 726 counter is stable. This task can be accomplished in two ways. The 727 general approach suggests to read the counters periodically, many 728 times during a block duration, and to compare these successive 729 readings: when the counter stops incrementing means that the current 730 block has ended and its value can be elaborated safely. 731 Alternatively, if the coloring operation is performed on the basis of 732 a fixed timer, it is possible to configure the reading of the 733 counters according to that timer: for example, if each block is 5 734 minutes long, reading the counter for color A every 5 minute in the 735 middle of the subsequent block (with color B) is a safe choice. A 736 sufficient margin should be considered between the end of a block and 737 the reading of the counter, in order to take into account any out-of- 738 order packets. The choice of a 5 minutes timer for colore switching 739 was also inspired by these considerations. 741 4.1.3. Collecting data and calculating packet loss 743 The nodes enabled to perform performance monitoring collect the value 744 of the counters, but they are not able to directly use this 745 information to measure packet loss, because they only have their own 746 samples. For this reason, an external Network Management System 747 (NMS) is required to collect and elaborate data and to perform packet 748 loss calculation. The NMS compares the values of counters from 749 different nodes and can calculate if some packets were lost (even a 750 single packet) and also where packets were lost. 752 The value of the counters needs to be transmitted to the NMS as soon 753 as it has been read. This can be accomplished by using SNMP or FTP 754 and can be done in Push Mode or Polling Mode. In the first case, 755 each router periodically sends the information to the NMS, in the 756 latter case it is the NMS that periodically polls routers to collect 757 information. In any case, the NMS has to collect all the relevant 758 values from all the routers within one cycle of the timer (5 759 minutes). 761 If link-based measurement is used, it would be possible to use a 762 protocol to exchange values of counters between the two endpoints in 763 order to let them perform the packet loss calculation for each 764 traffic direction. A similar approach could be complicated if 765 applied to a flow-based measurement. 767 4.1.4. Metric transparency 769 In Telecom Italia's implementation the source node colors the packets 770 with a policy that is modified periodically via an automatic script 771 in order to alternate the DSCP field of the packets. The nodes 772 between source and destination (included) have to count with an 773 access-list the colored packets that they receive and forward. 775 Moreover the destination node has an important role: the colored 776 packets are intercepted and a policy restores and sets the DSCP field 777 of all the packets to the initial value. In this way the metric is 778 transparent because outside the section of the network under 779 monitoring the traffic flow is unchanged. 781 In such a case, thanks to this restoring technique, network elements 782 outside the Alternate Marking monitoring domain (e.g. the two 783 Provider Edge nodes of the Mobile Backhauling VPN MPLS) are totally 784 anaware that packets were marked. So this restoring technique makes 785 Alternate Marking completely transparent outside its monitoring 786 domain. 788 4.2. IP flow performance measurement (IPFPM) 790 This application of marking method is described in 791 [I-D.chen-ippm-coloring-based-ipfpm-framework]. 793 4.3. Performance Measurement Marking Method in BIER Domain 795 In [I-D.ietf-bier-mpls-encapsulation] two OAM bits from Bit Index 796 Explicit Replication (BIER) Header are reserved for the passive 797 performance measurement marking method. [I-D.mirsky-bier-pmmm-oam] 798 details the measurement for multicast service over BIER domain. 800 4.4. RFC6374 Use Case 802 RFC6374 [RFC6374] uses the LM packet as the packet accounting 803 demarcation point. Unfortunately this gives rise to a number of 804 problems that may lead to significant packet accounting errors in 805 certain situations. [I-D.ietf-mpls-flow-ident] discusses the desired 806 capabilities for MPLS flow identification in order to perform a 807 better in-band performance monitoring of user data packets. A method 808 of accomplishing identification is Synonymous Flow Labels (SFL) 809 introduced in [I-D.bryant-mpls-sfl-framework], while 810 [I-D.bryant-mpls-rfc6374-sfl] describes RFC6374 performance 811 measurements with SFL. 813 4.5. Application to active performance measurement 815 [I-D.fioccola-ippm-rfc6812-alt-mark-ext] describes an extension to 816 the Cisco SLA Protocol Measurement-Type UDP-Measurement, in order to 817 implement alternate marking methodology. 819 5. Hybrid measurement 821 The method has been explicitly designed for passive measurements but 822 it can also be used with active measurements. In order to have both 823 end to end measurements and intermediate measurements (hybrid 824 measurements) two end points can exchanges artificial traffic flows 825 and apply alternate marking over these flows. In the intermediate 826 points artificial traffic is managed in the same way as real traffic 827 and measured as specified before. 829 6. Compliance with RFC6390 guidelines 831 RFC6390 [RFC6390] defines a framework and a process for developing 832 Performance Metrics for protocols above and below the IP layer (such 833 as IP-based applications that operate over reliable or datagram 834 transport protocols). 836 This document doesn't aim to propose a new Performance Metric but a 837 new method of measurement for a few Performance Metrics that have 838 already been standardized. Nevertheless, it's worth applying 839 [RFC6390] guidelines to the present document, in order to provide a 840 more complete and coherent description of the proposed method. We 841 used a subset of the Performance Metric Definition template defined 842 by [RFC6390]. 844 o Metric name and description: as already stated, this document 845 doesn't propose any new Performance Metric. On the contrary, it 846 describes a novel method for measuring packet loss [RFC2680]. The 847 same concept, with small differences, can also be used to measure 848 delay [RFC2679], and jitter [RFC3393]. The document mainly 849 describes the applicability to packet loss measurement. 851 o Method of Measurement or Calculation: according to the method 852 described in the previous sections, the number of packets lost is 853 calculated by subtracting the value of the counter on the source 854 node from the value of the counter on the destination node. Both 855 counters must refer to the same color. The calculation is 856 performed when the value of the counters is in a steady state. 858 o Units of Measurement: the method calculates and reports the exact 859 number of packets sent by the source node and not received by the 860 destination node. 862 o Measurement Points: the measurement can be performed between 863 adjacent nodes, on a per-link basis, or along a multi-hop path, 864 provided that the traffic under measurement follows that path. In 865 case of a multi-hop path, the measurements can be performed both 866 end-to-end and hop-by-hop. 868 o Measurement Timing: the method have a constraint on the frequency 869 of measurements. In order to perform a measure, the counter must 870 be in a steady state: this happens when the traffic is being 871 colored with the alternate color; for example in the Telecom 872 Italia application of the method the time interval is set to 5 873 minutes. 875 o Implementation: the Telecom Italia application of the method uses 876 two encodings of the DSCP field to color the packets; this enables 877 the use of policy configurations on the router to color the 878 packets and accordingly configure the counter for each color. The 879 path followed by traffic being measured should be known in advance 880 in order to configure the counters along the path and be able to 881 compare the correct values. 883 o Use and Applications: the method can be used to measure packet 884 loss with high precision on live traffic; moreover, by combining 885 end-to-end and per-link measurements, the method is useful to 886 pinpoint the single link that is experiencing loss events. 888 o Reporting Model: the value of the counters has to be sent to a 889 centralized management system that perform the calculations; such 890 samples must contain a reference to the time interval they refer 891 to, so that the management system can perform the correct 892 correlation; the samples have to be sent while the corresponding 893 counter is in a steady state (within a time interval), otherwise 894 the value of the sample should be stored locally. 896 o Dependencies: the values of the counters have to be correlated to 897 the time interval they refer to; moreover, as far the Telecom 898 Italia application of the method is based on DSCP values, there 899 are significant dependencies on the usage of the DSCP field: it 900 must be possible to rely on unused DSCP values without affecting 901 QoS-related configuration and behavior; moreover, the intermediate 902 nodes must not change the value of the DSCP field not to alter the 903 measurement. 905 o Organization of Results: the method of measurement produces 906 singletons. 908 o Parameters: currently, the main parameter of the method is the 909 time interval used to alternate the colors and read the counters. 911 7. Security Considerations 913 This document specifies a method to perform measurements in the 914 context of a Service Provider's network and has not been developed to 915 conduct Internet measurements, so it does not directly affect 916 Internet security nor applications which run on the Internet. 917 However, implementation of this method must be mindful of security 918 and privacy concerns. 920 There are two types of security concerns: potential harm caused by 921 the measurements and potential harm to the measurements. For what 922 concerns the first point, the measurements described in this document 923 are passive, so there are no packets injected into the network 924 causing potential harm to the network itself and to data traffic. 925 Nevertheless, the method implies modifications on the fly to the IP 926 header of data packets: this must be performed in a way that doesn't 927 alter the quality of service experienced by packets subject to 928 measurements and that preserve stability and performance of routers 929 doing the measurements. The measurements themselves could be harmed 930 by routers altering the coloring of the packets, or by an attacker 931 injecting artificial traffic. Authentication techniques, such as 932 digital signatures, may be used where appropriate to guard against 933 injected traffic attacks. 935 The privacy concerns of network measurement are limited because the 936 method only relies on information contained in the IP header without 937 any release of user data. 939 8. Conclusions 941 The advantages of the method described in this document are: 943 o easy implementation: it can be implemented using features already 944 available on major routing platforms; 946 o low computational effort: the additional load on processing is 947 negligible; 949 o accurate packet loss measurement: single packet loss granularity 950 is achieved with a passive measurement; 952 o potential applicability to any kind of packet/frame -based 953 traffic: Ethernet, IP, MPLS, etc., both unicast and multicast; 955 o robustness: the method can tolerate out of order packets and it's 956 not based on "special" packets whose loss could have a negative 957 impact; 959 o no interoperability issues: the features required to implement the 960 method are available on all current routing platforms. 962 The method doesn't raise any specific need for standardization, but 963 it could be further improved by means of some extension to existing 964 protocols. Specifically, the use of DiffServ bits for coloring the 965 packets could not be a viable solution in some cases: a standard 966 method to color the packets for this specific application could be 967 beneficial. 969 9. IANA Considerations 971 There are no IANA actions required. 973 10. Acknowledgements 975 The authors would like to thank Domenico Laforgia, Daniele Accetta 976 and Mario Bianchetti for their contribution to the definition and the 977 implementation of the method. 979 11. References 981 11.1. Normative References 983 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 984 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 985 September 1999, . 987 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 988 Packet Loss Metric for IPPM", RFC 2680, 989 DOI 10.17487/RFC2680, September 1999, 990 . 992 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 993 Metric for IP Performance Metrics (IPPM)", RFC 3393, 994 DOI 10.17487/RFC3393, November 2002, 995 . 997 11.2. Informative References 999 [I-D.bryant-mpls-rfc6374-sfl] 1000 Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, 1001 M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft- 1002 bryant-mpls-rfc6374-sfl-00 (work in progress), October 1003 2015. 1005 [I-D.bryant-mpls-sfl-framework] 1006 Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, 1007 M., and Z. Li, "Synonymous Flow Label Framework", draft- 1008 bryant-mpls-sfl-framework-00 (work in progress), October 1009 2015. 1011 [I-D.bryant-mpls-synonymous-flow-labels] 1012 Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, 1013 M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft- 1014 bryant-mpls-synonymous-flow-labels-01 (work in progress), 1015 July 2015. 1017 [I-D.chen-ippm-coloring-based-ipfpm-framework] 1018 Chen, M., Zheng, L., Mirsky, G., Fioccola, G., and T. 1019 Mizrahi, "IP Flow Performance Measurement Framework", 1020 draft-chen-ippm-coloring-based-ipfpm-framework-06 (work in 1021 progress), March 2016. 1023 [I-D.cociglio-mboned-multicast-pm] 1024 Cociglio, M., Capello, A., Bonda, A., and L. Castaldelli, 1025 "A method for IP multicast performance monitoring", draft- 1026 cociglio-mboned-multicast-pm-01 (work in progress), 1027 October 2010. 1029 [I-D.fioccola-ippm-rfc6812-alt-mark-ext] 1030 Fioccola, G., Clemm, A., Cociglio, M., Chandramouli, M., 1031 and A. Capello, "Alternate Marking Extension to Cisco SLA 1032 Protocol RFC6812", draft-fioccola-ippm-rfc6812-alt-mark- 1033 ext-00 (work in progress), October 2015. 1035 [I-D.ietf-bier-mpls-encapsulation] 1036 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and 1037 S. Aldrin, "Encapsulation for Bit Index Explicit 1038 Replication in MPLS Networks", draft-ietf-bier-mpls- 1039 encapsulation-03 (work in progress), February 2016. 1041 [I-D.ietf-mpls-flow-ident] 1042 Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. 1043 Mirsky, "MPLS Flow Identification Considerations", draft- 1044 ietf-mpls-flow-ident-00 (work in progress), December 2015. 1046 [I-D.mirsky-bier-pmmm-oam] 1047 Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, 1048 "Performance Measurement (PM) with Marking Method in Bit 1049 Index Explicit Replication (BIER) Layer", draft-mirsky- 1050 bier-pmmm-oam-01 (work in progress), March 2016. 1052 [I-D.tempia-opsawg-p3m] 1053 Capello, A., Cociglio, M., Castaldelli, L., and A. Bonda, 1054 "A packet based method for passive performance 1055 monitoring", draft-tempia-opsawg-p3m-04 (work in 1056 progress), February 2014. 1058 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1059 Measurement for MPLS Networks", RFC 6374, 1060 DOI 10.17487/RFC6374, September 2011, 1061 . 1063 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 1064 Performance Metric Development", BCP 170, RFC 6390, 1065 DOI 10.17487/RFC6390, October 2011, 1066 . 1068 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 1069 IP Network Performance Metrics: Different Points of View", 1070 RFC 6703, DOI 10.17487/RFC6703, August 2012, 1071 . 1073 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1074 Weingarten, "An Overview of Operations, Administration, 1075 and Maintenance (OAM) Tools", RFC 7276, 1076 DOI 10.17487/RFC7276, June 2014, 1077 . 1079 Authors' Addresses 1081 Alessandro Capello 1082 Telecom Italia 1083 Via Reiss Romoli, 274 1084 Torino 10148 1085 Italy 1087 Email: alessandro.capello@telecomitalia.it 1088 Mauro Cociglio 1089 Telecom Italia 1090 Via Reiss Romoli, 274 1091 Torino 10148 1092 Italy 1094 Email: mauro.cociglio@telecomitalia.it 1096 Giuseppe Fioccola 1097 Telecom Italia 1098 Via Reiss Romoli, 274 1099 Torino 10148 1100 Italy 1102 Email: giuseppe.fioccola@telecomitalia.it 1104 Luca Castaldelli 1105 Telecom Italia 1106 Via Reiss Romoli, 274 1107 Torino 10148 1108 Italy 1110 Email: luca.castaldelli@telecomitalia.it 1112 Alberto Tempia Bonda 1114 Email: alberto.tempia@gmail.com