Multicast Reachability Monitoring Protocol (MRM)
End Host Implementation

Kamil Sarac (ksarac@cs.ucsb.edu)
Kevin Almeroth (almeroth@cs.ucsb.edu)

OVERVIEW OF MRM

The MRM Protocol has been designed to assist in the detection and isolation of network faults related to the delivery of multicast traffic. In particular, management functions offered by MRM are specifically designed to monitor multicast reachability and assist in the investigation of routing anomalies and connectivity problems.

The operation of MRM is based on communication and coordination between three types of network entities:

  1. MRM Manager:   Provides an interface enabling a user to configure and execute tests; and then collect and present results. The MRM manager communicates with MRM testers who are instructed to source and/or receive multicast traffic. The MRM manager, through beacon messages, also maintains and modifies the set of MRM testers.
  2. Test Sender (TS):   Responsible for sourcing multicast traffic. TSs receive requests from the MRM manager and will send multicast packets to a specified multicast address for a specified time duration with a specified inter-packet transmission time.
  3. Test Receiver (TR):   Expected to either  explicitly join a mutlicast group or simply monitor traffic on a specified group address. Based on thresholds or polls for reports sent by the MRM manager, a TR will report packet loss reports back to the manager.

MRM END-HOST IMPLEMENTATION

This site contains an end-host implementation of the MRM Protocol including an MRM Manager (MRM_Manager),  MRM Test Agent (MRM_Agent), MRM Test Sender (MRM_TS) and MRM Test Receiver (MRM_TR).

NOTE:  The end-host implementations included in this directory adhere to the standard as much as possible. However, as the standard is still  in flux, differences are likely to exist.  Additionally, much of the testing with the end-host implementation has been done using MRM  functionality implemented in Cisco IOS 12.0S.


MRM END-HOST DISTRIBUTION


MRM END-HOST DOWNLOAD INSTRUCTIONS

  1. Download binaries for your platform:
    1. Download mrm-1.0b-*.tar.gz   (* : sunos57 | other binaries to be available soon)
    2. Type "gunzip mrm-1.0b-*.tar.gz"
    3. Type "tar xvf mrm-1.0b-*.tar"
  2. Running MRM:
    1. Start a test by running MRM_Manager with the supplied test config files:

    2.  

       
       
       

GENERAL USAGE:
MRM Manager :   MRM_Manager  [<test config file>]  [-localip <local ip address>]
MRM Agent:         MRM_Agent <local ip addr> <log filename> <max bw in kbps> [manager ip list]

Note: MRM_Manager and MRM_Agents should be on different machines and there should be at most one MRM_Agent running on a machine.
Note 2: Since the protocol uses port 679, both MRM_Manager and MRM_Agent should be super user level processes.


MRM END-HOST IMPLEMENTATION DETAILS

The implementation has four parts: MRM_Manager, MRM_Agent, MRM_TS and MRM_TR.

MRM_Manager: This is a very basic MRM manager tool running on an end-host. A user can use a configuration file to specify test parameters or can enter the values using the text based interface. If a configuration file is to be used, the name of the file should be supplied as command line argument to MRM_Manager ( see USAGE above ).   Once the test parameters are specified, the manager sends requests to corresponding test senders and test receivers. The incoming Status Reports from test receivers are displayed on the terminal as they arrive. In order to stop the test and quit the MRM_Manager,  the user presses Ctrl-C. The manager will then send test stop messages to test agents and quit.

The format of configuration file is important. Users should use the included ucsb-mrm-test-config1 configuration file as an example in creating test configurations. The parser reading this file is very sensitive.

For the test multicast addresses, a default value 0.0.0.0 causes the manager to select an address based on the manager's IP address. The exact address is determined by appending the last two octets of manager's IP address onto the end of 224.3. For example, if the manager is running on 128.111.52.19, the selected multicast address would be 224.3.52.19. We encourage users to use this default option, if suitable, to avoid multiple managers sending test requests with the same multicast address to the same end-host test agent. NOTE: the MRM_Manager must be run as ROOT.

MRM_Agent: This is the main MRM agent process running on an end-host.  It listens to the UDP MRM port (679) and when it  receives a Test Sender Request (TSR) or Test Receiver  Request (TRR), it forks a new child and runs MRM_TS or  MRM_TR. NOTE: the MRM_Agent must be run as ROOT.

MRM_TS: This code runs an MRM Test Sender and is initiated by the MRM Agent. The Test Sender joins the multicast group and sends RTP formatted test data packets to the group until either the holdtime duration expires (in which case it kills itself and the agent is notified) or the agent  receives an "mrm test stop" request from the manager (in which  case the agent kills MRM_TS). A Test Sender sends packets only  from the targeted interface (the ip address in the "test sender request" packet).

MRM_TR: This code runs an MRM Test Receiver and is initiated by the MRM Agent. It joins the multicast group and listens for incoming data packets. The Test Receiver computes loss information every second and sends Status Reports to the manager. Currently it uses only unicast for Status Reports. Reports are only sent to the manager.  In calculating loss, it  uses timer interrupts.  After each second, the Test Receiver  generates an interrupt and examines the test packets received
during the last window (one second).  Because information is  stored about the arrival of each MRM packet, loss information  can be calculated in more detail than a standard RTP loss calculation.  For example, in a given interval, if x test  packets are lost and y are duplicated and x = y, RTP will calculate a 0%  loss.  The MRM Test Receiver will report that x packets are  lost (and ignore the y duplicate packets).  If x = 0 packets are lost, the MRM Test Receiver will report any duplicate packets, if y>0  (as negative loss).  Ideally the MRM Test Receiver should  report two numbers:  lost and duplicate packets but only one  field exists.


EXAMPLE TEST CONFIGURATION FILE FOR MRM MANAGER

Multicast Address (default 0.0.0.0 will select a random address - preferred) : 0.0.0.0
Number of Test Senders : 1    (***)
Enter Sender IP : 128.111.52.11
Number of Test Receivers : 1
Enter Receiver IP : 128.111.52.15
Test data port (default is 16384- SHOULD BE EVEN) : 16384
Status report port (default is 65535- SHOULD BE ODD) : 65535
Threshold loss% to send reports (default is 0%) : 0
Test packet length = 2^(4+x). Enter x value (range is 0-7, default is x=0) : 0  (****)
Packet interval (default is 200 msec) : 200
Holdtime (test duration - default is 3600 sec) : 3600
Receive window (default is 5 seconds) : 5
Maximum report delay (default is 3 sec - should be at least 1) : 3
Startup delay (default is 60 sec) : 60

(***) : If you want to have more than one test senders or test receivers, you should have a separate line for each of them. For example, if you want to have 3 test senders, then the config file should follow as:
.
.
Number of Test Senders : 3
Enter Sender IP : 128.111.52.11
Enter Sender IP : 128.111.52.15
Enter Sender IP : 128.111.52.18
.
.

(****) : This option is not implemented in the current Cisco implementation. They send test packets of size 16 bytes only.


END-HOST IMPLEMENTATION LIMITATIONS

- The beacon mechanism is not implemented for the Manager.

- In the current Cisco implementation, Status Report ACK messages are improperly formatted. When the Cisco MRM Manager receives a Status Report ACK, it is discarded instead of processed. In order to avoid unnecessary retransmissions, Test Receivers will send Status Reports only once.

- The Test Sender supports RTP formatted test data ONLY.

- In the MRM Draft, TSR packets have a field specifying the   IP address that the TS should use to source packets.  This   option allows routers to spoof IP packets.  For security,   this option is not allowed in the end-host implementation.

- Test Receiver uses ONLY unicast to send status reports to the manager.

- There is no way to specify a TTL value for test packets. Test Senders set a TTL of 127.

- The MRM Agent executes a new process to serve to each test session request. Once a test is started, the test parameters cannot be changed. The Manager must end the current test and start a new test.


This is only a beta version of the implementation. Please report any problems/bugs to Kamil Sarac.