Community-Lab introduction

- Routing: an isolated interface using a VLAN on top of a direct interface.
  All traffic is allowed, but it can only reach other slivers of the same
  slice with isolated interfaces on the same physical link.
- Low-level testing (not implemented): the sliver is given raw access to the
  interface.  For privacy, isolation and stability reasons this should only be
  allowed in exceptional occasions.








** An example experiment
# Event diagram, hover over components explained.
To show how the testbed works: two slivers, one of them (source sliver) pings
the other one (target sliver).

1. The researcher first contacts the server and creates a slice description
   which specifies a template for slivers (e.g. Debian Squeeze i386).
................................................................................
   programs query sliver properties to decide their behaviour.
8. Researchers interact straight with containers if needed (e.g. via SSH) and
   collect results from them.
9. When finished, the researcher tells the server to deactivate and
   deinstantiate the slice.
10. Nodes get the instructions and they stop and remove containers.

At all times there can be external services interacting with researchers,
server, nodes and slivers, e.g. to help choosing nodes, monitor nodes or
collect results.

* Community-Lab integration in existing community networks
# CN diagram (buildings and cloud).
A typical CN looks like this, with most nodes linked using cheap and
ubiquitous WiFi technology (and less frequently Ethernet, optical fiber or
others).  The CONFINE project follows three strategies taking into account
that CNs are production networks with distributed ownership:

- Routing: an isolated interface using a VLAN on top of a direct interface.
  All traffic is allowed, but it can only reach other slivers of the same
  slice with isolated interfaces on the same physical link.
- Low-level testing (not implemented): the sliver is given raw access to the
  interface.  For privacy, isolation and stability reasons this should only be
  allowed in exceptional occasions.

Besides low level access, RDs also offer link quality and bandwidth usage
measurements for all their interfaces through DLEP (available soon).

Finally, the server and nodes publish management information through an API
that can be used to study the testbed itself or to implement external services
(like node monitoring and selection).

** An example experiment
# Event diagram, hover over components explained.
To show how the testbed works: two slivers, one of them (source sliver) pings
the other one (target sliver).

1. The researcher first contacts the server and creates a slice description
   which specifies a template for slivers (e.g. Debian Squeeze i386).
................................................................................
   programs query sliver properties to decide their behaviour.
8. Researchers interact straight with containers if needed (e.g. via SSH) and
   collect results from them.
9. When finished, the researcher tells the server to deactivate and
   deinstantiate the slice.
10. Nodes get the instructions and they stop and remove containers.





* Community-Lab integration in existing community networks
# CN diagram (buildings and cloud).
A typical CN looks like this, with most nodes linked using cheap and
ubiquitous WiFi technology (and less frequently Ethernet, optical fiber or
others).  The CONFINE project follows three strategies taking into account
that CNs are production networks with distributed ownership: