MBONED M. Cociglio
Internet-Draft A. Capello
Intended status: Experimental A. Tempia Bonda
Expires: April 25, 2011 L. Castaldelli
Telecom Italia
October 22, 2010
A method for IP multicast performance monitoring
draft-cociglio-mboned-multicast-pm-01.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 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 April 25, 2011.
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
Cociglio, et al. Expires April 25, 2011 [Page 1]
Internet-Draft IP multicast performance monitoring October 2010
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 Simplified 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. Inter-arrival 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 April 25, 2011 [Page 2]
Internet-Draft IP multicast performance monitoring October 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 doesn't
require any extension to existing protocols and can be implemented
using tools already available on major routing platforms.
Cociglio, et al. Expires April 25, 2011 [Page 3]
Internet-Draft IP multicast performance monitoring October 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 April 25, 2011 [Page 4]
Internet-Draft IP multicast performance monitoring October 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 can be defined based on the number of
packets (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 on each block can vary and depends on the flow rate). In any
case blocks must be recognizable unambiguously on every node along
the path: 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
Cociglio, et al. Expires April 25, 2011 [Page 5]
Internet-Draft IP multicast performance monitoring October 2010
Blocks of consecutive packets are identified using some information
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 and
creating a sequence of blocks. All the packets within a block have
the field set to the same value and all the packets within the
following block 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 depends on the flow rate. 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.
In the following we will assume to define blocks on a time basis.
The same approach can also be used to measure one-way delay and
inter-arrival 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.
Inter-arrival jitter can be easily estimated from delay measures and
does not require necessarily synchronization between the nodes.
Cociglio, et al. Expires April 25, 2011 [Page 6]
Internet-Draft IP multicast performance monitoring October 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 inter-arrival 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 April 25, 2011 [Page 7]
Internet-Draft IP multicast performance monitoring October 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 April 25, 2011 [Page 8]
Internet-Draft IP multicast performance monitoring October 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 April 25, 2011 [Page 9]
Internet-Draft IP multicast performance monitoring October 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 April 25, 2011 [Page 10]
Internet-Draft IP multicast performance monitoring October 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 April 25, 2011 [Page 11]
Internet-Draft IP multicast performance monitoring October 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 April 25, 2011 [Page 12]
Internet-Draft IP multicast performance monitoring October 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.
It is possible to perform more than one delay measurement per period
by taking not only the timestamp of the first packet of each block,
but also the timestamp of other packets within the same block. What
is required is packets triggering timestamps being the same on every
router along the path.
5.3. Inter-arrival jitter
Similarly to one-way delay measurement, the method to evaluate the
inter-arrival jitter directly refers to the packet loss method.
Cociglio, et al. Expires April 25, 2011 [Page 13]
Internet-Draft IP multicast performance monitoring October 2010
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.
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:
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 April 25, 2011 [Page 14]
Internet-Draft IP multicast performance monitoring October 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 inter-arrival 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
Cociglio, et al. Expires April 25, 2011 [Page 15]
Internet-Draft IP multicast performance monitoring October 2010
any risk of conflict (consider the case where two nodes mark the same
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 April 25, 2011 [Page 16]
Internet-Draft IP multicast performance monitoring October 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 counter for packets with CB = 0 and one counter for
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 April 25, 2011 [Page 17]
Internet-Draft IP multicast performance monitoring October 2010
that marks all the intended traffic with a specific DSCP value: this
operation doesn't raise any scalability issue, since it is generally
performed by routers for QoS purposes.
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 April 25, 2011 [Page 18]
Internet-Draft IP multicast performance monitoring October 2010
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 marking 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.
Cociglio, et al. Expires April 25, 2011 [Page 19]
Internet-Draft IP multicast performance monitoring October 2010
8. IANA Considerations
There are no IANA actions required.
Cociglio, et al. Expires April 25, 2011 [Page 20]
Internet-Draft IP multicast performance monitoring October 2010
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. The authors would also like to thank
Paolo Fasano and Matteo Cravero for their useful suggestions.
Cociglio, et al. Expires April 25, 2011 [Page 21]
Internet-Draft IP multicast performance monitoring October 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 April 25, 2011 [Page 22]
Internet-Draft IP multicast performance monitoring October 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 April 25, 2011 [Page 23]