« Return to Thread: CF Requirements: 3) Slice Controller
Re: CF Requirements: 3) Slice Controller
by Jeff Chase
::
Rate this Message:
Harry asked me to kick off this discussion, so I'll do that by summarizing my views on the discussion questions he asked about "slice controller". The slice controller corresponds to what we have called "guest controller" or "service manager" in the Orca work and its predecessors (Shirako and SHARP).
Q1: Is the "slice controller" always required in a GENI suite?
I suggest we use the term "slice controller" (SC) for any entity that speaks control plane protocol in the role of an "experimenter". That is, a "slice controller" is any entity that issues resource discovery requests to a Clearinghouse (CH), or requests tickets from a CH broker service, or presents tickets to a component/aggregate manager (AM), etc.
So then the question becomes: what is the nature of the SC, i.e., what can/must the other control plane actors assume about an SC? What qualifies as an SC? SC could (or should) be a researcher-replaceable (or customizable) entity, so only the researcher trusts it. No other part of the system trusts it to maintain hard state or to do anything other than make requests on behalf of the researcher. However, SC is permitted (but not required) to register and serve callback interfaces for status notifications and the like. For this reason we generally presume there is exactly one SC per slice (although one SC could control many slices). I think this accommodation of callbacks to the SC is the only substantive change being proposed here by introducing an SC to flesh out the generic concept of "experiment control tools".
That's a pretty minimal set of assumptions, and it would accommodate a wide range of implementations to play the role of "slice controller" in the control framework. It could be a standalone program that a researcher runs, or it could reside within a web server operated by the testbed or a participating institution. In Orca/Shirako it can be either of these things---same code.
So my answer would be yes, SC is always required, unless we decide to introduce more terms to distinguish among different flavors of what I am calling SC.
Q2: Must the "slice controller" be persistent?
It is helpful for the SC to be persistent, and in Orca/Shirako it is persistent, but if it fails permanently or forgets its state, then it does not harm the system. Except in one way: the resources it has allocated are not reclaimed until their leases expire.
Q3: Should the slice controller typically represent one researcher? One
research organization? Or?
The SC operates on behalf of a slice owner, whatever that is. In our code today it is limited to operate on behalf of one user, but it should not be architecturally limited in that way.
Q4: Is it important to specify where it is located?
No, but it has to be reachable through the GENI control network, e.g., the public Internet.
Q5: Do we need to define the interface between the slice controller and
the researcher?
"Let a thousand flowers bloom."
Q6: How does the "slice controller" present a "trust assertion" to an
aggregate?
The SC holds one or more private keys and it wields credentials anchored in some identity provider to endorse its corresponding public keys. The credential could be a PKI/509 cert and/or something else...but that is an orthogonal set of questions.
Jeff
Harry Mussman wrote:
> GENI Control Framework WG Members, interested GENI participants, and
> Jeff Chase of Duke,
>
>
> A first DRAFT (v01.3) of the GENI Control Framework Requirements
> document has been completed, and can be found at
> http://groups.geni.net/geni/wiki/GeniControlFrameworkRequirements
>
> A discussion of the document on February 25, 2009 resulted in the
> identification of 10 discussion items, which can be found at
> http://groups.geni.net/geni/attachment/wiki/GeniControlFrameworkRequir
> ements/030609_CFRequireReviewTopics.pdf
>
>
>
> This email begins a discussion thread on: 3) Slice Controller
>
> I would like to invite Jeff Chase of Duke to begin the discussion, and
> then others are invited to join in.
>
>
>
> 2a) During the discussion, the key elements in a GENI suite were
> discussed, including the "triangle" of Researcher, Aggregate (with
> Components) and Clearinghouse.
>
> In his detailed comments for the document, Jeff suggested that a
> "Slice Controller" should become a first-class entity (element),
> associated with the researcher, that controls and monitors a slice.
> Jeff defined "first class" to mean that it is persistent, so that
> other actors in the control framework, or slivers in its slice, can
> send unsolicited messages/notifications to it. And, it may respond by
> taking autonomous actions to control the slice on behalf of an
> experimenter.
> Harry noted that this is in keeping with the current PlanetLab, the
> ProtoGENI and ORCA prototypes.
>
> 2b) The current DRAFT talks of:
> "A principal acting from a server utilizing a browser client or a set
> of helper tools". So, there is talk of a "server' and "helper tools",
> but no slice controller.
>
> 2c) Discussion:
> All of the current prototype implementations include some form of
> "slice controller" (or slice manager).
> In PlanetLab, it is part of PLC.
> In ProtoGENI, it is associated with the Researcher.
> In ORCA, it is called the Slice Manager.
> All hold state specifying the slice.
>
> 2d) A proposed change to the CF requirements:
> Each suite includes one or more Slice Controllers
> (this must also be reflected in the GENI System Overview)
>
> Each slice controller:
> Associated with one (or more) researchers.
> Trusted to properly represent the researcher(s)
>
> "First class" entity
> Persistent, so that other actors in the control framework, or slivers
> in its slice, can send unsolicited messages/notifications to it.
>
> Interacts with clearinghouse and aggregates.
> Discovers, plans, requests, acquires, and controls resources from
> aggregates.
> Keeps state.
> If gets firm reservations, it keeps a calendar of committed resources.
>
> 2e) Continued discussion:
> Is the "slice controller" always required in a GENI suite?
> Must the "slice controller" be persistent?
> Should the slice controller typically represent one researcher? One
> research organization? Or?
> Is it important to specify where it is located?
> Do we need to define the interface between the slice controller and
> the researcher?
> How does the "slice controller" present a "trust assertion" to an
> aggregate?
>
>
>
> We look forward to a continuing, lively discussion, working towards a
> 'rough consensus".
>
> Harry E. Mussman
> Control Framework Systems Engineer
>
> GENI Project Office
> BBN Technologies
> 10 Moulton Street
> Cambridge, MA 02138
> (617) 873-4282 - Office
> (781) 266-8479 - Mobile
> (617) 873-4888 - Fax
> hmussman@...
> www.bbn.com
>
>
_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg
Q1: Is the "slice controller" always required in a GENI suite?
I suggest we use the term "slice controller" (SC) for any entity that speaks control plane protocol in the role of an "experimenter". That is, a "slice controller" is any entity that issues resource discovery requests to a Clearinghouse (CH), or requests tickets from a CH broker service, or presents tickets to a component/aggregate manager (AM), etc.
So then the question becomes: what is the nature of the SC, i.e., what can/must the other control plane actors assume about an SC? What qualifies as an SC? SC could (or should) be a researcher-replaceable (or customizable) entity, so only the researcher trusts it. No other part of the system trusts it to maintain hard state or to do anything other than make requests on behalf of the researcher. However, SC is permitted (but not required) to register and serve callback interfaces for status notifications and the like. For this reason we generally presume there is exactly one SC per slice (although one SC could control many slices). I think this accommodation of callbacks to the SC is the only substantive change being proposed here by introducing an SC to flesh out the generic concept of "experiment control tools".
That's a pretty minimal set of assumptions, and it would accommodate a wide range of implementations to play the role of "slice controller" in the control framework. It could be a standalone program that a researcher runs, or it could reside within a web server operated by the testbed or a participating institution. In Orca/Shirako it can be either of these things---same code.
So my answer would be yes, SC is always required, unless we decide to introduce more terms to distinguish among different flavors of what I am calling SC.
Q2: Must the "slice controller" be persistent?
It is helpful for the SC to be persistent, and in Orca/Shirako it is persistent, but if it fails permanently or forgets its state, then it does not harm the system. Except in one way: the resources it has allocated are not reclaimed until their leases expire.
Q3: Should the slice controller typically represent one researcher? One
research organization? Or?
The SC operates on behalf of a slice owner, whatever that is. In our code today it is limited to operate on behalf of one user, but it should not be architecturally limited in that way.
Q4: Is it important to specify where it is located?
No, but it has to be reachable through the GENI control network, e.g., the public Internet.
Q5: Do we need to define the interface between the slice controller and
the researcher?
"Let a thousand flowers bloom."
Q6: How does the "slice controller" present a "trust assertion" to an
aggregate?
The SC holds one or more private keys and it wields credentials anchored in some identity provider to endorse its corresponding public keys. The credential could be a PKI/509 cert and/or something else...but that is an orthogonal set of questions.
Jeff
Harry Mussman wrote:
> GENI Control Framework WG Members, interested GENI participants, and
> Jeff Chase of Duke,
>
>
> A first DRAFT (v01.3) of the GENI Control Framework Requirements
> document has been completed, and can be found at
> http://groups.geni.net/geni/wiki/GeniControlFrameworkRequirements
>
> A discussion of the document on February 25, 2009 resulted in the
> identification of 10 discussion items, which can be found at
> http://groups.geni.net/geni/attachment/wiki/GeniControlFrameworkRequir
> ements/030609_CFRequireReviewTopics.pdf
>
>
>
> This email begins a discussion thread on: 3) Slice Controller
>
> I would like to invite Jeff Chase of Duke to begin the discussion, and
> then others are invited to join in.
>
>
>
> 2a) During the discussion, the key elements in a GENI suite were
> discussed, including the "triangle" of Researcher, Aggregate (with
> Components) and Clearinghouse.
>
> In his detailed comments for the document, Jeff suggested that a
> "Slice Controller" should become a first-class entity (element),
> associated with the researcher, that controls and monitors a slice.
> Jeff defined "first class" to mean that it is persistent, so that
> other actors in the control framework, or slivers in its slice, can
> send unsolicited messages/notifications to it. And, it may respond by
> taking autonomous actions to control the slice on behalf of an
> experimenter.
> Harry noted that this is in keeping with the current PlanetLab, the
> ProtoGENI and ORCA prototypes.
>
> 2b) The current DRAFT talks of:
> "A principal acting from a server utilizing a browser client or a set
> of helper tools". So, there is talk of a "server' and "helper tools",
> but no slice controller.
>
> 2c) Discussion:
> All of the current prototype implementations include some form of
> "slice controller" (or slice manager).
> In PlanetLab, it is part of PLC.
> In ProtoGENI, it is associated with the Researcher.
> In ORCA, it is called the Slice Manager.
> All hold state specifying the slice.
>
> 2d) A proposed change to the CF requirements:
> Each suite includes one or more Slice Controllers
> (this must also be reflected in the GENI System Overview)
>
> Each slice controller:
> Associated with one (or more) researchers.
> Trusted to properly represent the researcher(s)
>
> "First class" entity
> Persistent, so that other actors in the control framework, or slivers
> in its slice, can send unsolicited messages/notifications to it.
>
> Interacts with clearinghouse and aggregates.
> Discovers, plans, requests, acquires, and controls resources from
> aggregates.
> Keeps state.
> If gets firm reservations, it keeps a calendar of committed resources.
>
> 2e) Continued discussion:
> Is the "slice controller" always required in a GENI suite?
> Must the "slice controller" be persistent?
> Should the slice controller typically represent one researcher? One
> research organization? Or?
> Is it important to specify where it is located?
> Do we need to define the interface between the slice controller and
> the researcher?
> How does the "slice controller" present a "trust assertion" to an
> aggregate?
>
>
>
> We look forward to a continuing, lively discussion, working towards a
> 'rough consensus".
>
> Harry E. Mussman
> Control Framework Systems Engineer
>
> GENI Project Office
> BBN Technologies
> 10 Moulton Street
> Cambridge, MA 02138
> (617) 873-4282 - Office
> (781) 266-8479 - Mobile
> (617) 873-4888 - Fax
> hmussman@...
> www.bbn.com
>
>
_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg
« Return to Thread: CF Requirements: 3) Slice Controller
| Free embeddable forum powered by Nabble | Forum Help |
