Community-Lab introduction

* Community-Lab testbed architecture
** Overall architecture
This architecture applies to all testbeds using the CONFINE software.
# Move over overlay diagram less overlay connections plus overlay network.
- A testbed consists of a set of nodes managed by the same server.
  - Server managed by testbed admins.
  - Network and node managed by node admins (usually node owners).
  - Node admins must adhere to a set of conditions.
  - Solves management vs. ownersip problem.
- All components in testbed reachable via management network (tinc mesh VPN).
  - Avoids problems with firewalls and private networks in nodes.
  - Avoids address scarcity and incompatibility (well structured IPv6 schema).
  - Public CN addresses still used for experiments when available.
- Gateways connect disjoint parts of the management network.
  - Allows a testbed spanning different CNs and islands through external means
    (e.g. FEDERICA, the Internet).
  - A gateway reachable from the Internet can expose the management network
    (if using public addresses).
- A researcher runs the experiments of a slice in slivers each running in a
  different node…

** Nodes, slices and slivers
- …a model inspired in PlanetLab.
- The slice (a management concept) groups a set of related slivers.
- A sliver holds the resources (CPU, memory, disk, bandwidth, interfaces…)
  allocated for a slice in a given node.
# Diagram: Slices and slivers, two or three nodes with a few slivers on them,
# each with a color identifying it with a slice.)

** Node architecture
Mostly autonomous, no long-running connections to server, asynchronous
operation: robust under link instability.
# Node simplified diagram, hover to interesting parts.
- The community device
  - Completely normal CN network device, possibly already existing.
  - Routes traffic between the CN and devices in the node's local network
    (wired, runs no routing protocol).
- The research device
  - More powerful than CD, it runs OpenWrt firmware customized by CONFINE.
  - Experiments run here.  The separation between CD and RD allows:


    - Minumum CONFINE-specific tampering with CN hardware.
    - Minimum CN-specific configuration for RDs.
    - Greater compatibility and stability for the CN.


  - Slivers are implemented as Linux containers.
    - LXC: lightweight virtualization (in Linux mainstream).
    - Provides a familiar env for researchers.

    - Easier resource limitation, resource isolation and node stability.
  - Control software
    - Manages containers and resource isolation through LXC tools.
    - Ensures network isolation and stability through traffic control (QoS)
      and filtering (from L2 upwards).
    - Protects users' privacy through traffic filtering and anonimization.
  - Optional, controlled direct interfaces for experiments to interact
    directly with the CN (avoiding the CD).
- The recovery device can force a hardware reboot of the RD from several
  triggers and help with upgrade and recovery.

** Node and sliver connectivity
# Node simplified diagram, hover to interesting parts.
Slivers can be configured with different types of network interfaces depending
on what connectivity researchers need for experiments:
- Home computer behind a NAT router: a private interface with traffic
  forwarded using NAT to the CN.  Outgoing traffic is filtered to ensure
  network stability.
- Publicly open service: a public interface (with a public CN address) with
  traffic routed directly to the CN.  Outgoing traffic is filtered to ensure
  network stability.
- Traffic capture: a passive interface using a direct interface for capture.
  Incoming traffic is filtered and anonymized by control software.
- Routing: an isolated interface using a VLAN on top of a direct interface.
  It only can reach other slivers of the same slice with isolated interfaces
  on the same link.  All traffic is allowed.
- Low-level testing: the sliver is given raw access to the interface.  For
  privacy, isolation and stability reasons this should only be allowed in
  exceptional occasions.

* Community-Lab testbed architecture
** Overall architecture
This architecture applies to all testbeds using the CONFINE software.
# Move over overlay diagram less overlay connections plus overlay network.
- A testbed consists of a set of nodes managed by the same server.
  - Server managed by testbed admins.
  - Network and node managed by node admins (usually owners and CN members).
  - Node admins must adhere to testbed conditions.
  - This decouples testbed management from infrastructure ownership and mgmt.
- Testbed management traffic uses a tinc mesh VPN:
  - Avoids problems with firewalls and private networks in nodes.
  - Uses IPv6 to avoid address scarcity and incompatibility between CNs.
  - Short-lived mgmt connections make components mostly autonomous and
    tolerant to link instability.
- A testbed can span multiple CNs thanks to gateways.
  - Bridging the mgmt net over external means (e.g. FEDERICA, the Internet).
  - Gateways can route the management network to the Internet.

- A researcher runs the experiments of a slice in slivers each running in a
  different node…

** Nodes, slices and slivers
- …a model inspired in PlanetLab.
- The slice (a management concept) groups a set of related slivers.
- A sliver holds the resources (CPU, memory, disk, bandwidth, interfaces…)
  allocated for a slice in a given node.
# Diagram: Slices and slivers, two or three nodes with a few slivers on them,
# each with a color identifying it with a slice.)

** Node architecture


# Node simplified diagram, hover to interesting parts.
- The community device
  - Completely normal CN device, so existing ones can be used.
  - Routes traffic between the CN and devices in the node's wired local
    network (which runs no routing protocol).
- The research device


  - Usually more powerful than CD, since experiments run here.
  - Separating CD/RD makes integration with any CN simple and safe:
    - Little CONFINE-specific tampering with CN infrastructure.
    - Little CN-specific configuration for RDs.

    - Misbehaving experiments can't crash CN infrastructure.
  - Runs OpenWrt firmware customized by CONFINE.
  - Slivers are implemented as Linux containers.
    - Lightweight virtualization supported mainstream.
    - Provides a familiar and flexible env for researchers.
  - Direct interfaces allow experiments to bypass the CD when interacting with
    the CN.
  - Control software
    - Uses LXC tools on containers to enforce resource limitation, resource
      isolation and node stability.
    - Uses traffic control, filtering and anonymization to ensure network
      stability, isolation and privacy.


- The recovery device can force a hardware reboot of the RD from several
  triggers and help with upgrade and recovery.

** Node and sliver connectivity
# Node simplified diagram, hover to interesting parts.
Slivers can be configured with different types of network interfaces depending
on what connectivity researchers need for experiments:
- Home computer behind a NAT router: a private interface with traffic
  forwarded using NAT to the CN and filtered to ensure network stability.

- Publicly open service: a public interface (with a public CN address) with
  traffic routed directly to the CN and filtered to ensure network stability.

- Traffic capture: a passive interface using a direct interface for capture.
  Incoming traffic is filtered and anonymized to ensure network privacy.
- Routing: an isolated interface using a VLAN on top of a direct interface.
  It only can reach other slivers of the same slice with isolated interfaces
  on the same link.  All traffic is allowed.
- Low-level testing: the sliver is given raw access to the interface.  For
  privacy, isolation and stability reasons this should only be allowed in
  exceptional occasions.