Re: Network Control Architecture

[Gigi Karmous-Edwards <gigi@xxxxxxxx>]

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

--------------------------------------------

Gigi Karmous-Edwards
Principal Scientist
Advanced Technology Group
http://www.mcnc.org
MCNC 
RTP, NC, USA
+1 919-248 -4121
gigi@xxxxxxxx
--------------------------------------------



Jeroen van der Ham wrote:

> Hello,
>
> 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.
>
>
> Regards,
> Jeroen.
>
>
> [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".
>