Community-Lab introduction

      isolation and node stability.
    - uses traffic control, filtering and anonymization to ensure network
      stability, isolation and privacy (partialy implemented).
- The recovery device (not implemented) can force a remote hardware reboot of
  the RD in case it hangs.  It also helps with upgrade and recovery. *##*

* Experiments support
# Axel: Turn around as of mail: from PoV of researcher: 1) testbed through API, choose nodes, 2) login OoB, 3) auto creation, 4) specific interfaces.
Researchers can configure slivers with different types of network interfaces
depending on the connectivity needs of experiments.  For instance, to *##*

- mimic a home PC: use the private interface, *##* which has L3 traffic
  forwarded using NAT to the CN but filtered to ensure network stability. *##*
- implement a network service: create a public interface, *##* which has a CN
  address and L3 traffic routed directly to the CN but filtered to ensure
  network stability. *##*
- experiment with routing algorithms: create an isolated interface, *##* which
  uses a VLAN on top of a direct interface.  All L2 traffic is allowed, but
  only between other slivers of the same slice with isolated interfaces on the
  same physical link.

These were demonstrated with BitTorrent and mesh routing experiments at IEEE
P2P'12 Conference.  *##* Future support is also planned for experiments that:

- analyze traffic: create a passive interface *##* to capture traffic on a
  direct interface, which is filtered and anonymized to ensure network
  privacy. *##*
- perform low-level testing: *##* the sliver is given free raw access to a
  direct interface.  For privacy, isolation and stability reasons this should
  only be allowed in exceptional occasions. *##*

Besides experiments run in slices, researchers will soon be able to collect
link quality and bandwidth usage measurements of all RDs' interfaces through
the DLEP protocol. *##*

Moreover, the server and nodes will soon 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
to show how the testbed works.  We'll create two slivers which ping each
other. *##*

1. The researcher first contacts the server and registers a slice description
   which specifies a template for slivers (e.g. Debian Squeeze) and includes

      isolation and node stability.
    - uses traffic control, filtering and anonymization to ensure network
      stability, isolation and privacy (partialy implemented).
- The recovery device (not implemented) can force a remote hardware reboot of
  the RD in case it hangs.  It also helps with upgrade and recovery. *##*

* Experiments support
These testbed and node architectures offer varied support for experiments. *##*

- Researchers can query testbed management information via server and node
  APIs.  This can help them implement external services to help monitor and
  choose the most appropriate nodes. *##*
- Researchers can log into their running slivers using SSH out-of-band access
  against the node to run arbitrary programs. *##*
- A researcher can use a sliver as a home PC with L3 traffic forwarded using
  NAT to the CN but filtered to ensure network stability. *##*
- A researcher can offer a network service in a sliver by using a public
  interface, which has a CN address and L3 traffic routed directly to the CN
  but filtered to ensure network stability. *##*
- Routing experiments can use an isolated interface in a sliver, which uses a
  VLAN on top of a direct interface.  All L2 traffic is allowed, but only
  between other slivers of the same slice with isolated interfaces on the same
  physical link. *##*

These were demonstrated with BitTorrent and mesh routing experiments at IEEE
P2P'12 Conference.  *##* Future support is also planned for experiments that:

- analyze traffic: using a passive interface to capture traffic on a direct
  interface, which is filtered and anonymized to ensure network privacy. *##*
- perform low-level testing: the sliver is given free raw access to a direct
  interface.  For privacy, isolation and stability reasons this should only be
  allowed in exceptional occasions. *##*

Also, researchers will soon be able to collect link quality and bandwidth
usage measurements of all RDs' interfaces through the DLEP protocol. *##*




** An example experiment
to show how the testbed works.  We'll create two slivers which ping each
other. *##*

1. The researcher first contacts the server and registers a slice description
   which specifies a template for slivers (e.g. Debian Squeeze) and includes