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]