Global Lambda Integrated Facility

Subject Re: Network Control Architecture
From "Eric L. Boyd" <eboyd@xxxxxxxxxxxxx>
Date Thu, 19 Apr 2007 10:28:11 -0400

Hi all,

Sorry to join the discussion late.

Before comparing Monalisa and perfSONAR, it might help to define exactly what perfSONAR is.

First, perfSONAR is primarily a set of services and protocols (schema) for sharing performance data. The specific data schemata are extensible making it possible to share any kind of data that fits in the general architecture. (Basically performance data.)

Second, perfSONAR is a project made up of individuals and institutions that are actively developing tools, libraries, and schema in support of this data sharing. (Active participants include Internet2, ESnet, the GEANT2 JRA1 project [including many European NRENs], RNP, UDel, and Fermi.)

Third, there are several perfSONAR implementations - of clients and services. But, it would be a mistake to call any one of them 'the' perfSONAR implementation. The advantage of the open source effort is that there is a best-of-breed competition for nearly all components. The only truly important thing is that all components understand the same protocols - syntax (schema) and semantics (business logic). (These are being standardized in the context of the OGF NM-WG and the OGF NML-WG.)

It is true that monaLISA (mL) currently has more functionality than the current set of pS applications. However, due to the open-source nature of the perfSONAReffort (there are 10's of developers working on the many aspects of perfSONAR) I would expect that to change over time. (We originally wanted to work with Cal Tech to enhance mL but we were not willing to sign the licensing contract.)

Architecturally, the two frameworks are very similar. They are both Service Oriented Architectures (SOA) with a defined set of services. perfSONAR is still growing and not all aspects of the distributed services model have been implemented. (For example, current services use a global single point of failure Lookup Service (LS). However, the multi-LS has already been alpha tested and is likely to be in the next major release.

The primary differences:

MonaLISA is written in Java and makes use of some Java only technologies like JINI. I do understand that MonaLISA can access non-Java services. But, if I understand correctly, to truly 'join' the SOA network of services, you would need some Java.

perfSONAR is an open-source development project. There is good and bad to this. Even those of us that have been involved from the beginning do not have very much central authority or control over it. This can cause problems with interoperability, which is why the aforementioned standards process is so important. However, if someone wants their favorite new network metric made available to others - they can make it happen. They don't need to get someone else to do it for them, or sign away their ability to develop related software in the future. Since the point of implementing and deploying this software is to share the data - it is usually not too difficult to get people to agree on shared schemata.

Most perfSONAR applications are currently focused on network hardware and statistics. This is only natural since the first participants (and still the largest constituency) is networking organizations. However, I would like to make it clear that perfSONAR can absolutely go all the way to the desktop. There are already services written to run arbitrary command-line tools (CL-MP). The only thing required to return something like cpu utilization (or any other host statistic) is to define a schema for that type of data. (I agree that is is critically important to collect host performance issues to be able to differentiate host and network performance.)

Hope this helps inform the discussion. I'm happy to answer questions.


Harvey Newman wrote:
PerfSONAR is just beginning to develop a fraction of the services and functions
that MonALISA has had in operation for a long time.

It is also not obvious that PerfSONAR will engage a full time systems architect to try to reproduce the real-time services architecture with a sufficiently powerful multithreaded engine to schedule and drive the services, a fully distributed services
architecture that has no single point of failure, a mutually-aware set of
agents, a robust high - performance messaging infrstructure, etc. It would not be easy and it has rarely, if ever, been done before. In case how a fully fledged
PerfSONAR would compare to ML is a future consideration. It won't be
sufficiently function by the time the LHC is starting to do physics, by mid-2008. And ML will conitnue to advance and grapple with the real situation at the LHC.

PerfSONAR will not touch the end systems. ML does cover this aspect fully, as we need to distinguish end-system performance, load and configuration issues from network issues.

Since PerfSONAR is the agreed upon direction, and the services it fields will be relatively simple, we are sure we can interface to those and provide the interfaces as needed. That is already the case for the PerfSONAR monitoring sone today.


Gigi Karmous-Edwards wrote:
Hi Harvey,

How does MonAlisa compare with the effort of PerfSONAR (



Gigi Karmous-Edwards
Principal Scientist
Advanced Technology Group
+1 919-248 -4121

Harvey Newman wrote:


We strongly recommend using MonALISA real-time, fully distributed services to do this. We need non-stop real-time operations that are proven to be robust and globally scalable, with no single point of failure. Also the intelligence in the agents both in the network and end-systems
allow us to understand what is going on, and take action end-to-end.
Hence our technology choices for US LHCNet and UltraLight.


PS ML is currently monitoring and updating > 1M parameters at 340 sites.

Gigi Karmous-Edwards wrote:

Dear All,

At the last GLIF control plane meeting in Minneapolis (meeting minutes will be sent tomorrow to the list) we had several discussions on interoperability between the different networks. We drew a diagram on the white board with input from the participants. The outcome was an action item on me to send out a high level functional diagram on the framework for interoperability (sorry for the delay). We expanded the notion of network resource in the control plane working group to include other resources as well, such as compute, storage, instruments, etc.

Enclosed are three very high level slides discussing the framework and the high level functional components included in a "Resource Broker " and a "Network Resource Manager". Several of you in the meeting had comments on the interfaces we need to standardize. I propose we start with the "Grid Network Interface" GNI, first.

We also agreed to work with both the GLIF community and standard bodies like OGF to develop these interfaces. I look forward to your comments.

Kind regards,

Eric Boyd, Director
office: +1-734-352-7032

Make high-performance connections in person:
The Spring 2007 Internet2 Member Meeting