Re: Network Control Architecture
"Eric L. Boyd" <eboyd@xxxxxxxxxxxxx>
Thu, 19 Apr 2007 10:28:11 -0400
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
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
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
that MonALISA has had in operation for a long time.
It is also not obvious that PerfSONAR will engage a full time systems
try to reproduce the real-time services architecture with a
multithreaded engine to schedule and drive the services, a fully
architecture that has no single point of failure, a mutually-aware set of
agents, a robust high - performance messaging infrstructure, etc. It
be easy and it has rarely, if ever, been done before. In case how a
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,
And ML will conitnue to advance and grapple with the real situation at
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
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
as needed. That is already the case for the PerfSONAR monitoring sone
Gigi Karmous-Edwards wrote:
How does MonAlisa compare with the effort of PerfSONAR
Advanced Technology Group
MCNC RTP, NC, USA
+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
Gigi Karmous-Edwards wrote:
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
Eric Boyd, Director
Make high-performance connections in person:
The Spring 2007 Internet2 Member Meeting