RIPE NCC Multicast Monitoring - Help

TTM Configuration

TTM Configuration allows you to perform very accurate delay measurement between RIPE NCC testboxes. You can define multiple beacons and listeners by entering a multicast IP address and a Port number. The software will then start performing the requested measurements. For TTM measurements currently only a single beacon is allowed per multicast address. While multiple beacons can be run on a single multicast address, you will have to use a Custom Listener on the listening side, which would sacrifice some of the accuracy for delay measurements.

Every TTM Beacon sends out approximately 2 multicast packets per minute using a poession distribution to avoid fixed intervals. Every packet has a header that features a serial number and an offset to locate the timestamp inside the packet. Apart from the timestamp random data is generated as a payload for the packet. Each packet has a size of 100 bytes.

Each configured listener will evaluate incoming packets on a given multicast address and port. These packets have to come from another TTM Beacon, if you want to listen to arbitrary multicast streams, please use the Custom Listener. Timestamps will be extracted and the one-way delay will be calculated and logged. All this is done as soon as the packet arrives on the Data-Link layer to achieve the most accurate one-way delay measurements possible. After starting a listener the plots should usually appear within 10-15 minutes on the Plots page. If no plots are shown it is very likely that there is an error in the configuration or that no packets are arriving due to network problems.

Custom Listener

Configurations

By clicking on "Start Listener and Save Configuration" your configuration can be saved for later use. The TTM-Data configuration is hard coded and can therefore not be deleted. Other configurations may be distributed with the software and can vary from version to version. Usually there are 2 configuration for the dbeacon. "debacon" listens to all incomming packets on a given address and port and trys to extract the timestamp. "debaconSize" however only listens to "real" beacon frames that are 12 bytes in size. All other packets are ignored. Please review the configuration before using them to see if they fit your needs.

Timestamps

You can choose between several options on how the timestamp is stored inside the multicast packet.

Packet Payload

Using this field you can filter packets by their size in bytes. 0 means use any packet no matter what size to generate statistics. Seeting it to any number higher than 0 will result in only using packets with that size for statistics while any other packet will be ignored..

Predefined Values

There can be multiple predefined values in a comma separated list of hexadecimal values. Zeros in both fields will result in values not being checked, so you cannot check for a zero at the beginning of a packet. The number of defined values must match the number of offsets. The software cannot parse anything smaller than a single byte; The defined value 'a' will be interpreted as '0a' and therefore look for a new line character at the defined offset.
Optionally you can specify that the defined value should not simply be compared with the value inside the offset, but invoke the listener to do a bit wise XOR operation to validate the value. This is done by entering an '&' character (without quotes) before the hexadecimal value like '&3a'. This can be useful to check only certain bits within a byte. For instance, the RTP protocol uses the first 2 bits in the header for the version number, which should always be set to 2. If we want to check this we simply take the binary value '1100 0000' and convert it to a hex value, which is 'C0'. You would then specify the offset as '0' and the defined value as '&C0'. The listener will then perform the operation.

if '11xx xxxx' XOR '1100 0000' == '0000 0000'
    check passed
else
    check not passed

Default Configuration

The default configuration should consist of a beacon and a Custom Listener sending/listening to 233.13.5.1. There are also three default configurations for the Custom Listener. One for listening to a TTM beacon and two for listening to a dbeacon. Those are described in more detail in the Custom Listener section above.

Plots

The plots use a similar interface as the unicast measurements. You can view various plots from different listeners. Each listener is represented by a multicast IP address and, in case of a custom listener with Source Stats enabled, a source address. Just select the items that are of interest for you and click on draw. If you want to have one of the plots monitored by the Alarm tool click on "Activate Alarm for this RRD", to turn monitoring off again click on "Deactivate Alarm for this RRD". Important: To avoid false alarms only monitor RRDs that are somehow stable. IE. If you have a delay plot that has serious fluctuations due to imprecise timestamping of the source, do not monitor that RRD. The email you specified on the TTM Configuration page will be used to send you notifications in case an alarm has been triggered. You can watch currently active alarms under the "Alarms" link in the navigation.

In the "Start" field you can either specify something like "now-1week" which would subtract one week from the current time, however you can also specify a time and date in the form "MM/DD hh:mm" (example: "03/14 11:00").

Alarms

The Alarm tool monitors RRD files for any drastic changes using the LTA-STA (Long Term Average - Short Term Average) algorithm.

Alarms can only be added via the plots interface. The "Alarms" menu point will show you what is being monitored and the currently active alarms. You will be informed via email (configure via TTM config) whenever an alarm is triggered or an alarm situation returned back to normal.

Traceroutes

For each configured listeners your testbox runs multicast traceroutes against all sources which recently sent data to a given multicast addresss. Those traceroutes are done using the tool mtrace. Those traces are collected and processed by a server run by the RIPE NCC. They can be accessed via a convenient web interface.