onward to GEC3

With the GENI Spiral 1 prototype contracts out, this working group will
be a forum to reconcile various views of the researcher interfaces to
GENI, and the toolsets to extend those interfaces.

Also, we now have a systems engineer supporting the Experiment Services
and Workflow WG: Vic Thomas (see bio below). Among other things, Vic has
been working on the usage scenarios document, a "taxonomy" of researcher
tools and services, and the schedule for the upcoming GEC3. He will also
be working on the security architecture for GENI, which cuts across all
of the working groups.

For the usage scenarios and taxonomy documents, the goal is to trace the
end-to-end "life cycle" of a few specific experiment examples in depth,
in order to flesh out the tools and services needed to support those
examples.

Most of the Spiral 1 projects are built around some ideas about what
those are. So please feel free to send or post your ideas for the most
illuminating usage scenarios and/or the important tools/services to
support them.

In particular, I propose we focus the GEC3 discussions around the Spiral
1 services and interfaces for the first three of the subareas identified
at GEC2:

1. Slice control. The Spiral 1 projects include several efforts to build
controller servers and related tools that run on behalf of a researcher
to construct, deploy, monitor, and adapt slices. The GENI architecture
does not define this entity, but I propose we call them "slice
controllers". They run outside of the slice and do their work by
invoking clearinghouse, component managers, etc. GUSH and Stork in
Cluster B are two notable examples, and Cluster D uses the Orca "guest
controller". What about Cluster A (Deter) and C (ProtoGENI)?

In general, for such tools, how does a user specify an experiment? How
does a user program the slice controller? What other services does a
slice controller interact with? What are their interfaces? What are the
requirements for the control plane interfaces used by the slice controller?

2. Information plane. Several of the Spiral 1 projects deal directly
with instrumentation services for specific groups of components. How
will researchers or slice controllers specify the instrumentation data
they want to collect? How/where will it be stored and made available to
the researcher? How much processing/analysis occurs as the experiment
runs? What tools and interfaces are needed for post-processing? What
data formats will those tools assume?

3. Building blocks. How does a researcher or slice controller specify
the code that will run in the programmable slivers in the slice? How are
code artifacts stored for reuse and sharing with other researchers? How
are they named, typed, certified, rated, etc.? How are they delivered to
the slivers for deployment? What constraints do code artifacts place on
the slivers? How is a sliver "qualified" to run a code artifact?

Clearly there are tight relationships among these three subareas.

I invite representatives of the various Spiral 1 projects, or anyone
else, to chime in here on these questions or others we should focus on
at this stage.

Jeff



Dr. Vicraj (Vic) Thomas expertise lies in the area of highly-dependable
systems, distributed systems protocols and architectures and wireless
sensor networks. Before joining BBN Technologies he was with the
Honeywell Laboratories where he developed technologies related to
wireless networks for flight-essential avionics applications and to the
assessment of the quality of information from sensor networks. Dr.
Thomas was the Industrial Technology Area Leader for the sensors
research area within the US-UK International Technology Alliance (ITA)
program. He has helped define the research area related to the
assessment of the quality of information from sensor networks and will
be co-chairing a workshop on this topic in conjunction with the Mobile
Ad-Hoc Sensors and Systems (MASS) conference. He was the PI for
Honeywell’s DARPA NEST and Ultra*Log projects and was proposal lead for
the Honeywell DARPA CyberPanel project that led to the development of a
very successful aggregator of alerts from intrusion detection systems.
As part of this project he made technical contributions to the IETF
Intrusion Detection Working Group. He has also a systems architect on
the NASA C3I network for the Orion program and a member of the
architecture team responsible for the design of the Boeing FCS SOSCOE
system (middleware for the FCS system of systems). He was the lead
software architect for a NIST funded effort that developed a large
distributed collaboration system for operators in industrial process
control plants. Dr. Thomas has been invited to speak at workshops
including the NSF/Japan Society for the Promotion of Science Workshop on
Sensors, Smart Structures and Mechatronic Systems (Tokyo 2005), the EU
Workshop on Next Generation Sensor Actuator Systems (Edinburg 2007) and
the International Workshop on Cyber-Physical Systems Challenges and
Applications (Santorini 2008).



_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg