Changes between Initial Version and Version 1 of GeniServices/mar08/index.html

Timestamp:

02/29/08 13:05:09 (16 years ago)

Author:

chase@cs.duke.edu

Comment:

--

GeniServices/mar08/index.html

@@ +1 @@
+
+This working group is the focal point for defining the interfaces,
+services, and tools supported by the GENI facility.
+
+Our most important goal in this working group is to guide the design
+of the essential services that will make the facility easy and
+productive for researchers to use.  The workflow stages for
+researchers include defining and acquiring a slice, configuring the
+slice for an experiment, assembling and launching the software used in
+the experiment, monitoring and controlling the experiment as it runs,
+collecting and archiving experiment results, and storing and sharing
+experiment building blocks and configurations.
+
+A second goal of the working group is to cultivate extensions to the
+GENI core services ("let a thousand flowers bloom").  GENI will
+provide an open and extensible software base of optional components
+that researchers may select and combine for their experiments within
+GENI.  This working group will identify opportunities to leverage
+useful technology pieces from outside of the core GENI effort and
+incorporate them for use with GENI.
+
+== Issues for the March Meeting ==
+
+At the March 3-4 meeting we want to focus on three broad questions:
+
+ 1.  ''How shall we rework the subgroups to focus on the services that
+ are important and hard and must be part of the core facility
+ planning?''  That means agreeing on the priority list for services,
+ distinguishing the essential services from the extensions, and
+ refactoring subgroups to address the essential services and extension
+ interfaces.
+
+ 2. ''What requirements should we communicate to the other working
+ groups?''  For example, collection of experiment data will involve
+ monitoring interfaces driven by the substrate WG.  And the slice
+ control services will place specific demands on the facility control
+ WG.
+
+ 3. ''What aspects of the previous WG output should be revisited?''  In
+ this phase of GENI, we are using the output of the "design phase"
+ working groups as a starting point.  But nothing is cast in stone.
+ We now have a new working group structure, and an opportunity to
+ revisit some of the earlier choices before prototyping activities
+ begin.  What was decided that should be reconsidered?  What is
+ started but not yet finished?
+
+== Subgroups for Essential Services ==
+
+We had a good discussion of the priority list of services at the
+October07 meeting.  Any service that we consider should flow directly
+from the usage scenarios.  Aaron Falk and others at BBN have put
+together a fairly complete usage scenario for a GENI experiment.
+Peter Steenkiste contributed some text for a wireless scenario with
+realistic mobility, and Marco Ruffini and Donal O'Mahony contributed
+some text for an optical usage scenario.
+
+Here is a straw man proposal for a new subgroup structure reflecting a
+a rough functional grouping of the important services.  Of course
+they should all be open and extensible so the system can grow
+organically.    We can discuss what is "essential" and what is "extension"
+within each subgroup.  Each subgroup also involves 
+linkages with other WGs.
+
+ * '''Slices'''.  Programmatic control/orchestration for GENI experiments.
+   Specifying, discoverying, allocating, and configuring end-to-end
+   resources for a slice.  Also deals with issues of slice visibility,
+   containment, and reach.
+
+ * '''Information Plane'''.  The focus here is on monitoring and instrumentation of a slice, but it will be useful to consider it in the larger context.  What can an experimenter (or a facility monitor) know about a slice?  Includes time and space issues, e.g., geographic localization, topology.  What facilities are offered to collect and process data from an experiment?
+
+ * '''Building Blocks'''.  GENI will have an artifact repository for software
+   packages, standard data sets, workloads, faultloads, etc.  How can
+   we make it easy for researchers to combine components into a
+   complete configuration, provision a slice for the experiment, and
+   assemble tool chains to process the data?  In scope: packaging
+   formats, virtual appliances, validating/certifying configurations,
+   artifact rankings/reputation.
+
+ * '''FDR'''.  Faults, Diagnosis, and Repair.  Fault injection for running
+  experiments, fault detection and reporting, slice repair,
+  snapshot/restart, suspend/resume, invariant checking, event logging.
+
+=== Cross-cutting Issues ===
+
+There are several cross-cutting issues that will engage all of the
+subgroups.  These could be (and have been) an alternative basis for
+organizing subgroups, rather than organizing them along major
+functional groupings.  Here are some of the important cross-cutting
+issues:
+
+ * Representations of slices as combinations of resource types and
+ locations, artifacts, and configurations.
+
+ * Storage.  The proposed subgroup structure separates the various uses
+ of storage for independent consideration, e.g., artifact
+ repositories, snapshots, instrumentation data, and local scratch
+ storage for virtual machines.  The idea here is to focus on the
+ higher-level services and their representations, on the premise that
+ we can build these essential services (and many other extensions)
+ above a sliverable raw storage substrate.
+
+ * Security.  All users of the core GENI services will have strong
+ identities endorsed keypairs as the foundations of a security
+ architecture.  We can consider issues of trust management and
+ authorization in the context of each high-level service.
+
+ * Other: incentives, configuration scripting, naming, etc., etc.
+