« Return to Thread: clearinghouses (or not)
Re: clearinghouses (or not)
by Larry Peterson
::
Rate this Message:
Sure, you can always have a "clearinghouse broker" that
manages credentials so the AM doesn't have to...
So we have a set of functionality that can be bundled in
a clearinghouse (or not). They include (at least):
1) Credential manager (so aggregates don't have do deal
with credentials);
2) Resource manger (collects tickets from aggregates and
redistributes to users based on some allocation policy);
3) Aggregate aggregator (or virtual aggregate that "hides"
multiple aggregates behind a unified front-end); and
4) A slice manager (that offers users some nicer abstraction
than the "machine language" provided by the slice interface
and rspecs).
The geniwrapper implementation really only does (3), although
our arm is being twisted to do (1) as well. We don't do (2) -- each
individual aggregate makes resource allocation decisions on its
own behalf -- and we push (4) to the client front-end (currently a
set of Unix command line tools).
My original posting observed that practical issues suggest (3)
and (4) can be bundled and located on the client's desktop; and
that if you do this, (1) is orphaned (and personally, I don't see
why it's a big deal for an AM to decode and check a credential).
Larry
On Thu, Apr 16, 2009 at 2:06 PM, Schwab, Stephen
<Stephen.Schwab@...> wrote:
> Hi Larry,
> This is a very useful (and clear) message, so thank you for sending it.
>
> I think you may have painted too sharp of a contrast between doing
> things one-way-or-the-other.
>
> For example, the user's SM may sign some request and bundle with that
> request all the necessarily credentials and attributes to entail
> authorization of that request at an AM. But that doesn't mean there
> can't be a "clearinghouse-like broker" in the path. So the request
> would flow from:
>
> SM --> Clearinghouse broker --> AM.
>
> What would the Clearinghouse broker do? It might check the request
> itself, and then add an "endorsement" attribute to it, before forwarding
> it on to the AM. Nothing in the architecture restricts (or requires)
> this sort of thing -- but it would afford a place for "centralized
> policy" to be applied.
>
> Of course, the policy could be bypassed: if the AM wants to service
> requests that don't have a clearinghouse endorsement attribute, that is
> the AM's business. (And so the GENI environment would not be limited to
> one sort of AM that respected one centralized Clearinghouse policy.)
>
> I don't think there is much additional complexity in supporting this
> approach. Essentially a clearinghouse would just interpose, acting as a
> proxy w.r.t. the AM interface in this situation.
>
> --Steve
>
> -----Original Message-----
> From: control-wg-bounces@... [mailto:control-wg-bounces@...]
> On Behalf Of Larry Peterson
> Sent: Thursday, April 16, 2009 11:07 AM
> To: control-wg@...
> Subject: [cwg] clearinghouses (or not)
>
> We've recently been evaluating our approach to geniwrapper, and
> I thought there might be value in getting input from the broader
> community.
>
> Our geniwrapper module currently includes an aggregate manager (AM)
> that exports the slice interface -- there is (will be) an AM for
> PlanetLab,
> an AM for PlanetLab-Europe, an AM for PlanetLab-Japan, an AM for
> VINI, an AM for M-Lab, and so on.
>
> We then have a Slice Manager (SM) that is configured to know about
> a set of Aggregates. It currently runs as a server that happens to be
> co-located with the PlanetLab AM. A researcher, using his or her
> favorite
> interface (we currently support a Unix-command line program called
> SFI -- Slice Facility Interface) contacts the SM to create/control a
> slice.
> The SM, in turn, contacts one or more AMs carry out the requested
> operation. In a nutshell, the SM implements "deals with a slice that
> spans multiple aggregates" functionality.
>
> On the one hand, this SM is sort of like the GPO's Clearinghouse -- one
> stop shopping for all your slice needs. On the other hand, it has always
> been our expectation that there will be multiple SMs, that in the limit,
> each user is free to create his or her own private SM. As long as they
> have the credentials expected by a given AM, they are free to ask it to
> create a slice on their behalf.
>
> As we gain experience with the implementation, we are more and more
> coming to realize that there is little value in the shared (server-side)
> SM.
> That each user is better off running the SM-like functionality on his or
> her desktop. Each Aggregate announces and enforces its own peering
> policy, where the user queries the Registry to learn what Aggregates are
> available. The user is free to modify the SM (we assume plenty of open
> source SMs are available), and MOST IMPORTANTLY, we remove the
> burden of creating a one-size-fits-all SM (and a one-size-fits-all rspec
> that describes to that SM exactly what the user wants).
>
> One consequence of having client-side code know about multiple AMs
> is that this moves us away from a model where a Clearinghouse
> processes credentials on our behalf -- the AMs need to support the full
> credential-based authorization mechanism. (I believe this is the right
> thing to do in any case, but once you get the Clearinghouse out of the
> loop, I think you have to go down this path.)
>
> Anyone care to comment on the general issue of these competing
> strategies:
>
> User manages multiple Aggregates (SM functionality runs on client
> and user requests go directly to the aggregates)
>
> versus
>
> Clearinghouse manages multiple Aggregates (SM functionality runs
> on server with all user requested funneled through the SM)
>
> Larry
>
> _______________________________________________
> control-wg mailing list
> control-wg@...
> http://lists.geni.net/mailman/listinfo/control-wg
>
_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg
manages credentials so the AM doesn't have to...
So we have a set of functionality that can be bundled in
a clearinghouse (or not). They include (at least):
1) Credential manager (so aggregates don't have do deal
with credentials);
2) Resource manger (collects tickets from aggregates and
redistributes to users based on some allocation policy);
3) Aggregate aggregator (or virtual aggregate that "hides"
multiple aggregates behind a unified front-end); and
4) A slice manager (that offers users some nicer abstraction
than the "machine language" provided by the slice interface
and rspecs).
The geniwrapper implementation really only does (3), although
our arm is being twisted to do (1) as well. We don't do (2) -- each
individual aggregate makes resource allocation decisions on its
own behalf -- and we push (4) to the client front-end (currently a
set of Unix command line tools).
My original posting observed that practical issues suggest (3)
and (4) can be bundled and located on the client's desktop; and
that if you do this, (1) is orphaned (and personally, I don't see
why it's a big deal for an AM to decode and check a credential).
Larry
On Thu, Apr 16, 2009 at 2:06 PM, Schwab, Stephen
<Stephen.Schwab@...> wrote:
> Hi Larry,
> This is a very useful (and clear) message, so thank you for sending it.
>
> I think you may have painted too sharp of a contrast between doing
> things one-way-or-the-other.
>
> For example, the user's SM may sign some request and bundle with that
> request all the necessarily credentials and attributes to entail
> authorization of that request at an AM. But that doesn't mean there
> can't be a "clearinghouse-like broker" in the path. So the request
> would flow from:
>
> SM --> Clearinghouse broker --> AM.
>
> What would the Clearinghouse broker do? It might check the request
> itself, and then add an "endorsement" attribute to it, before forwarding
> it on to the AM. Nothing in the architecture restricts (or requires)
> this sort of thing -- but it would afford a place for "centralized
> policy" to be applied.
>
> Of course, the policy could be bypassed: if the AM wants to service
> requests that don't have a clearinghouse endorsement attribute, that is
> the AM's business. (And so the GENI environment would not be limited to
> one sort of AM that respected one centralized Clearinghouse policy.)
>
> I don't think there is much additional complexity in supporting this
> approach. Essentially a clearinghouse would just interpose, acting as a
> proxy w.r.t. the AM interface in this situation.
>
> --Steve
>
> -----Original Message-----
> From: control-wg-bounces@... [mailto:control-wg-bounces@...]
> On Behalf Of Larry Peterson
> Sent: Thursday, April 16, 2009 11:07 AM
> To: control-wg@...
> Subject: [cwg] clearinghouses (or not)
>
> We've recently been evaluating our approach to geniwrapper, and
> I thought there might be value in getting input from the broader
> community.
>
> Our geniwrapper module currently includes an aggregate manager (AM)
> that exports the slice interface -- there is (will be) an AM for
> PlanetLab,
> an AM for PlanetLab-Europe, an AM for PlanetLab-Japan, an AM for
> VINI, an AM for M-Lab, and so on.
>
> We then have a Slice Manager (SM) that is configured to know about
> a set of Aggregates. It currently runs as a server that happens to be
> co-located with the PlanetLab AM. A researcher, using his or her
> favorite
> interface (we currently support a Unix-command line program called
> SFI -- Slice Facility Interface) contacts the SM to create/control a
> slice.
> The SM, in turn, contacts one or more AMs carry out the requested
> operation. In a nutshell, the SM implements "deals with a slice that
> spans multiple aggregates" functionality.
>
> On the one hand, this SM is sort of like the GPO's Clearinghouse -- one
> stop shopping for all your slice needs. On the other hand, it has always
> been our expectation that there will be multiple SMs, that in the limit,
> each user is free to create his or her own private SM. As long as they
> have the credentials expected by a given AM, they are free to ask it to
> create a slice on their behalf.
>
> As we gain experience with the implementation, we are more and more
> coming to realize that there is little value in the shared (server-side)
> SM.
> That each user is better off running the SM-like functionality on his or
> her desktop. Each Aggregate announces and enforces its own peering
> policy, where the user queries the Registry to learn what Aggregates are
> available. The user is free to modify the SM (we assume plenty of open
> source SMs are available), and MOST IMPORTANTLY, we remove the
> burden of creating a one-size-fits-all SM (and a one-size-fits-all rspec
> that describes to that SM exactly what the user wants).
>
> One consequence of having client-side code know about multiple AMs
> is that this moves us away from a model where a Clearinghouse
> processes credentials on our behalf -- the AMs need to support the full
> credential-based authorization mechanism. (I believe this is the right
> thing to do in any case, but once you get the Clearinghouse out of the
> loop, I think you have to go down this path.)
>
> Anyone care to comment on the general issue of these competing
> strategies:
>
> User manages multiple Aggregates (SM functionality runs on client
> and user requests go directly to the aggregates)
>
> versus
>
> Clearinghouse manages multiple Aggregates (SM functionality runs
> on server with all user requested funneled through the SM)
>
> Larry
>
> _______________________________________________
> control-wg mailing list
> control-wg@...
> http://lists.geni.net/mailman/listinfo/control-wg
>
_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg
« Return to Thread: clearinghouses (or not)
| Free embeddable forum powered by Nabble | Forum Help |
