idnits 2.17.1 draft-cociglio-mboned-multicast-pm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 26, 2010) is 5144 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-bipi-mboned-ip-multicast-pm-requirement-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED M. Cociglio 3 Internet-Draft A. Capello 4 Intended status: Experimental A. Tempia Bonda 5 Expires: August 30, 2010 L. Castaldelli 6 Telecom Italia 7 February 26, 2010 9 A method for IP multicast performance monitoring 10 draft-cociglio-mboned-multicast-pm-00.txt 12 Abstract 14 This document defines a method to accomplish performance monitoring 15 measurements on live IP flows, including packet loss, one-way delay 16 and jitter. The proposed method is applicable to both unicast and 17 multicast traffic, but only IP multicast streams are considered in 18 this document. The method can be implemented using tools and 19 features already available on IP routers and does not require any 20 protocol extension. For this reason, it does not raise any 21 interoperability issue. However, the method could be further 22 improved by means of some extension to existing protocols, but this 23 aspect is left for further study and it is out of the scope of the 24 document. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on August 30, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Principle of the method . . . . . . . . . . . . . . . . . . . 5 69 4. Characteristics of the method . . . . . . . . . . . . . . . . 7 70 5. Detailed description of the method . . . . . . . . . . . . . . 9 71 5.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 9 72 5.2. One-way Delay . . . . . . . . . . . . . . . . . . . . . . 12 73 5.3. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 6. Deployment considerations . . . . . . . . . . . . . . . . . . 15 75 6.1. Multicast Flow Identification . . . . . . . . . . . . . . 15 76 6.2. Path Discovery . . . . . . . . . . . . . . . . . . . . . . 15 77 6.3. Flow Marking . . . . . . . . . . . . . . . . . . . . . . . 15 78 6.4. Monitoring Nodes . . . . . . . . . . . . . . . . . . . . . 16 79 6.5. Management System . . . . . . . . . . . . . . . . . . . . 17 80 6.6. Scalability . . . . . . . . . . . . . . . . . . . . . . . 17 81 6.7. Interoperability . . . . . . . . . . . . . . . . . . . . . 18 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 85 10. Informative References . . . . . . . . . . . . . . . . . . . . 22 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 88 1. Introduction 90 The deployment of video services managed by Service Providers 91 determined the following two main consequences: 93 o a widespread adoption of IP multicast to carry live TV channels 95 o a strong effort to guarantee a user experience comparable to 96 traditional TV broadcasting services 98 The second point implies a reinforced interest in performance 99 monitoring techniques, including packet loss, delay and jitter 100 measurements. As discussed in 101 [I-D.bipi-mboned-ip-multicast-pm-requirement], these techniques 102 should satisfy a few fundamental requirements: 104 o applicability to real traffic 106 o availability of packet loss, delay and jitter measurements 108 o possibility to have both end-to-end and segment-by-segment 109 measures, in order to exploit fault localization 111 o scalability 113 o low interoperability issues 115 Currently available tools are not compliant with all of these 116 requirements, thus the opportunity to work on a new solution. 118 The method described in the present document allows performing packet 119 loss, delay and jitter measurements on real IP multicast streams, on 120 an end-to-end or segment-by-segment basis. In the basic proposal, 121 there are no interoperability issues, since the method not only 122 doesn't require any extension to existing protocols, but also can be 123 implemented using tools already available on major routing platforms. 125 2. Terminology 127 Terminology used in this document: 129 o CB Bit (Control Bit): bit used to "mark" traffic to be monitored 131 o Block: sequence of consecutive packets with the CB set to the same 132 value 134 o MI (Marking Interval): duration of a block (it defines the 135 frequency at which CB is changed) 137 o PI (Polling Interval): it defines the frequency at which 138 performance information is collected 140 o NMS: Network Management System 142 3. Principle of the method 144 In order to perform packet loss measurements on real traffic flows, 145 it is generally required to include a sequence number in the packet 146 header and to have an equipment able to extract the sequence number 147 and check in real time if some packets are missing. Such approach 148 can be difficult to implement on real traffic: if UDP is used as the 149 transport protocol the sequence number is not available, on the other 150 hand if a higher layer sequence number (e.g. in the RTP header) is 151 used, extracting the information from the RTP header on every packet 152 and performing the calculation in real-time can be stressing for the 153 equipment. 155 The method proposed in this document is a simple and efficient way to 156 measure packet loss on real traffic streams, without numbering 157 packets or overloading network equipment. The basic idea is to 158 consider the traffic being measured as a sequence of blocks made of 159 consecutive packets. Blocks must be recognizable unambiguously on 160 every node along the path and can be defined based on the number of 161 packets (that is each block contains a configured fixed number of 162 packets) or on its duration (f.i. blocks are 5 minutes long and the 163 number of packets can vary on each block). By counting on a node the 164 number of packets in each block and comparing the values with those 165 measured by a different router along the path, it is possible to 166 measure packet loss (if any) between the two nodes. 168 Figure 1 represents a simple multicast forwarding tree made of 6 169 nodes and 3 receivers. 171 +-----+ +--------+ 172 | SRC | +--------<> R5 <>--- Recv 1 173 +-----+ | +--------+ 174 | | 175 | | 176 +---<>---+ +--------+ +---<>---+ +--------+ 177 | R1 <>----<> R2 <>----<> R3 <>---<> R6 <>--- Recv 2 178 +--------+ +---<>---+ +--------+ +--------+ 179 | 180 | 181 | +--------+ 182 +---------<> R4 <>--- Recv 3 183 +--------+ 184 <> Interface 185 ---- Link 187 Figure 1: Example of multicast forwarding tree 189 Blocks of consecutive packets are identified using some information 190 in the packet flow itself, for instance a field in the packet header 191 that can assume two different values. The first-hop router (R1 in 192 figure 1) sets such field and changes it periodically (f.i. every 5 193 minutes or every 100000 packets) alternating the two values, so that 194 within a time interval all the packets have the field set to the same 195 value, but within the following time interval all the packets have 196 the field set to the second value. If blocks are defined on a time 197 basis, the number of packets in each block is not fixed, but can vary 198 according to fluctuations of the flow. However, since blocks are 199 created on the first-hop router and not modified along the path, all 200 the nodes should count the same number of packets within the same 201 block (if no packet loss occurs). By counting the number of packets 202 in the block on each node and comparing those values, it's possible 203 to unveil any packet loss with the maximum precision (a single packet 204 lost) and to identify where the loss occurred. 206 The same approach can also be used to measure one-way delay and 207 jitter. In this case, the transition from a block to the following 208 one is used as a time reference to calculate the delay between any 209 two nodes in the network. Time synchronization is required in order 210 to have a consistent delay measurement. 212 Jitter can be easily estimated from delay measures and does not 213 require necessarily synchronization between the nodes. 215 4. Characteristics of the method 217 The method described in this document fulfills all the requirements 218 described in , in addition it is characterized by the following 219 advantages: 221 o easy implementation (use of features already available on major 222 routing platforms) 224 o low computational effort 226 o highly precise packet loss measurement (single packet loss 227 granularity) 229 o applicability to any kind of IP traffic (unicast and multicast) 231 o independence from the flow bit rate 233 o independence from higher level protocols (e.g. RTP, etc.) or 234 video coding (e.g. MPEG, etc.) 236 o no interoperability issues 238 Figure 2 represents a subtree of the multicast forwarding tree 239 depicted in figure 1 and shows how the method can be used to measure 240 packet loss (or one-way delay and jitter) on different network 241 segments. 243 +-----+ 244 | SRC | 245 +-----+ 246 | 247 | 248 +---<>---+ +--------+ +--------+ +--------+ 249 | R1 <>----<> R2 <>---<> R3 <>----<> R6 <>--- Recv 2 250 +--------+ +--------+ +--------+ +--------+ 251 . . . . . . 252 . . . . . . 253 . <--------> <------> . 254 . Node Packet Loss Link Packet Loss . 255 . . 256 <---------------------------------------------------> 257 End-to-End Packet loss 259 Figure 2: Available measurements 261 By applying the method on different interfaces along the multicast 262 distribution tree, it is possible to measure packet loss across a 263 single link, across a node (e.g. due to queuing management) or end- 264 to-end. In general, it is possible to monitor any segment of the 265 network. 267 5. Detailed description of the method 269 This section describes more in detail the application of the method 270 for measuring packet loss, one-way delay and jitter in packet- 271 switched networks. 273 5.1. Packet Loss 275 Figure 1 shows how the method described in this document can be used 276 to measure the packet loss across a link between two adjacent nodes. 277 For example, referring Figure 1, we are interested in monitoring the 278 packet loss on the link between R1 and R2. According to the method 279 briefly described in Section 3, since router R1 is the first-hop 280 router, it is responsible for marking the field in the packet header. 281 As discussed before, a single bit is sufficient to this purpose : the 282 bit used to mark the traffic is called Control Bit (CB bit). By 283 assuming alternately on each period values 0 and 1, the Control Bit 284 generates a sort of square-wave signal and the original traffic flow 285 is converted in a sequence of blocks. The semi-period T/2 of the 286 square-wave is called Marking Interval (MI) and corresponds to the 287 duration of each single block. The action of "marking" the traffic 288 (setting the Control Bit) can be executed on the ingress interface of 289 R1. On the egress interface of R1 two counters, named C(0)R1 and 290 C(1)R1, will count the number of packets with the CB bit set to 0 and 291 1 respectively. As long as traffic is marked to 0, only counter 292 C(0)R1 is incremented while C(1)R1 doesn't change. Counters C(0)R1 293 and C(1)R1 can be used as reference values to determine the packet 294 loss from R1 to R2 (or to other nodes along the path toward the 295 destination). 297 Router R2, similarly, will instantiate on its ingress interface two 298 counters, C(0)R2 and C(1)R2, to count the number of packets received 299 with the CB bit set to 0 and 1 respectively. By comparing C(0)R1 300 with C(0)R2 and C(1)R1 with C(1)R2 and repeating this operation on 301 every block, it is possible to detect the number of packets lost in 302 the link between R1 and R2. 304 Similarly, using 2 counters on the R2 egress interface and on every 305 interface along the path, it is possible to use them to determine 306 packet loss on every network segment and therefore detect where 307 packet losses occur. 309 T/2 T 310 <------> <--------------> 311 +-------+ +-------+ 312 | | | | 313 +-------+ +-------+ +------- 314 Control Bit 0000000011111111000000001111111100000000 316 Block Block Block Block Block 317 <------><------><------><------><------> 319 +---------+ +---------+ 320 -------> <> R1 <> -----------------------> <> R2 <> ---> 321 +---------+ +---------+ 323 Figure 3: Application of the method to compute link packet loss 325 The method doesn't require any synchronization in the network, as the 326 traffic flow implicitly carries the synchronization in the 327 alternation of values of the Control Bit. 329 Table 1 shows an example of the use of router counters to calculate 330 the packet loss between R1 and R2. Time is expressed in minutes and 331 we assume to check counter values on each router every two minutes 332 (it doesn't matter if R1 and R2 are not synchronized). We assume 333 also that the Marking Interval is 5 minutes, meaning that the CB bit 334 changes every 5 minutes. 336 The columns contain the values of C(0) and C(1) for both R1 and R2, 337 in particular, the table shows the values they assume every 2 338 minutes. Counters increases according to the Control Bit: when CB is 339 0, only C(0) increases and C(1) is still, when CB is 1, only C(1) 340 increases and C(0) is still. Packet loss calculation must be 341 performed when a counter is stable, because it means that a block is 342 terminated and we can count exactly the number of packets within that 343 block. 345 +------+--------+--------+--------+--------+ 346 | Time | C(0)R1 | C(1)R1 | C(0)R2 | C(1)R2 | 347 +------+--------+--------+--------+--------+ 348 | 0 | 0 | 0 | 0 | 0 | 349 | | | | | | 350 | 2 | 112 | 0 | 110 | 0 | 351 | | | | | | 352 | 4 | 234 | 0 | 237 | 0 | 353 | | | | | | 354 | 6 | 277 | 103 | 277 | 101 | 355 | | | | | | 356 | 8 | 277 | 212 | 277 | 210 | 357 | | | | | | 358 | 10 | 277 | 259 | 277 | 256 | 359 | | | | | | 360 | 12 | 403 | 262 | 401 | 261 | 361 | | | | | | 362 | 14 | 827 | 262 | 819 | 261 | 363 +------+--------+--------+--------+--------+ 365 Table 1: Evaluation of counters for packet loss measurements 367 For example, looking at Table 1, traffic is initially marked with 368 CB=0 because only C(0)R1 and C(0)R2 increase, while C(1) counters are 369 still. At minute 6, C(1) counters have started moving while C(0) 370 counters have stopped (in fact at minute 8 they have the same values 371 they had at minute 6): it means that the block with CB=0 is 372 terminated and the flow is now being marked with CB=1. Hence the 373 value of C(0) counters gives the exact number of packets transmitted 374 in that block. Comparing C(0)R1 and C(0)R2 at minute 8 it is 375 possible to verify if any packet of the first block was lost in the 376 link between R1 and R2 (in the case shown in the table C(0)R1 = 377 C(0)R2 = 277, meaning that no packets were lost). At minute 12, C(0) 378 counters have started moving again while C(1) counters have stopped 379 (at minute 14 they have the same values they had at minute 12): it 380 means now that the block with CB=1 is terminated and the flow is now 381 being marked again with CB=0. The value of C(1) counters gives the 382 exact number of packets transmitted in the block just terminated. 383 Comparing C(1)R1 and C(1)R2 at minute 14 it is possible to verify if 384 any packet of that block was lost (this time C(1)R1 = 262 and C(1)R2 385 = 261, meaning that 1 packet was lost). 387 The same method can be applied to more complex networks, as far as 388 the measurement is enabled on the path followed by the traffic flow 389 being analyzed. 391 5.2. One-way Delay 393 The method to measure one-way delay directly refers to the packet 394 loss method. The event when the marking changes from 0 to 1 or vice 395 versa is used as a time reference to calculate the delay. 396 Considering again the example depicted in Figure 1, R1 will record as 397 an event every change in the marking, by storing a timestamp TS R1 398 every time it sends the first packet of a block. R2 will do the same 399 operation, recording TS R2 every time it receives the first packet of 400 a block. By comparing TS R1 and TS R2 it's possible to calculate the 401 delay between R1 and R2. 403 In order to coherently compare the timestamps collected on different 404 routers, synchronization is required in the network. Moreover, the 405 measurement can be considered valid only if no packet loss occurred. 406 If some packets are lost it is possible that the first packet of a 407 block on R1 is not the first packet of the same block on R2. 409 Going into details, whenever an interface sends/receives the first 410 packet of a block (that is a packet with Control Bit set to 0 or 1, 411 while previous packets were marked with the opposite value), a 412 timestamp should be recorded. By comparing timestamps recorded on 413 different nodes in the network, it is possible to calculate the delay 414 on each network segment. As stated before, synchronization is 415 required to get a reliable delay measurement. 417 Table 2 considers the same example of Figure 1, but both packet loss 418 and one-way delay are now measured. Time is expressed in minutes, 419 while timestamps are expressed in milliseconds (hours and minutes are 420 omitted for simplicity). We assume to check counters and timestamp 421 values on each router every two minutes and we assume the Marking 422 Interval is 5 minutes. Routers R1 and R2, besides incrementing 423 counters C(0) and C(1), now also set a timestamp whenever the 424 corresponding counter begins incrementing (i.e. the first packet is 425 sent/received). 427 +-------+-----+--------+-----+--------+-----+--------+-----+--------+ 428 | Time | R1 | TS0 R1 | R1 | TS1 R1 | R2 | TS0 R2 | R2 | TS1 R2 | 429 | (min) | C0 | (sec) | C1 | (sec) | C0 | (sec) | C1 | (sec) | 430 +-------+-----+--------+-----+--------+-----+--------+-----+--------+ 431 | 0 | 0 | - | 0 | - | 0 | - | 0 | - | 432 | | | | | | | | | | 433 | 2 | 112 | 7.483 | 0 | - | 110 | 7.487 | 0 | - | 434 | | | | | | | | | | 435 | 4 | 234 | - | 0 | - | 237 | - | 0 | - | 436 | | | | | | | | | | 437 | 6 | 277 | - | 103 | 3.621 | 277 | - | 101 | 3.626 | 438 | | | | | | | | | | 439 | 8 | 277 | - | 212 | - | 277 | - | 210 | - | 440 | | | | | | | | | | 441 | 10 | 277 | - | 259 | - | 277 | - | 256 | - | 442 | | | | | | | | | | 443 | 12 | 403 | 5.752 | 262 | - | 401 | 5.757 | 262 | - | 444 | | | | | | | | | | 445 | 14 | 827 | - | 262 | - | 819 | - | 262 | - | 446 +-------+-----+--------+-----+--------+-----+--------+-----+--------+ 448 Table 2: Evaluation of counters for delay measurements 450 At minute 2, C(0) counters have started moving on both routers and 451 the first timestamp (relative to the first packet with CB=0) is 452 recorded: R1 timestamp is 7.483, R2 timestamp is 7.487. Notice that 453 those timestamps refer to the same packet because the first packet of 454 the block is the same on both routers (if no packet loss has 455 occurred): therefore they can be compared and, if we assume that R1 456 and R2 are synchronized, they can be used to measure the delay 457 between R1 and R2 (4 msec). At minute 6 the marking has changed, 458 C(0) counters have stopped and C(1) counters have started moving: it 459 means that a new block with CB=1 has started, therefore R1 and R2 460 record a new timestamp. The new timestamp refers to the first packet 461 of the block with CB=1 (which is the same packet on both routers). 462 R1 timestamp is 3.621, R2 timestamp is 3.626; again, the two values 463 are comparable and the delay is 5 msec. 465 5.3. Jitter 467 Similarly to one-way delay measurement, the method to evaluate the 468 jitter directly refers to the packet loss method. Again, the event 469 when the marking changes from 0 to 1 or vice versa is used as a time 470 reference to record timestamps: considering the example depicted in 471 Figure 1, R1 will store a timestamp TS R1 every time it sends the 472 first packet of a block and R2 will record a timestamp TS R2 every 473 time it receives the first packet of a block. 475 The jitter can be easily derived from one-way delay measurement. For 476 example, it is possible to evaluate the jitter calculating the delay 477 variation on two consecutive samples: considering the values shown in 478 Table 2, since the measured delay is 4 msec for the first sample and 479 5 msec for the second sample, the derived jitter is 1 msec. 481 In this case, synchronization in the network is not strictly required 482 because it is compensated by jitter calculation. 484 6. Deployment considerations 486 This section describes some aspects that should be taken into account 487 when the method is deployed in a real network. For sake of 488 simplicity, we consider a network scenario where only packet loss is 489 being measured, but all the considerations are valid and can be 490 easily extended to one-way delay and jitter measurement as well. 492 6.1. Multicast Flow Identification 494 The first thing to do in order to monitor multicast traffic in a real 495 network is to identify the flow to be monitored. The method 496 described in this document is able to monitor a single multicast 497 stream or multiple flows grouped together, but in this case 498 measurement is consistent only if all the flows in the group follow 499 the same path. Moreover, a network operator must be aware that, if 500 measurement is performed on many streams, it is not possible to 501 determine exactly which flow was affected by packets loss (all the 502 flows are considered as a single stream by the monitoring system). 504 6.2. Path Discovery 506 Once the multicast stream(s) to be monitored is identified, it is 507 important to enable the monitoring system in the proper nodes. In 508 order to have just an end-to-end monitoring it is sufficient to 509 enable the monitoring system on the first and last-hop routers of the 510 path: the mechanism is completely transparent to intermediate nodes 511 and independent from the path followed by multicast streams. At the 512 contrary, to monitor the flow along its whole path and on every 513 segment (every node and link) it is necessary to enable monitoring on 514 every node from the source to the destination. To this purpose it 515 isn't strictly required to know the exact path followed by the flow. 516 If, for example, the flow has multiple paths to reach a destination, 517 it is sufficient to enable the monitoring system on every path, then 518 a Management System will process just the right information (or it 519 will process all the counters but some of them will be zero, meaning 520 that the considered flow is not flowing through the corresponding 521 interface). 523 6.3. Flow Marking 525 Once the multicast stream is identified and its path is known, it is 526 necessary to "mark" the flow so to create packet blocks. This means 527 choosing where to activate the marking and how to "mark" packets. 529 Regarding the first point, it is desirable, in general, to have a 530 single marking node because it is simpler to manage and doesn't rise 531 any risk of conflict (consider the case where two nodes mark the same 532 flow). To this purpose it is necessary to mark the flow as close as 533 possible to the multicast source, f.i. on the first router downstream 534 to multicast sources where all the multicast streams can be marked. 535 In addition, marking a flow close to the source allows an end-to-end 536 measurement if a measurement point is enabled on the last-hop router 537 as well. Theoretically, the flow could be marked before the first- 538 hop router, directly by the sources: in this case the first-hop 539 router just need to count packets of each block and acts as an 540 intermediate node. The only requirement is that marking must change 541 periodically and every node along the path must be able to identify 542 unambiguously marked packets. 544 On the contrary, if many marking nodes are required, it is important 545 that each marking node marks different flows so to avoid "marking 546 conflicts" that would invalidate measurements. 548 Regarding the second point, as described in Section 5.1, a field in 549 the IP header could be sufficient for this purpose. As an example, 550 it is possible to use the two less significant bits of the DSCP field 551 (bit 0 and bit 1). One of them (bit 0) is always set to value 1 and 552 is used to identify the flow to be measured, the other one (bit 1) is 553 changed periodically and assumes alternately values 0 and 1. This 554 way traffic flow is transformed in a sequence of blocks where each 555 block has all the packets with bit 1 of DSCP field set to the same 556 value (0 or 1). Of course, marking can be based on DSCP field if 557 differentiated packet scheduling is not based on that field and, for 558 instance, it is based only on IP Precedence bits. 560 In practice, the marking using the DSCP field can be performed 561 configuring on the first-hop router an access list that intercepts 562 the flow(s) to be measured and a policy that sets the DSCP field 563 accordingly. Flows to be measured can be changed easily modifying 564 the access list. Moreover, since traffic marking must change to 565 create traffic blocks, it is necessary to change the policy 566 periodically: this can be done for example using an automatic script 567 that periodically modifies the configuration. 569 6.4. Monitoring Nodes 571 The operation of marking flows to be monitored can be accomplished by 572 a single node, namely the first-hop router. All the intermediate 573 nodes are not required to perform any particular operation except 574 counting marked packets they receive and forward: this operation can 575 be enabled on every router along the multicast forwarding tree or 576 just on a small subset, depending on which network segment we want to 577 monitor (a single link, a particular metro area, the backbone, the 578 whole path). 580 The operation of counting packets on intermediate nodes is very 581 simple and can be accomplished f.i. configuring an access list that 582 intercepts packets belonging to the multicast group being monitored 583 with certain DSCP values (those configured on the first-hop router 584 and used to mark the flow). This way only "marked" packets will be 585 counted. Since marking changes periodically between two values, two 586 counters (one for each value) are needed for a single flow being 587 monitored: one counting packets with CB = 0 and one counting packets 588 with CB = 1. 590 Marking and counting are two decoupled operations: it is possible to 591 mark all the multicast flows on the source but monitor just one or 592 few flows, by enabling counters only for the intended streams. 594 6.5. Management System 596 Nodes enabled to perform performance monitoring collect counters 597 relative to multicast flows, but they are not able to use this 598 information to measure packet loss, because they only have local 599 information and lack a global view of the network. For this reason 600 an external Network Management System (NMS) is required to collect 601 and elaborate data and to perform packet loss calculation. The NMS 602 compares values of counters from different nodes and is then able to 603 determine if some packets were lost (even a single packet) and also 604 where packets were lost. 606 Information collected by the routers (counter values) needs to be 607 transferred to the NMS periodically. This can be accomplished f.i. 608 via FTP or TFTP and can be done in Push Mode or Polling Mode. In the 609 first case, each router sends periodically the information it 610 collects to the NMS, in the latter case it is the NMS that 611 periodically polls routers to collect information. In any case, the 612 Polling Interval (PI) should be compliant with the Shannon theorem: 613 (PI < MI / 2).This means that the Management System should collect, 614 during every Marking Interval, at least two samples of each counter 615 (in order to determine if the counter is incrementing or is still 616 within the considered interval). 618 6.6. Scalability 620 This section describes what is needed on a node in order to enable 621 the performance measurement system to the purpose of understand its 622 scalability. 624 Regarding the marking, it is preferable to have a single marking node 625 for reasons explained in Section 6.3. The marking can be easily 626 performed on a single multicast flow as well as on the entire 627 multicast traffic. What is needed for example is a single policy 628 that marks all the intended traffic with a specific DSCP value, but 629 this operation is usually already performed by routers for QoS 630 purpose. 632 Regarding the counting, what is needed are two counters for every 633 flow (or group of flows) being monitored and for every interface 634 where the monitoring system is activated. For example, in order to 635 monitor 3 multicast flows on a router with 4 interfaces involved, 24 636 counters are needed (2 counters for each of the 3 flows on each of 637 the 4 interfaces). If access lists are used to count packets, a 638 single ACL can be used to count packets of many flows (access list 639 entries will increase with the number of flows), but a different 640 access list is required on every interface. 642 The number of counters and access lists can easily increase with the 643 number of flows and interfaces, however monitoring is not required on 644 every interface (it should be activated only on interfaces belonging 645 to the multicast forwarding tree). Besides, it can be sufficient to 646 monitor few flows to have a monitoring system that spans the whole 647 network because multicast flows follow the shortest path which is 648 usually the same for all the streams (except in case of multiple 649 equal cost paths), therefore flows using the same path are subject to 650 give similar performance results. 652 6.7. Interoperability 654 The method described in this document doesn't raise any 655 interoperability issue, since it doesn't require any new protocol or 656 any kind of interaction among nodes. Traffic marking can be 657 performed by a single node, while counting of packets is performed 658 locally by each router and the correlation between counters is done 659 by an external NMS. 661 The only requirement is that every node should be able to identify 662 marked flows, but, as explained in Sections 6.3 and 6.4, this can be 663 accomplished using simple functionalities that doesn't have any 664 interoperability issue and are already available on major routing 665 platforms. 667 7. Security Considerations 669 TBD 671 8. IANA Considerations 673 There are no IANA actions required. 675 9. Acknowledgements 677 The authors would like to thank Domenico Laforgia for his 678 contribution to the definition of the method. The authors would also 679 like to thank Paolo Fasano and Matteo Cravero for their useful 680 suggestions. 682 10. Informative References 684 [I-D.bipi-mboned-ip-multicast-pm-requirement] 685 Bianchetti, M., Picciano, G., Chen, M., and J. Qiu, 686 "Requirements for IP multicast performance monitoring", 687 draft-bipi-mboned-ip-multicast-pm-requirement-00 (work in 688 progress), July 2009. 690 Authors' Addresses 692 Mauro Cociglio 693 Telecom Italia 694 Via Reiss Romoli, 274 695 Torino 10148 696 Italy 698 Email: mauro.cociglio@telecomitalia.it 700 Alessandro Capello 701 Telecom Italia 702 Via Reiss Romoli, 274 703 Torino 10148 704 Italy 706 Email: alessandro.capello@telecomitalia.it 708 Alberto Tempia Bonda 709 Telecom Italia 710 Via Reiss Romoli, 274 711 Torino 10148 712 Italy 714 Email: alberto.tempiabonda@telecomitalia.it 716 Luca Castaldelli 717 Telecom Italia 718 Via Reiss Romoli, 274 719 Torino 10148 720 Italy 722 Email: luca.castaldelli@telecomitalia.it