Re: [GLIF controlplane] RE: Network Control Architecture

[Bram Peeters <bram.peeters@xxxxxxxxxx>]

Indeed - the options we're considering are a p2p architecture or a 
distributed approach. In the first architecture you rely on a 
reliable/redundant local RB to coordinate the end-to-end provisioning 
using access to other RBs and NRMs from other domains. In the second 
option you rely on the combined systems to converge on good solutions.

Bram

Cees de Laat wrote:

> 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
> > > > > --------------------------------------------