[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 draft-ietf-ippm-alt-mark

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/