Draft of Multicast Monitoring on RIPE NCC Test Traffic Boxes

1. Multicast beacons that send packets at regular intervals to well-known multicast addresses both inside and outside the TTM network. The beacons should be compatible with similar existing beacons. The set-up should be user configurable, similar to the current TTM setup. Packets should be time-stamped.
2. Multicast listeners. This software monitors incoming multicast packets from a known set of beacons, both inside and outside the TTM network. It measures arrival rates and delays. The software should warn the user if data from certain senders stops arriving, similar to the mechanism currently used for one-way delay alarms.
3. Raw (unanalysed) data should be made available to all interested parties for analysis.
4. Once the software to send and receive data has been written, the data should be analysed to see if it is possible to pinpoint any problems in multicast distribution, using the fact that there are lots of senders and receivers. If possible, it should be automated.

The set-up should be user-configurable. It should have the option to run on demand or continuously. Internet Engineering Task Force (IETF) standards for multi-party metrics should be followed as much as possible. The RIPE NCC should provide feedback on the relevant IETF drafts if applicable.

The RIPE NCC is asked to build a first version of such a set-up, to show that this (in particular (1) and (2) above) can be done. The exact specification of the set-up should be determined in consultation with the Test Traffic Working Group. A first version of such a system is expected to be ready by October 2006, a RIPE Document describing the system should be written.

The Test Traffic Working Group will evaluate this set-up. If it is successful, the RIPE NCC should add this feature to the test-boxes operated by all interested parties.

RIPE Document ripe-297 should be amended to reflect the fact that multicast testing is part of TTM measurement program.