CLMPService

From GEANT2-JRA1 Wiki

Contents

[edit]

Objectives

Network measurement tools are responsible for testing services of the network. They permit to the Network Operational Center (NOC) staff to diagnose problems with the operation of the network. One restriction this kind of tool has is the need to have access to the workstation originating the test. This limits the network operators to their own domain, which can be very inefficient when diagnosing inter-domain network related problems. An even more restrictive situation happens when you need to compose metrics to diagnose the problem.

The objective of the Commmand Line Measurement Point (CL-MP) is to enable users to run tests across domains with a common language to reach the metrics. Command line tools are developed to run in command line environments. This characteristic makes in possible to automatize the metric collection. Command line tools can be abstracted as command, valued arguments, and descritive results. This combination allows any tool to be described in a way that allows the definition of the test to be parameterised and the analysis of the metric results can be described from the test execution.

Basically, the CL-MP is a "tools wrapper". The basic idea is that you can very easily add new tools to the perfSONAR framework and use the common schema language to talk to them while respecting the unicity of each tool. This enables a single MP to provide multiple tools producing a different combination of metrics.

[edit]

Achievements

There is no snapshot version available yet. It is currently in a testing environment only. But, some achievements have been achieved:

  • Measurement Executor: prepared to run the command line;
  • Measurement Request: message prepared to integrate different tool needs;
  • Measurement Response: sent to requester;
  • Tools integrated: BWCTL, OWAMP, Ping and Traceroute.
[edit]

Next steps

The next steps are:

  • Integrate new tools. E.g.: Iperf and NTPTime;
  • Scheduling for recurring events (and maybe resource protection);
  • Generic configuration;
  • MA insertion;
  • LS integration;
  • code revision to get more generic.
[edit]

References

perfSONAR SVN

[edit]

Contact

Fausto Vetter (RNP) <fvetter@npd.ufsc.br>

Jeff Boote (Internet2) <boote@internet2.edu>

[edit]

Work in progress

The work that is being done is:

  • Better logging;
  • Temp files (bwctl/err/out) exclusion;
  • Better testing (JUNIT/ANT).
[edit]

Implemantation Details

The perfSONAR base service was used to implement the command line MP. This code handles all the webservice and nmwg standard, though extensions are needed to implement each specific tool nmwg portion of code.

The command line MP is basically a Service Engine that handles the web service calls and send to the right tool what to do based in the right action. This process is shown in the diagram below.

Media:MakeMeasurement-Sequence.dia

This diagram shows the process of MakeMeasurement request. All requests are handled by takeAction in CommandLineMPService. Based on actionType, this class uses a different method. In the case if actionType MeasurementRequest, it creates CommandLineAction and send a makeMeasurementRequest sending the message as attribute. After, CommandLineAction gets the right tool based on the eventType. It was implemented based on the Abstract Factory Pattern. The class CommandLineActionFactory receives the getCommandLineToolBundle message, then based on the eventType creates the right tool class and send it as response of it. Finally, it sends a runTool to the gotten class and sends back the response to the service requester.

[edit]

Case Study BWCTL: Adding a new tool

A new tool is able to be added in few standard steps. This section will follow you through this process giving you a pratical example using the BWCTL tool. BWCTL tool is a command line wrapper to Iperf tool, that enables better bandwidth scheduled tests.

The generic steps to add a tool to perfSONAR is the following:

  1. Implement NMWG extension classes to handle the specific tool
    1. Datum Class
    2. Parameters Class
    3. Subject Class
  2. Implement ToolBundle extension class to handle the specific tool
  3. Define the CommandLineToolBundleFactory class in the hash of CommandLine factory

Based on this simple steps, to integrate BWCTL the first thing is to create the classes that will handle NMWG. All this classes must to be located at the following package:

org.ggf.ns.nmwg.tools.bwctl.v2_0

For each new tool, a new package should be added. The basic rules that must to be followed to define this package is:

  • org.ggf.ns.nmwg.tools : it is the basic root package to NWMG Tools code handlers;
  • bwctl : the specific tool package. In this case, bwctl because the tool to be integrated is BWCTL. Examples of other packages would be ping, owamp, traceroute, that are already implemented.
  • v2_0 : schema version. In this case, the schema used is v2_0.

Created the package, the Datum, Parameter and Subject class should be created. They should be implemented in a standard way, following the examples of other tolls already implemented. For each class, the following should be implemented: 

Datum Class
----
Tools results should be implemented as Class attributes (gets and sets)
The constructor should define the following:
    localName : defining the class name
    uri : defining uri name. It should follow this standard:
        http://ggf.org/ns/nmwg/tools/ [tool_name] / [schema_version] /
    qName = "[tool_name]:[local_name]";
    prefix = "[tool_name]";
    fileName = the following file name.

For BWCTL, the following was defined:
    localName = "datum";
    uri = "http://ggf.org/ns/nmwg/tools/bwctl/2.0/";
    qName = "bwctl:datum";	
    prefix = "bwctl";	
    fileName = "org/ggf/ns/nmwg/tools/bwctl/v2_0/Datum.java";

Change the following methods to support the new tool results:
    addAttr(String attr, String value, NamespaceSupport nss)
    getAttributes(NamespaceSupport nss)
    getDOM(org.w3c.dom.Element parent)
    toString()

Parameters
----
The constructor should define the following:
    localName : defining the class name
    uri : defining uri name. It should follow this standard:
        http://ggf.org/ns/nmwg/tools/ [tool_name] / [schema_version] /
    qName = "[tool_name]:[local_name]";
    prefix = "[tool_name]";
    fileName = the following file name.

For BWCTL, the following was defined:
    localName = "parameters";
    uri = "http://ggf.org/ns/nmwg/tools/bwctl/2.0/";
    qName = "bwctl:parameters";
    prefix = "bwctl";		
    fileName = "org/ggf/ns/nmwg/tools/bwctl/v2_0/Parameters.java";

Change the following methods to support the new tool results:
    getParameterByName(String name)
    addParameter(Parameter newParameter)
    addParameter(String name, String value)

Subject
----
The constructor should define the following:
    localName : defining the class name
    uri : defining uri name. It should follow this standard:
        http://ggf.org/ns/nmwg/tools/ [tool_name] / [schema_version] /
    qName = "[tool_name]:[local_name]";
    prefix = "[tool_name]";
    fileName = the following file name.

For BWCTL, the following was defined:
    localName = "subject";
    uri = "http://ggf.org/ns/nmwg/tools/bwctl/2.0/";
    qName = "bwctl:subject";		
    prefix = "bwctl";
    fileName = "org/ggf/ns/nmwg/tools/bwctl/v2_0/Subject.java";

Commnand Line Subject class already has EndPointPair information.
If it is needed more for subject, this information should be added here.

After it, the next step is to create the tool handler. A new tool handler should be created under the package:

org.perfsonar.service.measurementPoint.commandLine.tools

The new class should be named as the tool name. It is not a restriction, but a recommendation when possible. When creating this class, the following should be defined: 

CNAME : which define the tool bundle class name
getToolBundleName() : returns the tool bundle name
getToolName() : returns the tool name
getToolBundleVersion() : returns the version of tool bundle
getToolVersion() : returns the tool version
runTool(Message reqMess) : executes the command line tool

A fully functional example is showed in BWCTL tool bundle implementation. In this class you may see the other private methods and tool options handlers to improve and make faster the implementation.

Finally to finish and enable this tool to run, the eventType mapping to commandLineHandler should be defined in CommandLineToolBundleFactory in the existing hashtable. The new entry is eventType as key, and the class name as value. To BWCTL the entry was: m2c.put("BWCTL", "org.perfsonar.service.measurementPoint.commandLine.tools.Bwctl");

With this few steps, the service now is ready to be compiled and re-deployed to run the new tool, in this case BWCTL.

Retrieved from "http://wiki.perfsonar.net/jra1-wiki/index.php/CLMPService"
Personal tools