GENI AM API and GENI RSpecs
GENI Experimenter Workflow
|This page introduces:
A project organizes research in GENI, containing both people and their experiments. A project is created and led by a single responsible individual: the Project Lead. A project may have many experimenters as its members and an experimenter may be a member of many projects. The Project Lead is ultimately accountable for all actions by project members in the context of the project. GENI experimenters must have Project Lead privileges to create projects. Only faculty and senior members of an organization can be project leads (e.g. students cannot be project leads).
The following figure illustrates a situation where a professor is the Lead for two GENI projects, one that he uses for his research project Hactar and the other for the networking class CS404 he is teaching . Members of the project Hactar are the professor’s research assistant and his post-doc. Members of the project CS404 are the teaching assistant for CS404 and all the students in the class. The professor gives his teaching assistant administrative privileges to Project CS404 so the assistant is able to add students to the project or remove them.
For more information on Project Roles/privileges, see here.
GENI is a shared testbed i.e. multiple experimenters may be running multiple experiments at the same time. This is possible because of the concept of a slice. A GENI slice is:
The following figure shows two slices created by the research assistant in Project Hactar. He has added to Slice 1 three compute resources connected by three network links. He has also added the post-doc associated with his project as a member of the slice. His professor was automatically added to the slice as he is the Project Lead. Slice 2 has two compute resources connected by a link. He has not added the post-doc as a member of this slice and so she cannot perform any actions on this slice or even view the resources in this slice. An experiment in Slice 1 can only use resources in Slice 1 and an experiment in Slice 2 can only use resources in Slice 2.
For more information on Slice Roles/privileges, see here.
A GENI aggregate provides resources to GENI experimenters. For example, a GENI Rack at a university is an aggregate; GENI experimenters may request resources from this aggregate and add them to their slice. Different aggregates provide different kinds of resources. Some aggregates provide compute resources: Virtual Machines or “bare machines” or both. Some aggregates provide networking resources that experimenters can use to connect compute resources from multiple aggregates. The figure below shows a GENI slice with resources from multiple aggregates.
The GENI AM API and GENI RSpecs
Experimenters request resources from aggregates using a standard API called the GENI Aggregate Manager API or GENI AM API. The AM API allows experimenters to, among other things:
The AM API uses resource specification documents, commonly referred to as GENI RSpecs, to describe resources. RSpecs are just XML documents in a prescribed format. Experimenters send to aggregates a request RSpec that describes the resources they want and get back from the aggregates a manifest RSpec that describes the resources they got. The manifest includes information the experimenters will need to use these resources such as the names and IP addresses of compute resources (e.g. virtual machines), user accounts created on the resources and VLAN tags assigned to network links. Most experimenters will not need to learn details of the AM API or read/write RSpec files; GENI experimenter tools hide much of this complexity.
There is a third type of RSpec called an advertisement RSpec. This is the RSpec returned by an aggregate when an experimenter lists the resources available at the aggregate. It describes all the resources available at the aggregate.
The figure below shows an experimenter adding resources from two different aggregates to her slice using the Allocate call of the GENI AM API.
Getting Access to GENI and GENI Resources
Experimenters need an account to use GENI and can get an account from any one of GENI’s federated authorities called clearinghouses. Commonly used clearinghouses include the the GPO Clearinghouse, Emulab and PlanetLab.
GENI aggregates federate with one or more clearinghouses i.e. they choose to trust GENI accounts issued by these clearinghouses. Most GENI aggregates federate with all three of the clearinghouses listed above so most experimenters should not have to concern themselves with which clearinghouse to use to get an account.
Tying this all together: The GENI Experimenter Workflow
The following is the workflow for a typical GENI experiment. The objective here is to show how the concepts described above tie together; this is not intended to be a complete description of the GENI experimenter workflow.
1. GENI account and Project
2. Experiment set up
3. Experiment execution
4. Finishing up
The GENI Glossary
For a glossary of GENI terms, see GENI Glossary.