At Community-Lab, most of the equipment supports experiments that range from transport to application layers. However, the researcher should consider that this equipment is comparable to those used by community networks, i.e. modest capabilities in term of CPU, memory and disk should be expected. Additionally, we have deployed a limited number of devices in what we call a Community-Lab cloud. Devices within such a cloud can reach each other wirelessly, allowing researchers to experiment at the link layer using DLEP and at the network layer using VLAN tagging. The type of applications that can be run on a node is determined by the network interfaces it has (more details at the glossary).

Through this manual we will use some concepts that the reader should be familiar with. For completeness, we provide here a short description of the most relevant ones, but the reader can always check the glossary for further details.

Architecture overview

Community-Lab defines two different types of devices to ease the management of the testbed while being part of a community network:

Research devices or nodes are the devices deployed by CONFINE that run the applications (like networking experiments or distributed services).

Community devices are devices connected to the community network, participating on every mechanism required by it (routing protocols, database registration, etc.). Research devices are connected to the community network through a community device, but they do not have to adapt to the requirements of the community network.

Testbed nodes can run applications concurrently. This is achieved by means of Linux Containers (LXC): every application will indicate a set of nodes where it wants to run, and the research devices will create a LXC container for the application. Using PlanetLab terminology, we call each of those containers a sliver and the set of slivers belonging to an application is called a slice.

Nodes, slices, users and so on are managed through the a testbed registry, which can be reached via the Community-Lab controller. It runs confine-controller, a software package used for managing a CONFINE testbed. Its main goal is to provide a web interface as well as a REST API to the testbed registry, allowing users to create and manage slices in the testbed, as well as register and offer nodes in it, among other tasks.

Users and roles

The main roles of testbed users are:

Slice administrators (or researchers) are the main users of the testbed. They are the people that run applications in the testbed as slices, and they must belong to a group, which represents a community, research group, institution, etc.

Node administrators (or technicians) are the people responsible for the research devices (AKA testbed nodes). They can register nodes, generate their software, etc., and they must also belong to a group.

Finally, group administrators are responsibles for a group and can manage the people that belong to it, as well as the related slices and nodes.

To conclude, we would like to state that, even though the guides are written to help users of Community-Lab, CONFINE's software is distributed as Free/Libre/Open Source Software, therefore, such guides can be of help to the users of any other deployment of CONFINE's software.

How to get support

Users of Community-Lab should subscribe to the Community-Lab Users mailing list. This is a forum for all Community-Lab users to discuss and get support from other users, testbed operators and developers. You can participate after subscribing by sending mail to users@lists.community-lab.net.

In case of any problem with the operation of the testbed that requires action from the testbed operators or node administrators, you may also report it to Community-Lab's issue tracker. For instance, if you need some particular testbed node to run an application and it happens to be down or malfunctioning, you can use the testbed's issue tracker to report the problem in a new ticket addressed to the group that owns the node.

In case of any bug or required feature related with CONFINE software (the software behind Community-Lab and other similar testbeds), you may ask in the confine-devel mailing list or report it to CONFINE's Redmine site. For instance, if you, as a node administrator, found a bug in the software of one of the nodes you administer, you can report that in a new issue at the Redmine project for node software.

Best practices

You have two main choices to work with a CONFINE testbed: preparing your own virtual environment (Virtual CONFINE Testbed or VCT) or using the real Community-Lab testbed deployed in the several community networks involved in the CONFINE Project. It is strongly recommended to prepare and debug your application locally with VCT (a testbed and your application, all running virtualized on your computer). Then, when it works in the virtualized environment, you may move to the real Community-Lab testbed and face the additional challenges of running on a realistic environment. If you have a local physical testbed running CONFINE, you may want to try your application in the local testbed before moving on to Community-Lab.

In any case, installing VCT on your computer is the easiest way to get used to CONFINE testbeds. Please read Using the Virtual CONFINE Testbed if you intend to use VCT on your computer.