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. A description of an Emulab sufficient for the federation system to create a sub experiment on it. Note that fedAttrs provide an extension mechanism by which testbeds may communicate additional information and preferences to federation systems that understand it. 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 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. 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 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 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. The description of the federated experiment, in extended ns2. Known subexperiment interconnection mechanisms 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 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, the access keys to be used in the subsequent instantiation and service use, an allocation ID to identify this access in later requests, 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. Naming and Emulab instantiation information about a federant. This is returned by various informational requests and as part of a successful creation message. 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 to run the CEDL splitter remotely. This is primarily an internal interface. Remote splitter output. Also an internal interface 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.