wiki:GeniServices/mar08/index.html

Version 8 (modified by chase@cs.duke.edu, 16 years ago) (diff)

--

Focus of the Working Group

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.
  1. 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.
  1. 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. See the Usage drafts page.

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 (measurement plane), 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.

Tendrils to Other Working Groups