| 1 | |
| 2 | This working group is the focal point for defining the interfaces, |
| 3 | services, and tools supported by the GENI facility. |
| 4 | |
| 5 | Our most important goal in this working group is to guide the design |
| 6 | of the essential services that will make the facility easy and |
| 7 | productive for researchers to use. The workflow stages for |
| 8 | researchers include defining and acquiring a slice, configuring the |
| 9 | slice for an experiment, assembling and launching the software used in |
| 10 | the experiment, monitoring and controlling the experiment as it runs, |
| 11 | collecting and archiving experiment results, and storing and sharing |
| 12 | experiment building blocks and configurations. |
| 13 | |
| 14 | A second goal of the working group is to cultivate extensions to the |
| 15 | GENI core services ("let a thousand flowers bloom"). GENI will |
| 16 | provide an open and extensible software base of optional components |
| 17 | that researchers may select and combine for their experiments within |
| 18 | GENI. This working group will identify opportunities to leverage |
| 19 | useful technology pieces from outside of the core GENI effort and |
| 20 | incorporate them for use with GENI. |
| 21 | |
| 22 | == Issues for the March Meeting == |
| 23 | |
| 24 | At the March 3-4 meeting we want to focus on three broad questions: |
| 25 | |
| 26 | 1. ''How shall we rework the subgroups to focus on the services that |
| 27 | are important and hard and must be part of the core facility |
| 28 | planning?'' That means agreeing on the priority list for services, |
| 29 | distinguishing the essential services from the extensions, and |
| 30 | refactoring subgroups to address the essential services and extension |
| 31 | interfaces. |
| 32 | |
| 33 | 2. ''What requirements should we communicate to the other working |
| 34 | groups?'' For example, collection of experiment data will involve |
| 35 | monitoring interfaces driven by the substrate WG. And the slice |
| 36 | control services will place specific demands on the facility control |
| 37 | WG. |
| 38 | |
| 39 | 3. ''What aspects of the previous WG output should be revisited?'' In |
| 40 | this phase of GENI, we are using the output of the "design phase" |
| 41 | working groups as a starting point. But nothing is cast in stone. |
| 42 | We now have a new working group structure, and an opportunity to |
| 43 | revisit some of the earlier choices before prototyping activities |
| 44 | begin. What was decided that should be reconsidered? What is |
| 45 | started but not yet finished? |
| 46 | |
| 47 | == Subgroups for Essential Services == |
| 48 | |
| 49 | We had a good discussion of the priority list of services at the |
| 50 | October07 meeting. Any service that we consider should flow directly |
| 51 | from the usage scenarios. Aaron Falk and others at BBN have put |
| 52 | together a fairly complete usage scenario for a GENI experiment. |
| 53 | Peter Steenkiste contributed some text for a wireless scenario with |
| 54 | realistic mobility, and Marco Ruffini and Donal O'Mahony contributed |
| 55 | some text for an optical usage scenario. |
| 56 | |
| 57 | Here is a straw man proposal for a new subgroup structure reflecting a |
| 58 | a rough functional grouping of the important services. Of course |
| 59 | they should all be open and extensible so the system can grow |
| 60 | organically. We can discuss what is "essential" and what is "extension" |
| 61 | within each subgroup. Each subgroup also involves |
| 62 | linkages with other WGs. |
| 63 | |
| 64 | * '''Slices'''. Programmatic control/orchestration for GENI experiments. |
| 65 | Specifying, discoverying, allocating, and configuring end-to-end |
| 66 | resources for a slice. Also deals with issues of slice visibility, |
| 67 | containment, and reach. |
| 68 | |
| 69 | * '''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? |
| 70 | |
| 71 | * '''Building Blocks'''. GENI will have an artifact repository for software |
| 72 | packages, standard data sets, workloads, faultloads, etc. How can |
| 73 | we make it easy for researchers to combine components into a |
| 74 | complete configuration, provision a slice for the experiment, and |
| 75 | assemble tool chains to process the data? In scope: packaging |
| 76 | formats, virtual appliances, validating/certifying configurations, |
| 77 | artifact rankings/reputation. |
| 78 | |
| 79 | * '''FDR'''. Faults, Diagnosis, and Repair. Fault injection for running |
| 80 | experiments, fault detection and reporting, slice repair, |
| 81 | snapshot/restart, suspend/resume, invariant checking, event logging. |
| 82 | |
| 83 | === Cross-cutting Issues === |
| 84 | |
| 85 | There are several cross-cutting issues that will engage all of the |
| 86 | subgroups. These could be (and have been) an alternative basis for |
| 87 | organizing subgroups, rather than organizing them along major |
| 88 | functional groupings. Here are some of the important cross-cutting |
| 89 | issues: |
| 90 | |
| 91 | * Representations of slices as combinations of resource types and |
| 92 | locations, artifacts, and configurations. |
| 93 | |
| 94 | * Storage. The proposed subgroup structure separates the various uses |
| 95 | of storage for independent consideration, e.g., artifact |
| 96 | repositories, snapshots, instrumentation data, and local scratch |
| 97 | storage for virtual machines. The idea here is to focus on the |
| 98 | higher-level services and their representations, on the premise that |
| 99 | we can build these essential services (and many other extensions) |
| 100 | above a sliverable raw storage substrate. |
| 101 | |
| 102 | * Security. All users of the core GENI services will have strong |
| 103 | identities endorsed keypairs as the foundations of a security |
| 104 | architecture. We can consider issues of trust management and |
| 105 | authorization in the context of each high-level service. |
| 106 | |
| 107 | * Other: incentives, configuration scripting, naming, etc., etc. |
| 108 | |