Re: [GLIF controlplane] RE: Network Control Architecture

[Gigi Karmous-Edwards <gigi@xxxxxxxx>]

Hi Admela,

I agree, there are two phases, 1) check availability from xRM, and 2) If 
all xRMs give an ack. then go th second phase of commit, 2') if one or 
more xRM gives a nack, then do not proceed to the phase two commit. In 
the architecture sent out, the responsibility of coordinating and 
administering the two phases is in ONE RB per request. Each xRM will 
rely on the RB to tell them  whether to proceed to a commit or not. If 
they get a commit from an RB, it then becomes the xRM's responsibility 
to make the reservation and allocation in the actual resources. I think 
if  for example RB-A talks to an xRM in domain "B", then it may be the 
responsibility of the xRM-B to tell its own  RB-B of its interaction 
with RB-A. Is this in line with your thoughts?

Gigi

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

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



Admela Jukan wrote:

> May I post one more comment.
>
> I think the point of confusion may be that there is no distinction  
> between two phases, i.e., "resource reservation" (Gigi's point B) and  
> "resource allocation" (Inder's point).
>
> In Gigi's architecture,  it is a process which reserves a resource  
> and this can be implemented in various ways, e.g., Web services, or  
> so that RM for example only has to discover the IP address of the  
> Resource Controller (a device which controls the resource, NOT the  
> resource itself).
> If a resource controller advertises its corresponding "resource",  
> similar to UCLP, this resource can be reserved, regardless of the  
> domain it belongs. Strictly speaking, this is done in Layer 7, and  
> locally at every advertised NE. Really no need for any RB to know this.
>
> The problem may happen when the "actual path" has to be established  
> (phase 2), i.e., if there is no agreement between two domain's RB's  
> (e.g., due to firewalls or policy, as Inder rightfully states).
>
> I can think of this as the following. You go to Web and book a flight  
> over a (rogue) airline, you pay (phase 1), and (phase 2) go to the  
> airport, but there is neither the airport nor the airline there (not  
> visible to you (due to RB not being aware of your deal!).
>
> In my view, these two phases are somewhat blurred right now.
>
> On Apr 18, 2007, at 11:34 AM, 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
> > > --------------------------------------------