Opsawg A. Tempia Bonda Internet-Draft A. Capello Intended status: Experimental M. Cociglio Expires: January 17, 2013 L. Castaldelli Telecom Italia July 16, 2012 A packet based method for passive performance monitoring draft-tempia-opsawg-p3m-02.txt Abstract This document describes a method to achieve performance measurements of live traffic, applicable to any packet based traffic stream, including L2, L3, MPLS traffic, unicast and multicast. The method can be easily implemented using tools and features already available on existing routing platforms without any protocol extension and, 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 in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 17, 2013. Copyright Notice Copyright (c) 2012 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 Tempia Bonda, et al. Expires January 17, 2013 [Page 1] Internet-Draft Method for passive performance monitoring July 2012 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of the method . . . . . . . . . . . . . . . . . . . . 4 3. Detailed description of the method . . . . . . . . . . . . . . 6 3.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. One-way Delay . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Delay variation . . . . . . . . . . . . . . . . . . . . . 11 4. Implementation strategies . . . . . . . . . . . . . . . . . . 12 4.1. Flow-based performance monitoring . . . . . . . . . . . . 12 4.2. Link-based performance monitoring . . . . . . . . . . . . 12 5. Implementation hints . . . . . . . . . . . . . . . . . . . . . 13 5.1. Traffic colouring . . . . . . . . . . . . . . . . . . . . 13 5.2. Packet counting . . . . . . . . . . . . . . . . . . . . . 13 5.3. Data collection . . . . . . . . . . . . . . . . . . . . . 13 6. Deployment considerations . . . . . . . . . . . . . . . . . . 15 6.1. Flow Identification . . . . . . . . . . . . . . . . . . . 15 6.2. Flow Colouring . . . . . . . . . . . . . . . . . . . . . . 15 6.3. Monitoring Nodes . . . . . . . . . . . . . . . . . . . . . 16 6.4. Management System . . . . . . . . . . . . . . . . . . . . 17 6.5. Scalability . . . . . . . . . . . . . . . . . . . . . . . 17 6.6. Interoperability . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Tempia Bonda, et al. Expires January 17, 2013 [Page 2] Internet-Draft Method for passive performance monitoring July 2012 1. Introduction The increasing deployment in Service Providers' networks of applications highly sensitive to packet loss [RFC2680], delay [RFC2679], and jitter [RFC3393]demands for mechanisms able to monitor and measure network performances. Service Level Agreements (SLA) verification asks Service Providers to be able to measure the quality of experience perceived by customers and the performance of the network in light of the agreed requirements. On the other hand, performance monitoring provides useful information on the network itself, simplifying the troubleshooting and the isolation of network problems. This document describes a method to achieve accurate performance monitoring of live traffic. The method can be applied to any kind of packet based traffic, including Ethernet, IP, and MPLS, both unicast and multicast. It doesn't require any protocol extension or interaction with existing protocols, thus avoiding any interoperability issue. The method has been explicitly designed for passive measurements but can also be used with active probes. Passive measurements are usually more easily understood by customers and give Service Providers more insights into network behaviour. There is a lot of work related to OAM and [I-D.ietf-opsawg-oam-overview] provides a good overview of existing OAM mechanisms defined in IETF, ITU-T and IEEE. In IETF, in particular, a lot of work has been done on fault detection and connectivity verification, while a minor effort has been dedicated so far to performance monitoring. IPPM WG has defined standard metrics to measure network performance; however, the methods developed in the WG refer to active measurement techniques. More recently, the MPLS WG has defined mechanisms for measuring packet loss, one-way and two- way delay, and delay variation in MPLS networks[RFC6374]. Tempia Bonda, et al. Expires January 17, 2013 [Page 3] Internet-Draft Method for passive performance monitoring July 2012 2. Overview of the method The method addresses primarily packet loss measurement, but it can be easily extended to one-way delay and delay variation measurements as well. In order to perform packet loss measurements of a live traffic flow it is possible to follow several approaches. The most intuitive one consists in numbering the packets so that each router receiving the flow can immediately detect a missing packet. Such approach, though very simple in theory, is not simple to achieve: it requires to insert a sequence number in each packet and to have an equipment able to extract the number and check it in real time. A similar task can be difficult to implement on live 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 of each packet and process it in real time could overload the equipment. An alternative approach is to count the number of packets sent on one end, the number of packets received on the other end, and to compare the two values. This operation is much simpler to implement than numbering each packet, but requires a kind of synchronization between the devices performing the measurement: in order to compare two counters it is required that they refer exactly to the same set of packets. Since a flow is continuous and cannot be stopped when a counter has to be read, it could be difficult to determine exactly when to read the counter. A possible solution to overcome this problem is to virtually split the flow in consecutive blocks by inserting periodically a delimiter so that each counter refers exactly to the same block of packets. The delimiter could be f.i. a special packet inserted into the flow. Compared to numbering the packets, the second approach is easier to implement; however, delimiting the flow using specific packets can have some limitations. First it requires to generate additional packets within the flow and requires the equipment to be able to process those packets. In addition, the method is vulnerable to delimiting packets losses: if a delimiting packet is lost, the contiguous blocks are affected and the related measurement is wrong. The method proposed in this document follows the second approach described, but doesn't use additional packets to virtually split the flow in blocks. Instead, it "colours" the packets so that packets belonging to different consecutive blocks will have different colours. Each network device manages a packet counter for each block and by comparing the values of counters at different network devices it is possible to measure packet loss. Each colour change represents Tempia Bonda, et al. Expires January 17, 2013 [Page 4] Internet-Draft Method for passive performance monitoring July 2012 a sort of auto-synchronization mechanism that guarantees the consistency of measurements (the value of the counters) taken by different devices along the path. The advantages of the method are: o easy implementation: it can be implemented using features already available on major routing platforms; o low computational effort; o accurate packet loss measurement (single packet loss granularity); o applicability to any kind of traffic (Ethernet, IP, MPLS, unicast, multicast); o no interoperability issues. Figure 1 represents a very simple network and shows how the method can be used to measure packet loss on different network segments: by enabling the measurement on several interfaces along the path, it is possible to perform link monitoring, node monitoring or end-to-end monitoring. The method is flexible enough to measure packet loss on any segment of the network. Traffic flow ========================================================> +------+ +------+ +------+ +------+ ---<> R1 <>-----<> R2 <>-----<> R3 <>-----<> R4 <>--- +------+ +------+ +------+ +------+ . . . . . . . . . . . . . <------> <-------> . . Node Packet Loss Link Packet Loss . . . <---------------------------------------------------> End-to-End Packet loss Figure 1: Available measurements Tempia Bonda, et al. Expires January 17, 2013 [Page 5] Internet-Draft Method for passive performance monitoring July 2012 3. Detailed description of the method This section describes in detail how the method can be used to achieve performance monitoring of live traffic in a packet-switched network. 3.1. Packet Loss The basic idea is to virtually split traffic flows into consecutive blocks; each block represents a measurable entity unambiguously recognizable by all network devices along the path. By counting the number of packets in each block and comparing the values measured by different network devices along the path, it is possible to measure packet loss occurred in any single block between any two points. The following figure shows how blocks are created by inserting delimiters into the flow. | | | | | | | Traffic flow | | ========|===========|===========|===========|===========|==========> ... | Block 5 | Block 4 | Block 3 | Block 2 | Block 1 | | | | | Figure 2: Traffic delimitation points A simple way to create the blocks is to "colour" the traffic (two colours are sufficient) so that packets belonging to different consecutive blocks will have different colours. Whenever the colour changes the previous block terminates and the new one begins. Hence all the packets belonging to the same block will have the same colour and packets of different consecutive blocks will have different colours. The number of packets in each block depends on the criterion used to create the blocks: if the colour is switched after a fixed number of packets, then each block will contain the same number of packets (except for any losses); but if the colour is switched according to a fixed timer, then the number of packets may be different in each block depending on the packet rate. The following figure shows how a flow looks like when it is split in traffic blocks with coloured packets. Tempia Bonda, et al. Expires January 17, 2013 [Page 6] Internet-Draft Method for passive performance monitoring July 2012 A: packet with A colouring B: packet with B colouring | | | | | | | Traffic flow | | -------------------------------------------------------------------> BBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA -------------------------------------------------------------------> ... | Block 5 | Block 4 | Block 3 | Block 2 | Block 1 | | | | | Figure 3: Traffic colouring Figure 4 shows how the method can be used to measure link packet loss between two adjacent nodes. Referring to the figure, let's assume we want to monitor the packet loss on the link between two routers: router R1 and router R2. According to the method here described, traffic is coloured alternatively with two different colours, A and B. Whenever the colour changes, the transition generates a sort of square-wave signal, as depicted in the following figure. Colour A ----------+ +-----------+ +---------- | | | | Colour B +-----------+ +-----------+ Block n ... Block 3 Block 2 Block 1 <---------> <---------> <---------> <---------> <---------> Traffic flow ===========================================================> Colour ... AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA... ===========================================================> Figure 4: Application of the method to compute link packet loss Traffic colouring could be done by R1 itself or by an upward router. R1 needs two counters, C(A)R1 and C(B)R1, on its egress interface in order to count the packets sent out of the interface and coloured respectively with colour A and B. As long as traffic is coloured A, only counter C(A)R1 will be incremented while C(B)R1 is still; viceversa, when the traffic is coloured as B, only C(B)R1 is incremented while C(A)R1 is still. C(A)R1 and C(B)R1 can be used as reference values to determine the packet loss from R1 to any other measurement point down the path. Router R2, similarly, will need two counters on its ingress interface, C(A)R2 and C(B)R2, to count the Tempia Bonda, et al. Expires January 17, 2013 [Page 7] Internet-Draft Method for passive performance monitoring July 2012 packets received on that interface and coloured with colour A and B respectively. When an A block terminates it is possible to compare C(A)R1 and C(A)R2 and calculate the packet loss within the block; similarly, when the successive B block terminates, it is possible to compare C(B)R1 with C(B)R2, and so on for every successive block. Likewise, by using two counters on R2 egress interface it is possible to count the packets sent out of R2 interface and use them as reference values to calculate the packet loss from R2 to any measurement point down R2. Using a fixed timer for colour switching offers a better control over the method: the (time) length of the blocks can be chosen large enough to simplify the collection and the comparison of measures taken by different network devices. It's preferable to start the comparison between the counters not immediately after the colour switch: some packets could arrive out of order and increment the counter associated to the previous block (colour), so it is worth waiting for few seconds. The drawback is that the longer the duration of the block, the less frequent the measurement can be taken, but usually performance monitoring doesn't need to be performed at very high rates. The method doesn't require any synchronization in the network, as the traffic flow implicitly carries the synchronization in the alternation of colours. In addition, splitting the flow into blocks, the method is able not only to detect any packet loss, but also to provide information about when the packet loss has occurred and in which point of the network. The following table shows how the counters can be used to calculate the packet loss between R1 and R2. The first column lists the sequence of traffic blocks while the other columns contain the counters of A-coloured packets and B-coloured packets for R1 and R2. In this example, we assume that the values of the counters are reset to zero whenever a block ends and its associated counter has been read: with this assumption, the table shows only relative values, that is the exact number of packets of each colour within each block. If the values of the counters were not reset, the table would contain cumulative values, but the relative values could be determined simply by difference from the value of the previous block of the same colour. The colour is switched on the basis of a fixed timer (not shown in the table), so the number of packets in each block is different. Tempia Bonda, et al. Expires January 17, 2013 [Page 8] Internet-Draft Method for passive performance monitoring July 2012 +-------+--------+--------+--------+--------+------+ | Block | C(A)R1 | C(B)R1 | C(A)R2 | C(B)R2 | Loss | +-------+--------+--------+--------+--------+------+ | 1 | 375 | 0 | 375 | 0 | 0 | | | | | | | | | 2 | 0 | 388 | 0 | 388 | 0 | | | | | | | | | 3 | 382 | 0 | 381 | 0 | 1 | | | | | | | | | 4 | 0 | 377 | 0 | 374 | 3 | | | | | | | | | ... | ... | ... | ... | ... | ... | | | | | | | | | n | 0 | 387 | 0 | 387 | 0 | | | | | | | | | n+1 | 379 | 0 | 377 | 0 | 2 | +-------+--------+--------+--------+--------+------+ Table 1: Evaluation of counters for packet loss measurements During an A block (blocks 1, 3 and n+1), all the packets are A-coloured, therefore C(A) counters indicate the number of packets of that block, while C(B) counters are zero. Viceversa, during a B block (blocks 2, 4 and n), all the packets are B-coloured: C(A) counters are zero, while C(B) counters indicate the number of packets of that block. When a block terminates (because the colouring has switched to the other colour) the relative counters stop incrementing and it is possible to read them, compare the values measured on router R1 and R2 and calculate the packet loss within that block. For example, looking at the table above, during the first block (A-coloured) C(A)R1 and C(A)R2 have the same value (375), which corresponds to the exact number of packets of the first block. Also during the second block (B-coloured) R1 and R2 counters have the same value (388), which corresponds to the number of packets of the second block. During blocks three and four, R1 and R2 counters are different, meaning that some packets have been lost: in the example, one single packet (382-381) was lost during block three and three packets (377-374) were lost during block four. The method here described for R1 and R2 can be extended to any router and applied to more complex networks, as far as the measurement is enabled on the path followed by the traffic flow(s) being analyzed. Tempia Bonda, et al. Expires January 17, 2013 [Page 9] Internet-Draft Method for passive performance monitoring July 2012 3.2. One-way Delay The principle used to measure packet loss can be applied to one-way delay measurement as well because the alternations of colours can be used as time references to calculate the delay (again a sort of auto synchronization). Whenever the colour changes (that means that a new block has started) a network device can store the timestamp of the first packet of the new block; that timestamp can be compared with the timestamp of the same packet on a second router to compute packet delay. Considering Figure 4, R1 stores a timestamp TS(A1)R1 when it sends the first packet of block 1 (A-coloured), a timestamp TS(B2)R1 when it sends the first packet of block 2 (B-coloured) and so on for every other block. R2 performs the same operation, recording TS(A1)R2, TS(B2)R2 and so on. Since timestamps refer to specific packets (the first packet of each block) we are sure that timestamps compared to compute delay refer to the same packets. By comparing TS(A1)R1 with TS(A1)R2 (and similarly TS(B2)R1 with TS(B2)R2 and so on) it is possible to measure the delay between R1 and R2. In order to have more measurements it may also be possible to take more timestamps, not only referring to the first packet of each block, but also its subsequent packets. How timestamps are recorded when a particular packet is sent or received depends on the implementation and is out of the scope of this document. In order to coherently compare timestamps collected on different routers, synchronization is required in the network. Furthermore, a measurement is valid only if no packet loss occurs and if packet misordering can be avoided, otherwise the first packet of a block on R1 could be different from the first packet of the same block on R2 (f.i. if that packet is lost between R1 and R2 or it arrives after the next one). The following table shows how timestamps can be used to calculate the delay between R1 and R2. The first column lists the sequence of traffic blocks while other columns contain the timestamp referring to the first packet of each block on R1 and R2. Delay is computed as a difference between timestamps. For sake of simplicity hours, minutes and seconds are omitted from timestamps and all the values are expressed in milliseconds. Tempia Bonda, et al. Expires January 17, 2013 [Page 10] Internet-Draft Method for passive performance monitoring July 2012 +-------+---------+---------+---------+---------+-------------+ | Block | TS(A)R1 | TS(B)R1 | TS(A)R2 | TS(B)R2 | Delay R1-R2 | +-------+---------+---------+---------+---------+-------------+ | 1 | 12.483 | - | 15.591 | - | 3.108 | | | | | | | | | 2 | - | 6.263 | - | 9.288 | 3.025 | | | | | | | | | 3 | 27.556 | - | 30.512 | - | 2.956 | | | | | | | | | | - | 18.113 | - | 21.269 | 3.156 | | | | | | | | | ... | ... | ... | ... | ... | ... | | | | | | | | | n | 77.463 | - | 80.501 | - | 3.038 | | | | | | | | | n+1 | - | 24.333 | - | 27.433 | 3.100 | +-------+---------+---------+---------+---------+-------------+ Table 2: Evaluation of timestamps for delay measurements The first row shows timestamps (in milliseconds) taken on R1 and R2 respectively and referring to the first packet of block 1 (which is A-coloured). Delay can be computed as a difference between the timestamp on R1 and the timestamp on R2. Similarly, the second row shows timestamps (in milliseconds) taken on R1 and R2 and referring to the first packet of block 2 (which is B-coloured). Comparing timestamps taken on different nodes in the network and referring to the same packets (identified using the alternation of colours) it is possible to measure delay on different network segments. 3.3. Delay variation Similarly to one-way delay measurement, the method can be used to measure the inter-arrival jitter. The alternation of colours can be used as a time reference to record timestamps and measure delay variations. Considering the example depicted in Figure 4, R1 stores a timestamp TS(A)R1 whenever it sends the first packet of a block and R2 stores a timestamp TS(B)R2 whenever it receives the first packet of a block. The inter-arrival 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. Tempia Bonda, et al. Expires January 17, 2013 [Page 11] Internet-Draft Method for passive performance monitoring July 2012 4. Implementation strategies The methodology described in the previous sections can be applied to different scenarios adopting different strategies. Specifically, it can be used in two basic ways: o flow-based: performance measurement is applied to specific flows for service monitoring purpose and can be end-to-end; o link-based: performance measurement is applied to a particular link (physical or logical) and monitors all the flows of the link. 4.1. Flow-based performance monitoring The flow-based strategy is used when only a limited number of traffic flows need to be monitored. This could be the case, for example, of IPTV channels or other specific applications traffic with high QoS requirements. According to this strategy, only a subset of the flows is coloured. Counters for packet loss measurements can be instantiated for each single flow, or for the set as a whole, depending on the desired granularity. A relevant problem with this approach is the necessity to know in advance the path followed by flows that are subject to measurement. Path rerouting and traffic load-balancing increase the issue complexity, especially for unicast traffic. The problem is easier to solve for multicast traffic where load balancing is seldom used, especially for IPTV traffic where static joins are frequently used to force traffic forwarding and replication. 4.2. Link-based performance monitoring The link-based strategy is similar to performance monitoring tools usually used in transport networks, where the goal is to monitor the network behaviour as a whole, without distinguishing among different services. Measurements are performed on all the traffic on a link. The link could be a physical link or a logical link (for instance an Ethernet VLAN or a MPLS PW). Counters could be instantiated for the traffic as a whole or for each traffic class (in case it is desired to monitor each class separately), but in the second case a couple of counters is needed for each class. Tempia Bonda, et al. Expires January 17, 2013 [Page 12] Internet-Draft Method for passive performance monitoring July 2012 5. Implementation hints This section describes, as an example, a practical implementation of the method using basic features already available on major routing platforms. 5.1. Traffic colouring Traffic colouring can be implemented by setting a specific bit in the packet header and changing the value of that bit periodically. With current implementations, only QoS related fields and features offer flexibility in setting bits and configuring policies. For example, in case a Service Provider only uses the three most significant bits of the DSCP field (corresponding to IP Precedence) for QoS classification and queuing, it is possible to use the two less significant bits of the DSCP field (bit 0 and bit 1) to implement the method without affecting QoS policies. One of the two bits (bit 0) could be used to identify flows subject to traffic monitoring (and therefore it is always set to 1 on these flows), while the other (bit 1) would be used for colouring the traffic (switching between values 0 and 1) and creating the blocks. In practice, colouring traffic using the DSCP field can be implemented easily by configuring on the router interface an access list that intercepts the flow(s) to be monitored (or all the traffic, according to the link-based approach) and a policy that sets the DSCP field accordingly. Since traffic colouring must change over time, it is necessary to modify the policy periodically: an automatic script could easily perform this task. 5.2. Packet counting If traffic is coloured using the DSCP field, an access list that matches specific DSCP values can be used to count the packets of the flow being monitored. The access list can also be configured to match different flow properties (such as source or destination address) besides the DSCP value, hence monitoring just a subset of the coloured traffic. An important feature of this approach, in fact, is that colouring and counting are two decoupled operations: it is possible to colour all the traffic, but monitor just one or few flows. 5.3. Data collection In order to properly elaborate packet counters it is necessary to correlate values coming from different nodes. If we cannot use any specific protocol to exchange this information among routers, it is possible to use an external system. Its task is to collect data Tempia Bonda, et al. Expires January 17, 2013 [Page 13] Internet-Draft Method for passive performance monitoring July 2012 (counter values) from the network and do correlations to calculate packet loss. This operation can be done for instance by transferring data to the external system via FTP/TFTP or by reading the related MIBs (if available) via SNMP. Tempia Bonda, et al. Expires January 17, 2013 [Page 14] Internet-Draft Method for passive performance monitoring July 2012 6. Deployment considerations This section describes some aspects that should be taken into account when the method is deployed in a real network. 6.1. Flow Identification In the previous section it was outlined that flow-based measurements require the identification of the flow to be monitored and the discovery of the path followed by the selected flow. It is possible to monitor a single flow 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 Service Provider should be aware that, if a measurement is performed by grouping many flows, it is not possible to determine exactly which flow was affected by packets loss. In order to have measures per single flow it is necessary to configure counters for each specific flow. Once the flow(s) to be monitored have been identified, it is necessary to configure the monitoring on the proper nodes. Configuring the monitoring means configuring the policy to intercept the traffic and configuring the counters to count the packets. To have just an end-to-end monitoring, it is sufficient to enable the monitoring on the first and the last hop routers of the path: the mechanism is completely transparent to intermediate nodes and independent from the path followed by traffic flows. On the contrary, to monitor the flow on a hop-by-hop basis along its whole path it is necessary to enable the monitoring on every node from the source to the destination. In case the exact path followed by the flow is not known a priori (i.e. the flow has multiple paths to reach the destination) it is necessary to enable the monitoring system on every path: counters on interfaces traversed by the flow will report packet count, counters on other interfaces will be null. In case the link-based strategy is used, flow identification is not necessary because all the traffic has to be coloured and measured. 6.2. Flow Colouring In both strategies, flow-based and link-based, the fundamental operation is to colour the flow in order to create packet blocks. This implies choosing where to activate the colouring and how to colour the packets. In case of flow-based measurements, it is desirable, in general, to have a single colouring node because it is easier to manage and doesn't rise any risk of conflict (consider the case where two nodes colour the same flow). Thus it is necessary to colour the flow as Tempia Bonda, et al. Expires January 17, 2013 [Page 15] Internet-Draft Method for passive performance monitoring July 2012 close as possible to the source. In addition, colouring a flow close to the source allows an end-to-end measure if a measurement point is enabled on the last-hop router as well. The only requirement is that the colouring must change periodically and every node along the path must be able to identify unambiguously the coloured packets. For link-based measurements, all traffic needs to be coloured when transmitted on the link. If the traffic had already been coloured, then it has to be re-coloured because the colour must be consistent on the link. This means that each hop along the path must (re-)colour the traffic; the colour is not required to be consistent along different links. 6.3. Monitoring Nodes In the previous section it was outlined that, in case of flow-based measurement, the operation of colouring the packets to be monitored can be accomplished by a single node. All the intermediate nodes are not required to perform any particular operation except counting the coloured packets that they receive and forward: this operation can be enabled on every router along the path or only on a subset, depending on which network segment is being monitored (a single link, a particular metro area, the backbone, the whole path). Since colours change periodically between two values, two counters (one for each value) are needed for a single flow being monitored: one counter for packets with colour A and one counter for packets with colour B. In case of link-based measurements the behaviour is similar except that colouring and counting operations are performed on a link by link basis at each endpoint of the link. Another important aspect to take into consideration is when to read counters: in order to count the exact number of packets of a block the routers must perform this operation when a block has terminated. The task can be performed in two ways. The most general approach suggests to read counters periodically, many times during a block, and to compare successive readings: when the counter stops incrementing means that the relative block has finished and its value can be elaborated. Alternatively, if colouring is performed on the basis of a fixed timer, it is possible to configure the reading of the counters according to that timer (f.i. if each block is 5 minutes long it is possible to read counters every 5 minute in the middle of the subsequent block to overcome eventual time shifts from the router that colours the traffic). A sufficient margin should be considered between the end of a block and the reading of the counter, in order to take into account any out-of-order packets. Tempia Bonda, et al. Expires January 17, 2013 [Page 16] Internet-Draft Method for passive performance monitoring July 2012 6.4. Management System Nodes enabled to perform performance monitoring collect the value of the counters, but they are not able to directly 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 the values of counters from different nodes and can calculate 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 periodically sends the information to the NMS, in the latter case it is the NMS that periodically polls routers to collect information. If link-based measurement is used, it would be possible to use a protocol to exchange values of counters between the two endpoints in order to let them perform the packet loss calculation for each traffic direction. A similar approach could be complicated if applied to a flow-based measurement. 6.5. Scalability The colouring can be easily performed on a single flow as well as on the entire traffic. Regarding the counting, what is needed are two counters for each flow (or group of flows) being monitored and for every interface where the monitoring system is activated. For example, in order to monitor separately 3 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). 6.6. 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 colouring can be performed by a single node, while the counting of packets is done locally by each router, and the correlation between counters can be done by an external NMS which collects and correlates the data coming from the network. The only requirement is that every node should be able to identify coloured flows, but, as explained in Section 5, this can be accomplished by using simple functionalities that doesn't have any Tempia Bonda, et al. Expires January 17, 2013 [Page 17] Internet-Draft Method for passive performance monitoring July 2012 interoperability issue and are already available on major routing platforms. Tempia Bonda, et al. Expires January 17, 2013 [Page 18] Internet-Draft Method for passive performance monitoring July 2012 7. Security Considerations This document specifies a method to perform measurements in the context of a Service Provider's network and has not been developed to conduct Internet measurements, so it does not directly affect Internet security nor applications which run on the Internet. However, implementation of this method must be mindful of security and privacy concerns. There are two types of security concerns: potential harm caused by the measurements and potential harm to the measurements. For what concerns the first point, the measurements described in this document are passive, so there are no packets injected into the network causing potential harm to the network itself and to data traffic. Nevertheless, the method implies modifications on the fly to the IP header of data packets: this must be performed in a way that doesn't alter the quality of service experienced by packets subject to measurements and that preserve stability and performance of routers doing the measurements. The measurements themselves could be harmed by routers altering the colouring of the packets, or by an attacker injecting artificial traffic. Authentication techniques, such as digital signatures, may be used where appropriate to guard against injected traffic attacks. The privacy concerns of network measurement are limited because the method only relies on information contained in the IP header without any release of user data. Tempia Bonda, et al. Expires January 17, 2013 [Page 19] Internet-Draft Method for passive performance monitoring July 2012 8. IANA Considerations There are no IANA actions required. Tempia Bonda, et al. Expires January 17, 2013 [Page 20] Internet-Draft Method for passive performance monitoring July 2012 9. Acknowledgements The authors would like to thank Domenico Laforgia, Daniele Accetta and Mario Bianchetti for their contribution to the definition and the implementation of the method. Tempia Bonda, et al. Expires January 17, 2013 [Page 21] Internet-Draft Method for passive performance monitoring July 2012 10. References 10.1. Normative References [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 10.2. Informative References [I-D.ietf-opsawg-oam-overview] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", draft-ietf-opsawg-oam-overview-06 (work in progress), March 2012. [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011. Tempia Bonda, et al. Expires January 17, 2013 [Page 22] Internet-Draft Method for passive performance monitoring July 2012 Authors' Addresses Alberto Tempia Bonda Telecom Italia Via Reiss Romoli, 274 Torino 10148 Italy Email: alberto.tempiabonda@telecomitalia.it Alessandro Capello Telecom Italia Via Reiss Romoli, 274 Torino 10148 Italy Email: alessandro.capello@telecomitalia.it Mauro Cociglio Telecom Italia Via Reiss Romoli, 274 Torino 10148 Italy Email: mauro.cociglio@telecomitalia.it Luca Castaldelli Telecom Italia Via Reiss Romoli, 274 Torino 10148 Italy Email: luca.castaldelli@telecomitalia.it Tempia Bonda, et al. Expires January 17, 2013 [Page 23]