1. WP7 Network Monitoring Schemata
Richard Hughes-Jones / Peter Clarke / Paul Mealor
Hi Richard/Pete
I’ve added a load of notes if you want to read them.
Note that the R-GMA schemas are probably much better than the LDAP schemas

2. Menu
LDAP schema
R-GMA schema

3. LDAP schema design considerations
LDAP schema for MDS
Publication of most recent measurements
Early work
Easy to add new metrics to
Easy to add new measurement parameters to
MDS was harder to add new classes to
Started with LDAP schemas for Globus MDS in EDG. These schemas were primarily for publication of the most recent measurements for any host pairs; mostly because it’s not easy or efficient to store histories in MDS.
This was early work, so we had to work with uncertainty about the state of EDG network monitoring in the future. The LDAP schemas were made to be easy to add new metrics and measurement parameters to – the (EDG) setup of MDS made it relatively difficult and time-consuming to create new LDAP objectclasses at short notice.

4. LDAP schema objectclass ( 1.3.6.1.4.1.8005.666.2.4.26
NAME 'NetworkMeasurement‘
DESC 'Describes a single measurement.‘
SUP ( NetworkMonitorSource $ NetworkMonitorDest $ NetworkMonitorMetric )
STRUCTURAL
MUST ( NMMeasureId $ MetricValue $ MetricTime ) )
objectclass (
NAME 'NetworkMonitorSource'
DESC 'Describes a network monitoring host from which measurements are made. This is here to help the with implementation.'
SUP DataGridTop
STRUCTURAL
MUST ( SourceHost )
MAY ( SourceSite $ SourceNE ) )
objectclass (
NAME 'NetworkMonitorDest'
DESC 'Describes a network monitoring host to which measurements are made. This is here to help the with implementation.'
MUST ( DestHost )
MAY ( DestSite $ DestNE )
objectclass (
NAME 'NetworkMonitorMetric'
DESC 'Describes a single metric and its parameters.Abstract: do not use.'
SUP NetworkMonitorToolName
ABSTRACT
MUST ( MetricName $ MetricUnit )
MAY ( Parameter ) )
This is what the LDAP schema for a measurement looks like. Bit of a mess, not really terribly important. Probably you’ll want to remove this slide from the show. The next slide shows what an LDAP object in use looks like.

5. LDAP schema in use objectClass: NetworkMeasurement
nmMeasureId: foo.ac.uk/bar.ac.uk/rttavg
sourceHost: a.foo.ac.uk
destHost: b.bar.ac.uk
sourceNE: foo.ac.uk
destNE: bar.ac.uk
metricName: rttavg
metricUnit: ms
parameter: packetsize:100
parameter: packets:10
metricValue: 67
metricTime: Z
This contains the average RTT of a measurement between a.foo.ac.uk and b.bar.ac.uk that was made with 10 packets of 100bytes each.
Mappings between source and destination “NEs” and Computing or Storage Elements held elsewhere
This is what an LDAP object containing network monitoring information looks like.
This one represents the average RTT for ten 100byte packets in milliseconds between two hosts: a.foo.ac.uk and b.bar.ac.uk. At the time, we added sourceNE and destNE, which effectively represent the “site” at which the network monitoring host was situated. This should allow for multiple network monitoring hosts (say if some tools completely takes over a host).
Although LDAP is a directory access protocol, the use of the directory tree structure is discouraged in the MDS, mostly because the tree looks different depending where you look at it from.
To map between EDG computing and storage elements and the Network Monitoring “elements”, a separate set of LDAP objects was added. For EDG testing these objects were held in a special Network Information Index, although they could probably have been stored in the general MDS. With this mapping, the NE attributes are probably deprecated.

6. R-GMA schema design considerations
Relational database schema
R-GMA looks a lot like a relational database
R-GMA allows historical information
Different tables for different metrics
Better understanding of network monitoring
Adding new tables easier
Much better for SQL queries
The R-GMA schemata are relational database schemata. R-GMA acts as a relation database, except with the restrictions forced on it by being distributed. R-GMA allows us to more easily store historical information in an SQL database or accessible again by using R-GMA.
R-GMA also enables us to add tables more easily, especially when they allow users to add custom schemas at run time. We also understand the tools available to do measurements (EDG’s and others). These factors allow us to fairly safely have different tables for different metrics, with all the parameters one can modify to make those measurements also stored in the table. Doing this also allows us to form much simpler SQL queries when searching for measurements using R-GMA.

7. R-GMA schema tables NetworkRTT ¥ NetworkCE ComputingElement CEId
GRAMVersion
Architecture
OpSys
&c…
NMIdSource
NMIdDestination
tool
packetSize
time
minimum
maximum
average 1
CEId
NMId
NetworkCE
CEId
NMId 1 1
NetworkTCPThroughput
NMIdSource
NMIdDestination
tool
bufferSize
streams
duration
time
value
NetworkSE
SEId
NMId 1
This slide shows the a few tables in the network monitoring schema and their relationships with each other and the other EDG information schemas.
On the left are two tables: one for Round Trip Time and one for TCP Throughput (it’s called NetworkTCPThroughput). The tables contain all the necessary parameters which can be adjusted when making a measurement. The “minimum,maximum,average” and “value” colums are the results of a measurement made at time “time”. The NMId* columns indicate some sort of identifier for the network monitoring nodes.
In the middle are two tables: NetworkCE, which is shown twice as the source and destination NMs will be different, and NetworkSE. These tables provide the mappings between EDG Computing or Storage elements (the table for which is on the right hand side) and the network monitor hosts.
We’ve defined tables for RTT, TCP throughput, ICMP packet loss, UDP packet loss, one way IPDV, UDP throughput.