Community-Lab introduction

Modified script.txt from [0df14cd02b] to [9c5a856712].

    88     88   - A testbed consists of a set of nodes managed by the same server.
    89     89     - Server managed by testbed admins.
    90     90     - Network and node managed by CN members.
    91     91     - Node admins must adhere to testbed terms and conditions.
    92     92     - This decouples testbed management from infrastructure ownership and mgmt.
    93     93   - Testbed management traffic uses a tinc mesh VPN:
    94     94     - Avoids problems with firewalls and private networks in nodes.
    95         -  - Mgmt network uses IPv6 to avoid address scarcity and incompatibility
    96         -    between CNs.
    97         -  - Short-lived mgmt connections make components mostly autonomous and
    98         -    tolerant to link instability.
           95  +  - IPv6 is used to avoid address scarcity and incompatibility between CNs.
           96  +  - Link instability is tolerated by using short-lived mgmt connections.
    99     97   - Gateways allow a testbed to span multiple CNs.
   100         -  - Bridging the mgmt net over external means (e.g. FEDERICA, the Internet).
   101         -  - Gateways can route the management network to the Internet.
           98  +  - Connecting the mgmt net over external means (e.g. FEDERICA, the Internet).
           99  +  - Gateways can make the management network available to the Internet.
   102    100   - A researcher runs the experiments of a slice in slivers each running in a
   103    101     different node.
   104    102   
   105    103   ** Nodes, slices and slivers
   106    104   # Diagram: Slices and slivers, two or three nodes with a few slivers on them,
   107    105   # each with a color identifying it with a slice.)
   108    106   - These concepts are inspired in PlanetLab.
................................................................................
   115    113   # Node simplified diagram, hover to interesting parts.
   116    114   - The community device
   117    115     - Completely normal CN device, so existing ones can be used.
   118    116     - Routes traffic between the CN and the node's wired local network (which
   119    117       runs no routing protocol).
   120    118   - The research device
   121    119     - Usually more powerful than CD, since experiments run here.
   122         -  - Separating CD/RD makes integration with any CN simple and safe:
   123         -    - Little CONFINE-specific tampering with CN infrastructure.?!
   124         -    - Little CN-specific configuration for RDs.?!
   125         -    - Misbehaving experiments can't crash CN infrastructure.
          120  +  - A separated RD minimizes tampering with CN infrastructure.
          121  +    - Also experiments can't crash the CD.
   126    122     - Runs OpenWrt firmware customized by CONFINE.
   127         -  - Slivers are implemented as Linux containers.
   128         -    - Lightweight virtualization supported mainstream.
   129         -    - Provides a familiar and flexible env for researchers.
   130         -  - Direct interfaces allow experiments to bypass the CD when interacting with
   131         -    the CN.
          123  +  - Slivers are implemented as lightweight Linux containers.
          124  +    - Provide a familiar and flexible env for researchers.
          125  +  - Direct interfaces allow low-level interaction of experiments with the CN
          126  +    bypassing the CD.
   132    127     - Control software
   133    128       - Uses LXC tools on containers to enforce resource limitation, resource
   134    129         isolation and node stability.
   135    130       - Uses traffic control, filtering and anonymization to ensure network
   136    131         stability, isolation and privacy (partialy implemented).
   137    132   - The recovery device (not implemented) can force a remote hardware reboot of
   138    133     the RD in case it hangs.  It also helps with upgrade and recovery.