MBONED M. Cociglio Internet-Draft A. Capello Intended status: Experimental A. Tempia Bonda Expires: August 30, 2010 L. Castaldelli Telecom Italia February 26, 2010 A method for IP multicast performance monitoring draft-cociglio-mboned-multicast-pm-00.txt Abstract This document defines a method to accomplish performance monitoring measurements on live IP flows, including packet loss, one-way delay and jitter. The proposed method is applicable to both unicast and multicast traffic, but only IP multicast streams are considered in this document. The method can be implemented using tools and features already available on IP routers and does not require any protocol extension. For this reason, it does not raise any interoperability issue. However, the method could be further improved by means of some extension to existing protocols, but this aspect is left for further study and it is out of the scope of the document. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 30, 2010. Cociglio, et al. Expires August 30, 2010 [Page 1] Internet-Draft IP multicast performance monitoring February 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Principle of the method . . . . . . . . . . . . . . . . . . . 5 4. Characteristics of the method . . . . . . . . . . . . . . . . 7 5. Detailed description of the method . . . . . . . . . . . . . . 9 5.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. One-way Delay . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Deployment considerations . . . . . . . . . . . . . . . . . . 15 6.1. Multicast Flow Identification . . . . . . . . . . . . . . 15 6.2. Path Discovery . . . . . . . . . . . . . . . . . . . . . . 15 6.3. Flow Marking . . . . . . . . . . . . . . . . . . . . . . . 15 6.4. Monitoring Nodes . . . . . . . . . . . . . . . . . . . . . 16 6.5. Management System . . . . . . . . . . . . . . . . . . . . 17 6.6. Scalability . . . . . . . . . . . . . . . . . . . . . . . 17 6.7. Interoperability . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 10. Informative References . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Cociglio, et al. Expires August 30, 2010 [Page 2] Internet-Draft IP multicast performance monitoring February 2010 1. Introduction The deployment of video services managed by Service Providers determined the following two main consequences: o a widespread adoption of IP multicast to carry live TV channels o a strong effort to guarantee a user experience comparable to traditional TV broadcasting services The second point implies a reinforced interest in performance monitoring techniques, including packet loss, delay and jitter measurements. As discussed in [I-D.bipi-mboned-ip-multicast-pm-requirement], these techniques should satisfy a few fundamental requirements: o applicability to real traffic o availability of packet loss, delay and jitter measurements o possibility to have both end-to-end and segment-by-segment measures, in order to exploit fault localization o scalability o low interoperability issues Currently available tools are not compliant with all of these requirements, thus the opportunity to work on a new solution. The method described in the present document allows performing packet loss, delay and jitter measurements on real IP multicast streams, on an end-to-end or segment-by-segment basis. In the basic proposal, there are no interoperability issues, since the method not only doesn't require any extension to existing protocols, but also can be implemented using tools already available on major routing platforms. Cociglio, et al. Expires August 30, 2010 [Page 3] Internet-Draft IP multicast performance monitoring February 2010 2. Terminology Terminology used in this document: o CB Bit (Control Bit): bit used to "mark" traffic to be monitored o Block: sequence of consecutive packets with the CB set to the same value o MI (Marking Interval): duration of a block (it defines the frequency at which CB is changed) o PI (Polling Interval): it defines the frequency at which performance information is collected o NMS: Network Management System Cociglio, et al. Expires August 30, 2010 [Page 4] Internet-Draft IP multicast performance monitoring February 2010 3. Principle of the method In order to perform packet loss measurements on real traffic flows, it is generally required to include a sequence number in the packet header and to have an equipment able to extract the sequence number and check in real time if some packets are missing. Such approach can be difficult to implement on real traffic: if UDP is used as the transport protocol the sequence number is not available, on the other hand if a higher layer sequence number (e.g. in the RTP header) is used, extracting the information from the RTP header on every packet and performing the calculation in real-time can be stressing for the equipment. The method proposed in this document is a simple and efficient way to measure packet loss on real traffic streams, without numbering packets or overloading network equipment. The basic idea is to consider the traffic being measured as a sequence of blocks made of consecutive packets. Blocks must be recognizable unambiguously on every node along the path and can be defined based on the number of packets (that is each block contains a configured fixed number of packets) or on its duration (f.i. blocks are 5 minutes long and the number of packets can vary on each block). By counting on a node the number of packets in each block and comparing the values with those measured by a different router along the path, it is possible to measure packet loss (if any) between the two nodes. Figure 1 represents a simple multicast forwarding tree made of 6 nodes and 3 receivers. +-----+ +--------+ | SRC | +--------<> R5 <>--- Recv 1 +-----+ | +--------+ | | | | +---<>---+ +--------+ +---<>---+ +--------+ | R1 <>----<> R2 <>----<> R3 <>---<> R6 <>--- Recv 2 +--------+ +---<>---+ +--------+ +--------+ | | | +--------+ +---------<> R4 <>--- Recv 3 +--------+ <> Interface ---- Link Figure 1: Example of multicast forwarding tree Blocks of consecutive packets are identified using some information Cociglio, et al. Expires August 30, 2010 [Page 5] Internet-Draft IP multicast performance monitoring February 2010 in the packet flow itself, for instance a field in the packet header that can assume two different values. The first-hop router (R1 in figure 1) sets such field and changes it periodically (f.i. every 5 minutes or every 100000 packets) alternating the two values, so that within a time interval all the packets have the field set to the same value, but within the following time interval all the packets have the field set to the second value. If blocks are defined on a time basis, the number of packets in each block is not fixed, but can vary according to fluctuations of the flow. However, since blocks are created on the first-hop router and not modified along the path, all the nodes should count the same number of packets within the same block (if no packet loss occurs). By counting the number of packets in the block on each node and comparing those values, it's possible to unveil any packet loss with the maximum precision (a single packet lost) and to identify where the loss occurred. The same approach can also be used to measure one-way delay and jitter. In this case, the transition from a block to the following one is used as a time reference to calculate the delay between any two nodes in the network. Time synchronization is required in order to have a consistent delay measurement. Jitter can be easily estimated from delay measures and does not require necessarily synchronization between the nodes. Cociglio, et al. Expires August 30, 2010 [Page 6] Internet-Draft IP multicast performance monitoring February 2010 4. Characteristics of the method The method described in this document fulfills all the requirements described in , in addition it is characterized by the following advantages: o easy implementation (use of features already available on major routing platforms) o low computational effort o highly precise packet loss measurement (single packet loss granularity) o applicability to any kind of IP traffic (unicast and multicast) o independence from the flow bit rate o independence from higher level protocols (e.g. RTP, etc.) or video coding (e.g. MPEG, etc.) o no interoperability issues Figure 2 represents a subtree of the multicast forwarding tree depicted in figure 1 and shows how the method can be used to measure packet loss (or one-way delay and jitter) on different network segments. +-----+ | SRC | +-----+ | | +---<>---+ +--------+ +--------+ +--------+ | R1 <>----<> R2 <>---<> R3 <>----<> R6 <>--- Recv 2 +--------+ +--------+ +--------+ +--------+ . . . . . . . . . . . . . <--------> <------> . . Node Packet Loss Link Packet Loss . . . <---------------------------------------------------> End-to-End Packet loss Figure 2: Available measurements By applying the method on different interfaces along the multicast distribution tree, it is possible to measure packet loss across a Cociglio, et al. Expires August 30, 2010 [Page 7] Internet-Draft IP multicast performance monitoring February 2010 single link, across a node (e.g. due to queuing management) or end- to-end. In general, it is possible to monitor any segment of the network. Cociglio, et al. Expires August 30, 2010 [Page 8] Internet-Draft IP multicast performance monitoring February 2010 5. Detailed description of the method This section describes more in detail the application of the method for measuring packet loss, one-way delay and jitter in packet- switched networks. 5.1. Packet Loss Figure 1 shows how the method described in this document can be used to measure the packet loss across a link between two adjacent nodes. For example, referring Figure 1, we are interested in monitoring the packet loss on the link between R1 and R2. According to the method briefly described in Section 3, since router R1 is the first-hop router, it is responsible for marking the field in the packet header. As discussed before, a single bit is sufficient to this purpose : the bit used to mark the traffic is called Control Bit (CB bit). By assuming alternately on each period values 0 and 1, the Control Bit generates a sort of square-wave signal and the original traffic flow is converted in a sequence of blocks. The semi-period T/2 of the square-wave is called Marking Interval (MI) and corresponds to the duration of each single block. The action of "marking" the traffic (setting the Control Bit) can be executed on the ingress interface of R1. On the egress interface of R1 two counters, named C(0)R1 and C(1)R1, will count the number of packets with the CB bit set to 0 and 1 respectively. As long as traffic is marked to 0, only counter C(0)R1 is incremented while C(1)R1 doesn't change. Counters C(0)R1 and C(1)R1 can be used as reference values to determine the packet loss from R1 to R2 (or to other nodes along the path toward the destination). Router R2, similarly, will instantiate on its ingress interface two counters, C(0)R2 and C(1)R2, to count the number of packets received with the CB bit set to 0 and 1 respectively. By comparing C(0)R1 with C(0)R2 and C(1)R1 with C(1)R2 and repeating this operation on every block, it is possible to detect the number of packets lost in the link between R1 and R2. Similarly, using 2 counters on the R2 egress interface and on every interface along the path, it is possible to use them to determine packet loss on every network segment and therefore detect where packet losses occur. Cociglio, et al. Expires August 30, 2010 [Page 9] Internet-Draft IP multicast performance monitoring February 2010 T/2 T <------> <--------------> +-------+ +-------+ | | | | +-------+ +-------+ +------- Control Bit 0000000011111111000000001111111100000000 Block Block Block Block Block <------><------><------><------><------> +---------+ +---------+ -------> <> R1 <> -----------------------> <> R2 <> ---> +---------+ +---------+ Figure 3: Application of the method to compute link packet loss The method doesn't require any synchronization in the network, as the traffic flow implicitly carries the synchronization in the alternation of values of the Control Bit. Table 1 shows an example of the use of router counters to calculate the packet loss between R1 and R2. Time is expressed in minutes and we assume to check counter values on each router every two minutes (it doesn't matter if R1 and R2 are not synchronized). We assume also that the Marking Interval is 5 minutes, meaning that the CB bit changes every 5 minutes. The columns contain the values of C(0) and C(1) for both R1 and R2, in particular, the table shows the values they assume every 2 minutes. Counters increases according to the Control Bit: when CB is 0, only C(0) increases and C(1) is still, when CB is 1, only C(1) increases and C(0) is still. Packet loss calculation must be performed when a counter is stable, because it means that a block is terminated and we can count exactly the number of packets within that block. Cociglio, et al. Expires August 30, 2010 [Page 10] Internet-Draft IP multicast performance monitoring February 2010 +------+--------+--------+--------+--------+ | Time | C(0)R1 | C(1)R1 | C(0)R2 | C(1)R2 | +------+--------+--------+--------+--------+ | 0 | 0 | 0 | 0 | 0 | | | | | | | | 2 | 112 | 0 | 110 | 0 | | | | | | | | 4 | 234 | 0 | 237 | 0 | | | | | | | | 6 | 277 | 103 | 277 | 101 | | | | | | | | 8 | 277 | 212 | 277 | 210 | | | | | | | | 10 | 277 | 259 | 277 | 256 | | | | | | | | 12 | 403 | 262 | 401 | 261 | | | | | | | | 14 | 827 | 262 | 819 | 261 | +------+--------+--------+--------+--------+ Table 1: Evaluation of counters for packet loss measurements For example, looking at Table 1, traffic is initially marked with CB=0 because only C(0)R1 and C(0)R2 increase, while C(1) counters are still. At minute 6, C(1) counters have started moving while C(0) counters have stopped (in fact at minute 8 they have the same values they had at minute 6): it means that the block with CB=0 is terminated and the flow is now being marked with CB=1. Hence the value of C(0) counters gives the exact number of packets transmitted in that block. Comparing C(0)R1 and C(0)R2 at minute 8 it is possible to verify if any packet of the first block was lost in the link between R1 and R2 (in the case shown in the table C(0)R1 = C(0)R2 = 277, meaning that no packets were lost). At minute 12, C(0) counters have started moving again while C(1) counters have stopped (at minute 14 they have the same values they had at minute 12): it means now that the block with CB=1 is terminated and the flow is now being marked again with CB=0. The value of C(1) counters gives the exact number of packets transmitted in the block just terminated. Comparing C(1)R1 and C(1)R2 at minute 14 it is possible to verify if any packet of that block was lost (this time C(1)R1 = 262 and C(1)R2 = 261, meaning that 1 packet was lost). The same method can be applied to more complex networks, as far as the measurement is enabled on the path followed by the traffic flow being analyzed. Cociglio, et al. Expires August 30, 2010 [Page 11] Internet-Draft IP multicast performance monitoring February 2010 5.2. One-way Delay The method to measure one-way delay directly refers to the packet loss method. The event when the marking changes from 0 to 1 or vice versa is used as a time reference to calculate the delay. Considering again the example depicted in Figure 1, R1 will record as an event every change in the marking, by storing a timestamp TS R1 every time it sends the first packet of a block. R2 will do the same operation, recording TS R2 every time it receives the first packet of a block. By comparing TS R1 and TS R2 it's possible to calculate the delay between R1 and R2. In order to coherently compare the timestamps collected on different routers, synchronization is required in the network. Moreover, the measurement can be considered valid only if no packet loss occurred. If some packets are lost it is possible that the first packet of a block on R1 is not the first packet of the same block on R2. Going into details, whenever an interface sends/receives the first packet of a block (that is a packet with Control Bit set to 0 or 1, while previous packets were marked with the opposite value), a timestamp should be recorded. By comparing timestamps recorded on different nodes in the network, it is possible to calculate the delay on each network segment. As stated before, synchronization is required to get a reliable delay measurement. Table 2 considers the same example of Figure 1, but both packet loss and one-way delay are now measured. Time is expressed in minutes, while timestamps are expressed in milliseconds (hours and minutes are omitted for simplicity). We assume to check counters and timestamp values on each router every two minutes and we assume the Marking Interval is 5 minutes. Routers R1 and R2, besides incrementing counters C(0) and C(1), now also set a timestamp whenever the corresponding counter begins incrementing (i.e. the first packet is sent/received). Cociglio, et al. Expires August 30, 2010 [Page 12] Internet-Draft IP multicast performance monitoring February 2010 +-------+-----+--------+-----+--------+-----+--------+-----+--------+ | Time | R1 | TS0 R1 | R1 | TS1 R1 | R2 | TS0 R2 | R2 | TS1 R2 | | (min) | C0 | (sec) | C1 | (sec) | C0 | (sec) | C1 | (sec) | +-------+-----+--------+-----+--------+-----+--------+-----+--------+ | 0 | 0 | - | 0 | - | 0 | - | 0 | - | | | | | | | | | | | | 2 | 112 | 7.483 | 0 | - | 110 | 7.487 | 0 | - | | | | | | | | | | | | 4 | 234 | - | 0 | - | 237 | - | 0 | - | | | | | | | | | | | | 6 | 277 | - | 103 | 3.621 | 277 | - | 101 | 3.626 | | | | | | | | | | | | 8 | 277 | - | 212 | - | 277 | - | 210 | - | | | | | | | | | | | | 10 | 277 | - | 259 | - | 277 | - | 256 | - | | | | | | | | | | | | 12 | 403 | 5.752 | 262 | - | 401 | 5.757 | 262 | - | | | | | | | | | | | | 14 | 827 | - | 262 | - | 819 | - | 262 | - | +-------+-----+--------+-----+--------+-----+--------+-----+--------+ Table 2: Evaluation of counters for delay measurements At minute 2, C(0) counters have started moving on both routers and the first timestamp (relative to the first packet with CB=0) is recorded: R1 timestamp is 7.483, R2 timestamp is 7.487. Notice that those timestamps refer to the same packet because the first packet of the block is the same on both routers (if no packet loss has occurred): therefore they can be compared and, if we assume that R1 and R2 are synchronized, they can be used to measure the delay between R1 and R2 (4 msec). At minute 6 the marking has changed, C(0) counters have stopped and C(1) counters have started moving: it means that a new block with CB=1 has started, therefore R1 and R2 record a new timestamp. The new timestamp refers to the first packet of the block with CB=1 (which is the same packet on both routers). R1 timestamp is 3.621, R2 timestamp is 3.626; again, the two values are comparable and the delay is 5 msec. 5.3. Jitter Similarly to one-way delay measurement, the method to evaluate the jitter directly refers to the packet loss method. Again, the event when the marking changes from 0 to 1 or vice versa is used as a time reference to record timestamps: considering the example depicted in Figure 1, R1 will store a timestamp TS R1 every time it sends the first packet of a block and R2 will record a timestamp TS R2 every time it receives the first packet of a block. Cociglio, et al. Expires August 30, 2010 [Page 13] Internet-Draft IP multicast performance monitoring February 2010 The jitter can be easily derived from one-way delay measurement. For example, it is possible to evaluate the jitter calculating the delay variation on two consecutive samples: considering the values shown in Table 2, since the measured delay is 4 msec for the first sample and 5 msec for the second sample, the derived jitter is 1 msec. In this case, synchronization in the network is not strictly required because it is compensated by jitter calculation. Cociglio, et al. Expires August 30, 2010 [Page 14] Internet-Draft IP multicast performance monitoring February 2010 6. Deployment considerations This section describes some aspects that should be taken into account when the method is deployed in a real network. For sake of simplicity, we consider a network scenario where only packet loss is being measured, but all the considerations are valid and can be easily extended to one-way delay and jitter measurement as well. 6.1. Multicast Flow Identification The first thing to do in order to monitor multicast traffic in a real network is to identify the flow to be monitored. The method described in this document is able to monitor a single multicast stream or multiple flows grouped together, but in this case measurement is consistent only if all the flows in the group follow the same path. Moreover, a network operator must be aware that, if measurement is performed on many streams, it is not possible to determine exactly which flow was affected by packets loss (all the flows are considered as a single stream by the monitoring system). 6.2. Path Discovery Once the multicast stream(s) to be monitored is identified, it is important to enable the monitoring system in the proper nodes. In order to have just an end-to-end monitoring it is sufficient to enable the monitoring system on the first and last-hop routers of the path: the mechanism is completely transparent to intermediate nodes and independent from the path followed by multicast streams. At the contrary, to monitor the flow along its whole path and on every segment (every node and link) it is necessary to enable monitoring on every node from the source to the destination. To this purpose it isn't strictly required to know the exact path followed by the flow. If, for example, the flow has multiple paths to reach a destination, it is sufficient to enable the monitoring system on every path, then a Management System will process just the right information (or it will process all the counters but some of them will be zero, meaning that the considered flow is not flowing through the corresponding interface). 6.3. Flow Marking Once the multicast stream is identified and its path is known, it is necessary to "mark" the flow so to create packet blocks. This means choosing where to activate the marking and how to "mark" packets. Regarding the first point, it is desirable, in general, to have a single marking node because it is simpler to manage and doesn't rise any risk of conflict (consider the case where two nodes mark the same Cociglio, et al. Expires August 30, 2010 [Page 15] Internet-Draft IP multicast performance monitoring February 2010 flow). To this purpose it is necessary to mark the flow as close as possible to the multicast source, f.i. on the first router downstream to multicast sources where all the multicast streams can be marked. In addition, marking a flow close to the source allows an end-to-end measurement if a measurement point is enabled on the last-hop router as well. Theoretically, the flow could be marked before the first- hop router, directly by the sources: in this case the first-hop router just need to count packets of each block and acts as an intermediate node. The only requirement is that marking must change periodically and every node along the path must be able to identify unambiguously marked packets. On the contrary, if many marking nodes are required, it is important that each marking node marks different flows so to avoid "marking conflicts" that would invalidate measurements. Regarding the second point, as described in Section 5.1, a field in the IP header could be sufficient for this purpose. As an example, it is possible to use the two less significant bits of the DSCP field (bit 0 and bit 1). One of them (bit 0) is always set to value 1 and is used to identify the flow to be measured, the other one (bit 1) is changed periodically and assumes alternately values 0 and 1. This way traffic flow is transformed in a sequence of blocks where each block has all the packets with bit 1 of DSCP field set to the same value (0 or 1). Of course, marking can be based on DSCP field if differentiated packet scheduling is not based on that field and, for instance, it is based only on IP Precedence bits. In practice, the marking using the DSCP field can be performed configuring on the first-hop router an access list that intercepts the flow(s) to be measured and a policy that sets the DSCP field accordingly. Flows to be measured can be changed easily modifying the access list. Moreover, since traffic marking must change to create traffic blocks, it is necessary to change the policy periodically: this can be done for example using an automatic script that periodically modifies the configuration. 6.4. Monitoring Nodes The operation of marking flows to be monitored can be accomplished by a single node, namely the first-hop router. All the intermediate nodes are not required to perform any particular operation except counting marked packets they receive and forward: this operation can be enabled on every router along the multicast forwarding tree or just on a small subset, depending on which network segment we want to monitor (a single link, a particular metro area, the backbone, the whole path). Cociglio, et al. Expires August 30, 2010 [Page 16] Internet-Draft IP multicast performance monitoring February 2010 The operation of counting packets on intermediate nodes is very simple and can be accomplished f.i. configuring an access list that intercepts packets belonging to the multicast group being monitored with certain DSCP values (those configured on the first-hop router and used to mark the flow). This way only "marked" packets will be counted. Since marking changes periodically between two values, two counters (one for each value) are needed for a single flow being monitored: one counting packets with CB = 0 and one counting packets with CB = 1. Marking and counting are two decoupled operations: it is possible to mark all the multicast flows on the source but monitor just one or few flows, by enabling counters only for the intended streams. 6.5. Management System Nodes enabled to perform performance monitoring collect counters relative to multicast flows, but they are not able to use this information to measure packet loss, because they only have local information and lack a global view of the network. For this reason an external Network Management System (NMS) is required to collect and elaborate data and to perform packet loss calculation. The NMS compares values of counters from different nodes and is then able to determine if some packets were lost (even a single packet) and also where packets were lost. Information collected by the routers (counter values) needs to be transferred to the NMS periodically. This can be accomplished f.i. via FTP or TFTP and can be done in Push Mode or Polling Mode. In the first case, each router sends periodically the information it collects to the NMS, in the latter case it is the NMS that periodically polls routers to collect information. In any case, the Polling Interval (PI) should be compliant with the Shannon theorem: (PI < MI / 2).This means that the Management System should collect, during every Marking Interval, at least two samples of each counter (in order to determine if the counter is incrementing or is still within the considered interval). 6.6. Scalability This section describes what is needed on a node in order to enable the performance measurement system to the purpose of understand its scalability. Regarding the marking, it is preferable to have a single marking node for reasons explained in Section 6.3. The marking can be easily performed on a single multicast flow as well as on the entire multicast traffic. What is needed for example is a single policy Cociglio, et al. Expires August 30, 2010 [Page 17] Internet-Draft IP multicast performance monitoring February 2010 that marks all the intended traffic with a specific DSCP value, but this operation is usually already performed by routers for QoS purpose. Regarding the counting, what is needed are two counters for every flow (or group of flows) being monitored and for every interface where the monitoring system is activated. For example, in order to monitor 3 multicast flows on a router with 4 interfaces involved, 24 counters are needed (2 counters for each of the 3 flows on each of the 4 interfaces). If access lists are used to count packets, a single ACL can be used to count packets of many flows (access list entries will increase with the number of flows), but a different access list is required on every interface. The number of counters and access lists can easily increase with the number of flows and interfaces, however monitoring is not required on every interface (it should be activated only on interfaces belonging to the multicast forwarding tree). Besides, it can be sufficient to monitor few flows to have a monitoring system that spans the whole network because multicast flows follow the shortest path which is usually the same for all the streams (except in case of multiple equal cost paths), therefore flows using the same path are subject to give similar performance results. 6.7. Interoperability The method described in this document doesn't raise any interoperability issue, since it doesn't require any new protocol or any kind of interaction among nodes. Traffic marking can be performed by a single node, while counting of packets is performed locally by each router and the correlation between counters is done by an external NMS. The only requirement is that every node should be able to identify marked flows, but, as explained in Sections 6.3 and 6.4, this can be accomplished using simple functionalities that doesn't have any interoperability issue and are already available on major routing platforms. Cociglio, et al. Expires August 30, 2010 [Page 18] Internet-Draft IP multicast performance monitoring February 2010 7. Security Considerations TBD Cociglio, et al. Expires August 30, 2010 [Page 19] Internet-Draft IP multicast performance monitoring February 2010 8. IANA Considerations There are no IANA actions required. Cociglio, et al. Expires August 30, 2010 [Page 20] Internet-Draft IP multicast performance monitoring February 2010 9. Acknowledgements The authors would like to thank Domenico Laforgia for his contribution to the definition of the method. The authors would also like to thank Paolo Fasano and Matteo Cravero for their useful suggestions. Cociglio, et al. Expires August 30, 2010 [Page 21] Internet-Draft IP multicast performance monitoring February 2010 10. Informative References [I-D.bipi-mboned-ip-multicast-pm-requirement] Bianchetti, M., Picciano, G., Chen, M., and J. Qiu, "Requirements for IP multicast performance monitoring", draft-bipi-mboned-ip-multicast-pm-requirement-00 (work in progress), July 2009. Cociglio, et al. Expires August 30, 2010 [Page 22] Internet-Draft IP multicast performance monitoring February 2010 Authors' Addresses Mauro Cociglio Telecom Italia Via Reiss Romoli, 274 Torino 10148 Italy Email: mauro.cociglio@telecomitalia.it Alessandro Capello Telecom Italia Via Reiss Romoli, 274 Torino 10148 Italy Email: alessandro.capello@telecomitalia.it Alberto Tempia Bonda Telecom Italia Via Reiss Romoli, 274 Torino 10148 Italy Email: alberto.tempiabonda@telecomitalia.it Luca Castaldelli Telecom Italia Via Reiss Romoli, 274 Torino 10148 Italy Email: luca.castaldelli@telecomitalia.it Cociglio, et al. Expires August 30, 2010 [Page 23]