Global Lambda Integrated Facility

Subject Re: Network Control Architecture
From Gigi Karmous-Edwards <gigi@xxxxxxxx>
Date Thu, 19 Apr 2007 06:59:04 -0400

Hi Jeroen,

For your first point about components in the DNRM, we only put in functional components in the diagram. I agree the implementation from one DNRM to another may be completely different but provide similar functionality.

I agree the number of interfaces seem large, but each is suited for a particular resource and with the exception of the DNRM, they should mainly behave as translators between a broker request (based on standard interface) and the resource scheduler ( which contains the majority of logic). We should try to develop a very generic set of calls that can be used for each interface and then only a few calls specific to the type of resource.

Regarding a central broker, we assumed each "Grid administrative domain", or "resource domain" if we want to use that term will have a corresponding Resource Broker (RB), (which could be made redundant to avoid single point of failure). However, I disagree that RBs should make requests to each other due to the transaction problem. I do not think the RBs will obtain resource information about resources outside of their domain. If resources are requested which are outside of an RB's domain, then the RB will make a query to the distribute GLIF "distributed " resources to locate the other xRM necessary to resolved the request. I think this is where your work on NDL comes into play. How does each domain publish the information about resources and the corresponding URI for the xRMs.

I think each xRM should contain its own policy for usage and that is not the responsibility of the RB.

Thanks for the information about the new NML working group in OGF!



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

Jeroen van der Ham wrote:


This framework seems an interesting startingpoint to work toward a
common architecture. I think the important point we need to agree on is
what kind of components need to be present in the architecture. For
example, the second slide lists all the important components for a DNRM,
but it will depend on the implementation how they are tied together. We
really should focus on the interfaces presented to the outside.

The amount of different interfaces listed in the first slide seems
staggering. I am certain that the architecture as listed there does not
scale. The resource broker has to know about all different kinds of
interfaces, and it is also impossible for one domain to maintain
information about all the different resources in other domains. Combine
that with policy restrictions and the equation becomes even more complex.

The way forward really seems to be using a central broker[1] for the
domain, with a standardised interface to other brokers. I agree that we
should aim to do this first for network resources, and then we can see
how this can be extended for other resources.

I completely agree that the interfaces should be generic and not Grid
specific. The reason why we're using the OGF as standardization body is
because they are already doing related things in the Network
Measurements WG[2].

I would like to invite everyone to the first session of the Network
Markup Language WG at OGF 20, May 9th in Manchester.


[1]: "Central broker" in the sense that applications will know how to
approach the domain. This does not necessarily imply that it should be
one single services or single point of failure.
[2]: Note that the charter of the Network Markup Language WG only
contains the word "Grid" once, in the term "Open Grid Forum".