RIPE Policy Proposals

you are here: RIPE > Policy Development > Policy Proposals

	Current Policy Proposals
	Archived Policy Proposals
	Subscribe to the Policy-Announce List
	Policy Proposal Template
	Policy Development Process Info (PDF)

RIPE Policy Proposal 2005-11

Number:	2005-11
Policy Proposal Name:	Multicast Monitoring on RIPE NCC Test Traffic Boxes
Author:	Gert Doering SpaceNet AG
Proposal Version:	1.1
Submission Date:	20 April 2006 Previous version: v1.0
Current Status :	Withdrawn - During the discussion phase, the working group decided that the RIPE NCC should do the work and that there was no need to complete the full PDP cycle for this proposal.
Suggested WG for Discussion and Publication:	Test Traffic
Proposal Type:	Modify
Policy Term:	Permanent
Policy Document to be Affected:	ripe-297

Summary of Proposal:

This proposal is to add functionality to the Test Traffic Measurement (TTM) service that allows for testing of multicast-capable networks.

Draft Policy Text

Components should include:

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.
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.
Raw (unanalysed) data should be made available to all interested parties for analysis.
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.

Rationale:

a. Arguments supporting the proposal:

The RIPE NCC test-boxes form a very useful measurement platform, distributed over a large number of provider networks.

IP Multicast monitoring is inherently difficult, as you cannot easily probe connectivity from a single point of view - some problems need testing and monitoring from multiple different locations to identify "black holes" on some paths.

Troubleshooting connectivity issues that span multiple networks is easier if a neutral entity does the monitoring and pinpoints problem areas.

I think the RIPE NCC Test Traffic network is uniquely qualified to do this.

An informal poll on the Test Traffic Working Group mailing list has shown that there are a fair number of current test-box hosts interested in this feature.

b. Arguments opposing the proposal:
Some arguments have been brought forward that there are not enough multicast-capable networks to make this a worthwile action.


	About RIPE \| Site Map \| LIR Portal \| About the RIPE NCC \| Contact \| © RIPE Community. All rights reserved.