Re: [GLIF controlplane] RE: Network Control Architecture

[Gigi Karmous-Edwards <gigi@xxxxxxxx>]

Hi Inder,

Thank you for your comments.

A)  We use Grid in terms of the concept of "resource sharing".  In terms 
of the the interfaces that we all will develop together there will be no 
Grid relevance. The framework only shows functions and tries to specify 
interfaces to be standardized. Implementations of the resource broker 
(RB) and resource mangers (xRM) could be completely independent of Grid 
technology. We are assuming that a network resource manager could be 
implemented in various ways which may or may not include Grid 
components. An example of an Domain Network Resource Manager (DNRM) 
could be based on DRAC, UCPL, or GMPLS, etc

Another reference to Grid came from the name of the GLIF group, "GLIF 
Control Plane and Grid Middleware" working group.  In my personal 
opinion, we can just call it middleware rather than Grid middleware. To 
conclude, the interfaces will not have Grid specific attributes but will 
accommodate Grid applications.

B) I understand your concerns. This topic was discussed at great length, 
and I do not think we are all on the same page on this topic. The 
motivation for allowing a resource broker (RB) access to another 
domain's resource manager (xRM) is due to the transaction problem 
associated with the coordination of multiple resources. The 
implementation of the phase commit is currently the responsibility of 
the resource broker and not the resource managers. Therefore, if a 
request comes to a RB for multiple resources across multiple domains, 
the complexity of the transaction problem will greatly increase if each 
of the domain's RBs had an independent phase commit and then follow that 
with an overall phase commit for all the resources across all required 
domains. In contrast if only one RB was responsible for the phase commit 
for all the requested resources (across all domains) will simplify the 
transaction problem. Also, it is assumed that an  RB's access to a xRM 
in its domain has no particular advantage that is not reflected in the 
policy of the resources (which will be advertised by the xRM).



C) Thank you very much for sharing your document; it is very informative.

I am not sure I addressed all your concerns.... look forward to hearing 
from you.

Gigi

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

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



Inder Monga wrote:

> Dear Gigi and All,
>
> I was not present at the last GLIF meeting and plan to remedy that going
> forward. I apologize for maybe bringing up the same issues again, but
> these are my initial reactions in looking at the slides:
>
> A) I am surprised to see such a deep Grid flavor to the interfaces. I do
> understand Grids are an important application of the GLIF network, but
> can't GLIF define generic interfaces that can be used by non-grid
> applications, management platforms, automated scripts? To choose this
> path because OGF as a likely standardization body is not the right
> reason. The defined generic interfaces need to fit into the "grid"
> resource management model.
>
> B) In examining the multi-domain proposal, it looks like the RB from one
> domain can request access to resources directly from the specific RM of
> the next domain without notifying the RB of the other domain? This model
> does not appeal to me. 
> I am concerned about the case when resources are required across "n"
> domains (say),  RBi (where i belongs to N) needs to access and request
> resouces from xRMj where x = Network, Compute, Storage, Instrument and j
> = 1 .. n, {n <=N} ? In this case, the RB needs to have knowledge of and
> have access to (through firewalls) to all those RMs.
>
> In the multi-domain model we have demonstrated (detailed document
> attached) that having each domain manager manage the resources within
> its own domain makes the best architecture. With that model you have the
> advantage of having only ONE multi-domain resource request entry point
> (and corresponding AAA policies).
>
> I look forward to discussions on the mailing list.
>
> Thanks,
> Inder
>
>
> -----Original Message-----
> From: owner-tech@xxxxxxx [mailto:owner-tech@xxxxxxx] On Behalf Of Gigi
> Karmous-Edwards
> Sent: Tuesday, April 17, 2007 4:18 PM
> To: controlplane@xxxxxxx; GLIF-tech
> Subject: [GLIF tech] Network Control Architecture
>
> 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,
> Gigi
>
> --
> --------------------------------------------
>
> Gigi Karmous-Edwards
> Principal Scientist
> Advanced Technology Group
> http://www.mcnc.org
> MCNC
> RTP, NC, USA
> +1 919-248 -4121
> gigi@xxxxxxxx
> --------------------------------------------
>
>