Re: questions on RSpecs from GEC2 meeting

I've tried to capture some of the thoughts that have come out of this
discussion in a new draft of the RSpec document (0.5), which I've
attached to the wiki here:
http://groups.geni.net/geni/wiki/GeniRspec

Comments (especially in the form of proposed edits to the document!) are
invited.

Here's the relevant new text:

----------
3.1     Low-level Component Description

The purpose of the RSpec is to describe substrate resources. It
describes resources that are manipulated at the "GENI layer"
(ie. by the GMC API). It does not describe the configuration of
resources above that layer. Expressed in another way, RSpec is intended
to describe the set of resources that a GENI user must invoke privileged
operations (via GMC calls) to obtain or configure. Once given a sliver,
the user has the ability to configure and/or program that sliver within
the bounds of the component's capabilities and the slicing
technology used on the component. The core RSpec is concerned with
describing these bounds, which are outside of a user's direct
control, not the contents of the sliver, which are under the control of
the user.

As a simple, concrete example, consider a component that is a sliced PC.
The RSpec for this PC would include the details of the PC's
processor, memory, disk, etc. It would also give the level of
abstraction provided by the slicing mechanism on this component; for
example, this might be a hypervisor-based virtual machine, giving the
user a virtual x86 PC on which the user may install an operating system,
or it may be kernel-based virtualization giving the user a virtual Linux
machine. The core RSpec for this component would not attempt to describe
the set of operating systems or applications that may be run on the
component; it is up to the user (possibly, with the help of some service
providing a repository of "standard GENI software components")
to decide what they choose to do with a virtual x86 machine or a virtual
Linux PC. If the IP (or other protocol) stack on the component is not
fixed, but user-replaceable, it is not in the scope of the core RSpec.
----------
3.2.1   Standardization of RSpec Extensions

Entities contributing components and other resources to GENI will have
the flexibility to define their own extensions to RSpec, and to use
these extensions in a limited fashion without formal standardization.
Such non-standard extensions will be confined to a special namespace.
If an extension proves useful, and of interest to at least some subset
of the GENI community, it should go through a standardization process,
to be defined by the Control Framework Working Group, so that its
semantics and meaning are well-defined and well-understood, and it may
be used in an interoperable fashion. The result of this process with be
a "standard extension".

It is expected that, as components with new technologies are introduced
into GENI, the RSpec extensions used to describe them will begin as
"private" extensions used by the component developers and
operators, and become standardized as those components become suitable
and available for wider use.
----------
3.5     Limits to the Scope of RSpec

While RSpec is designed to be extensible, its purpose remains the
description, at a low level, of GENI substrate resources. This does not
preclude services that choose to operate at a higher level of
abstraction; we limit the RSpec to its original scope by allowing such
services to use their own resource descriptions.
The fundamental goal of the GMC API is interoperability between the
various parts of GENI. Thus, parameters to standard GMC API calls that
describe resources will all be given in RSpec. APIs, however, that
individual services choose to implement, but that are not part of the
GMC, may use RSpec, but are not required to do so. Slice embedding
services, for example, that wish to allow users to describe topologies
in ways that are higher-level and more flexible than those permitted by
RSpec may chose to do so using domain-specific languages. When they
interact with component managers or other GMC entities, however, the
will do so using RSpec.
----------

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

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