Re: [GLIF controlplane] RE: Network Control Architecture

[Cees de Laat <delaat@xxxxxxxxxxxxxx>]

Correct, we need robuust p2p architectures and principles here.

best regards,
Cees.

At 14:30 -0700 18-04-2007, Harvey Newman wrote:
> Hi,
>
> We foresee a ML service to do that, as in our VINCI project.
> Without agents to work within each domain, and without
> the fact that agents know how to discover each other, gather
> intra-domain information and collaborate, you will end up
> writing, or trying to write, too much code specific to a
> growing list of situations.
>
> We don't think a single resource broker can work.
> It's a single point of failure. And, if there is a distributed
> set of them, you better understand your messaging infrastructure.
> We need this to be in production, and we can't afford to
> have it all come down.
>
> See
> http://monalisa.cacr.caltech.edu/monalisa__Service_Applications__Optical_Control_Planes.htm
>
> Regards
> Harvey
>
>
> Bram Peeters wrote:
> > Hi Gigi, Inder, all -
> >
> > Interesting discussion -
> >
> > On (B) - I do indeed remember a pretty healthy discussion on that 
> > in Minneapolis, both on the single RB accessing other domains, and 
> > some more discussion on policy/authentication. I think what Gigi 
> > states in her response is actually pretty much what we ended up 
> > with - the idea that an "interdomain broker" would access all local 
> > NRBs / NRMs / NARBs /... This would solve the problem of having 
> > distributed commit issues, and basically quite a lot of other 
> > distributed issues such as routing, policy control,...
> >
> > In Phosphorus WP1 a similar approach has been taken with the 
> > introduction of the NSP (network service plane) that will talk to 
> > all domains involved through a "standard" interface (or basically 
> > all domain NRMs support the same set of request/response messages 
> > to allow the NSP to create an end-to-end connection). Doing it this 
> > way and not a complex distributed system was initially required to 
> > get a reasonable chance of actually getting something working by 
> > the target date of end October 2007 - which is still some time 
> > away. However - I start to like that approach more and more, as it 
> > seems quite a few problems become less problematic, and I can see 
> > ways of doing policy / resource control and authentication in such 
> > a system.
> >
> > That approach where for an application's request a single entity 
> > contacts all domains is - if I look carefully - at the top-level 
> > the same as the network-bit on the slides that Gigi sent, where the 
> > RB would be the Phosphorus-NSP-like application, and the NRM is 
> > DRAC/UCLP/Viola/anything else. For Phosphorus WP1 only the GNI 
> > arrows are relevant, and due to only one NSP being developed the 
> > resource registry where (topology + interconnect) resource info 
> > from the different domains is published is contained inside the NSP 
> > as well.
> >
> > On a side note - I'm not convinced (yet??) that a single resource 
> > broker will do the multi-domain, multi-technology brokering - I'd 
> > be looking for a metascheduler/broker that talks to one RB/NSP that 
> > will hide all the gory details of networking issues to the Grid app 
> > (routing, networking technology stitching,...), so one more layer 
> > of complexity before you get from the network to the application. 
> > And it would limit the number of acronyms I need to remember for 
> > now ;-)
> >
> >
> > Bram
> >
> >
> >
> >
> >
> >
> >
> > Gigi Karmous-Edwards wrote:
> > > 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
> > > > --------------------------------------------


--
http://www.science.uva.nl/~delaat/