An ID is an identifier for a principal, service, or object. This type
is currently polymorphic o allow different implementations of type,
though running code primarily uses localnames and fedids.
A description of the project used to access a testbed. Includes
the testbed being accessed, the project name (often a local
name, scoped by the testbed), and any users who have been
granted access or for whom access is being requested.
The information needed to create a dynamic project, specifically
a project description and the resources in needs access to.
This is used by an internal fedd interface.
A node from an Emulab. It may have 0 or more images or hardware
types associated with it. As this description is used for
acquiring access to the testbed in question, multiple images or
types are considered options. Specifying multiple image names
indicates that the requester is looking for support for any of
them.
A strawman network capacity description for access negotiation.
This will come to include more and more interesting parameters.
This defines the role the user/account is playing in the
federated experiment. An account being accessed by the
federation system to create the experiment is in the
experimentCreation role and the accounts that experimenters will
use to access local testbed services (e.g., rebooting a local
node) are serviceAccess roles.
An indication of how requested networking capacity is measured.
This will undoubtably expand.
The definition of a user principal. It includes the
identification of the user as an ID type, the access credential(s)
that the user will use, and the role of the user, if any.
Multiple access keys may be used, and it is also possible for
the user to be anonymous. Though it is possible to specify a
user without ID, access, or role, it is difficult to imagine
such a user being useful.
A proof or partial proof of access rights
The current state of the experiment.
This captures an access credential that will be used to access
resources. These are certificates or public keys. The type is
used to designate the key to which access should be bound, or on
a reply has been bound. Dynamic credentials where new keys have
been created may also be passed in this kind of field.
A general attribute/value pair for passing federation parameters and
preferences. Anything encodable in XML is allowed. This is a
point for customization and extension.
The estimate of resources a requester is looking for, or the
response of a testbed indicating what it can provide. This is
something of a placeholder for a full resource specification,
and alternative encodings are likely to be imported.
Explicit translation of testbed attribute in a federated experiment
description to the URI at which the controlling federation
system can be reached. Used in a creation request.
This type allows tools to encode experiments in familiar local
names for experimenters while providing remote federation
systems the information to map the local name into a service
location.
Node in the virtual topology of a federated experiment (Emulab
legacy). The fields are the local hostname and the IP addresses
of the experimental interfaces(colon-separated).
LAN in the virtual topology of a federated experiment (Emulab legacy).
The fields are the name of the LAN/link (vname) the node that
this description applies to (vnode), the IP of the connection,
and performance information.
The virtual topology of a federated experiment (Emulab legacy).
Node in the visualization of a federated experiment (Emulab
legacy). Fields include the local hostname of the node, x,y
coordinates in a 2-dimensional representation, and whether the
node in the visualization is a host or a LAN.
The visualization of a federated experiment (Emulab legacy)
The description of the federated experiment, in extended ns2.
Known subexperiment interconnection mechanisms
A member of a set of nodes for which transit is being provided
Connection parameter types: input or output
This is a parameter on which two or more access controllers have to
agree in order to complete the stitching. This gives the name of the
parameter, the key under which to store it (or it has been stored) and
whether it is to be input or output.
The information needed to stitch together two segments. It is both
exported from the nmaster and reported by the experiment controller to
the access controller and by the access controller into the world.
A generic service entry, basically a name and server
The global descriptions of services in the creation request. These
indicate which services are being provided at a testbed level. They
become service info requests in segment creation.
Request for an experiment to which credentials can be delegated and
resources attached. A local name may be included as a human readable
accessor, local to this experiment controller. It is a suggestion and
may be modified. experimentID can only be a local name.
Credentials are seed credentials to begin the proof.
Result of a new experiment creation. A successful sreation will have
an experimentState of "empty", 2 experimentIDs, one a fedid and one a
local name, and an experimentAccess that allows the creator to act as
the experiment.
Request for access to a testbed. It includes the testbed from
which resources are being requested (a single service may
provide access to many), the user or project requesting access
(a testbed making the request will leave both empty), the
resources needed, and scheduling information.
Response to an access request. Includes the allocation, the
information needed to access creation and experiment services
and scheduling information.
A request to release the access rights allocated by an earlier
RequestAccess call.
Indication that the access has been terminated.
A request to embed a federated experiment across testbeds. Non-
standard local names for testbeds are included in the
testbedmap, the user making the request, the experiment
description, master testbed, and a suggested experiment name are
included. More than one name can be suggested, either as
synonyms (a fedid and a localname) or as choices (multiple
localnames).
Returned to let the caller know that the request is underway.
Request for an existing experiment's virtual topology.
Different information may be returned based on the user's rights
to see the topology.
The response to a topology request. Different information may
be returned based on the user's rights to see the topology.
Request for an existing experiment's visualization. This is
largely a compatibility service. Different information may be
returned based on the user's rights to see the topology.
An existing experiment's visualization. This is largely a
compatibility service. Different information may be returned
based on the user's rights to see the topology.
A combined topology, visualalization, and federant request.
Different information may be returned based on the user's rights
to see the topology.
Information on an instantiated experiment. Different information may
be returned based on the user's rights to see the topology. Includes
the information about federants hosting sub-experiments for service
access as well as virtual topology and visualization information. All
that information is relative to the requester. ExperimentAccess
includes credentials with which one can access the experiment. These
may include a public key necessary to prove possession of the
credential and should be treated with care.
Gets all information that this user can access on this fedd.
Multi info response. A list of infoResponses
Request to terminate an experiment.
Indication that the experiment has been terminated.
Request a testbed to create a segment in the given allocation
Indication that the segment started successfully
Request to terminate an experiment.
Indication that the experiment has been terminated.
Request current status of the segment
Current status of the allocation
Request to run the CEDL to topdl translator remotely. This is
primarily an internal interface.
Translator splitter output. Also an internal interface
Request to set a shared value.
Request to set a shared value.
Request to set a shared value.
Request to set a shared value.
Indication that a service has failed. The code values are
1 access denied
2 proxy error
3 badly formed request
4 server configuration error
5 internal error
6 partial instantiation
7 federant error
Errstr contains the text above corresponding to the code. Code
is always present. Desc provides additional human-readable data
about the error.