Community-Lab introduction

Modified script.txt from [daf35fb5e3] to [2e758bb5c1].

     3      3   * Introduction
     4      4   ** Community networks
     5      5   - Infrastructure deployed by organized groups of people for self-provision of
     6      6     broadband networking that works and grows according to their own interests.
     7      7   - Characteristics: Open participation, open and transparent management,
     8      8     distributed ownership.
     9      9   - CNs are of strategic importance for the universal availability of broadband
    10         -  networking (according to the European Digital Agenda).
    11         -- A challenge: How to support the growth and sustainability of community
    12         -  networks by providing the means to conduct experimentally driven research.
           10  +  networking (an initiative for the European Digital Agenda).
           11  +- A challenge for researchers: How to support the growth and sustainability of
           12  +  CNs by providing the means to conduct experimentally driven research.
    13     13   
    14     14   ** The CONFINE project: Community Networks Testbed for the Future Internet
    15     15   - Takes on the previous challenge.
    16     16   - Project supported by the European Community Framework Programme 7 within the
    17     17     Future Internet Research and Experimentation Initiative (FIRE).
    18         -- Partners (list with logos): (community networks) guifi.net, Funkfeuer,
    19         -  Athens Wireless Metropolitan Network; (research centres) Universitat
    20         -  Politècnica de Catalunya, Fraunhofer Institute for Communication,
    21         -  Information Processing and Ergonomics, Interdisciplinary Institute for
    22         -  Broadband Technology; (NGOs) the OPLAN Foundation, Pangea.
    23         -- Objectives: Provide a testbed and associated tools and knowledge for
           18  +# List partner's logos.
           19  +- Partners: (community networks) guifi.net, Funkfeuer, Athens Wireless
           20  +  Metropolitan Network; (research centres) Universitat Politècnica de
           21  +  Catalunya, Fraunhofer Institute for Communication, Information Processing
           22  +  and Ergonomics, Interdisciplinary Institute for Broadband Technology; (NGOs)
           23  +  OPLAN Foundation, Pangea.
           24  +- Objective: Provide a testbed and associated tools and knowledge for
    24     25     researchers to experiment on real community networks.
    25     26   
    26     27   ** Testbeds
    27     28   - Environments built with real hardware for realistic experimental research on
    28         -  network technologies (instead of simulations).
    29         -- Wireless: (outdoor) Berlin RoofNet, MIT Roofnet; (indoor) IBBT's w-iLab.t,
    30         -  CERTH's NITOS, WINLAB's ORBIT.  Limited local scale, controlled environment,
    31         -  no resource sharing between experiments.
           29  +  network technologies.
           30  +- Wireless, both outdoor (HU's Berlin RoofNet, MIT Roofnet) and indoor (IBBT's
           31  +  w-iLab.t, CERTH's NITOS, WINLAB's ORBIT).  Problems: limited local scale,
           32  +  controlled environment, no resource sharing between experiments.
    32     33   - Internet: PlanetLab, planet-scale testbed with resource sharing on nodes.
    33     34     Main inspiration for Community-Lab.
    34     35   
    35     36   ** Community-Lab: a testbed for community networks
    36     37   - The testbed developed by CONFINE.
    37         -- Integrates and extends three Community Networks: guifi.net, FunkFeuer, AWMN.
    38     38   # Node maps here for CNs with captures from node DBs.
    39         -- Also nodes in participating research centres.
    40         -- Linked together over the FEDERICA academic backbone.
    41         -- All its software and documentation is released under Free licenses, anyone
    42         -  can setup a CONFINE testbed like Community-Lab.
           39  +- Integrates and extends three community networks: guifi.net, FunkFeuer, AWMN.
           40  +- Also includes nodes in participating research centres.
           41  +- All linked together over the FEDERICA research backbone.
           42  +- All its software and documentation is “free as in freedom”, anyone can setup
           43  +  a CONFINE testbed like Community-Lab.
    43     44   
    44     45   * Challenges and requirements
           46  +CNs pose unique challenges for a testbed.  How to
           47  +
    45     48   ** Simple management vs. Distributed node ownership
    46         -- How to manage devices belonging to diverse owners.
           49  +- manage devices belonging to diverse owners?
    47     50   
    48     51   ** Features vs. Lightweight, low cost (free & open)
    49         -- Devices ranging from PCs to embedded boards.
    50         -- Need light system able to run on very different devices.
           52  +- support devices ranging from PCs to embedded boards?
    51     53   
    52     54   ** Heterogeneity vs. Compatibility
    53         -- Some devices allow hacking while others don't.
    54         -- Diverse connectivity and link technologies (wireless, wired, fiber).
           55  +- work with devices which allow little customization?
           56  +- support diverse connectivity and link technologies (wireless, wired, fiber)?
    55     57   
    56     58   ** Familiarity & flexibility vs. System stability
    57     59   - Researchers prefer a familiar Linux env with root access.
    58         -- But experiments sharing the same node must be isolated.
           60  +- isolate experiments that share the same node?
           61  +- keep nodes stable to avoid in-place maintenance?  Accessing node locations
           62  +  can be hard.
    59     63   # Frozen tower.
    60         -- Accessing node locations can be hard, so keep node stability to avoid
    61         -  in-place maintenance.
    62     64   
    63     65   ** Flexibility vs. Network stability
    64         -- Network experiments running on nodes in a production network.
    65         -- Allow interaction at the lowest possible layer of the CN while not
    66         -  disrupting or overusing it.
           66  +- Network experiments run on nodes in a production network.
           67  +- allow interaction at the lowest possible layer of the CN while not
           68  +  disrupting or overusing it?
    67     69   
    68     70   ** Traffic collection vs. Privacy of CN users
    69         -- Experiments performing traffic collection and characterization.
    70         -- Avoid researchers spying on users' data.
           71  +- allow experiments performing traffic collection and characterization?
           72  +- avoid researchers spying on users' data?
    71     73   
    72     74   ** Link instability vs. Management robustness
    73         -- Management must deal with frequent network outages in the CN.
           75  +- deal with frequent network outages in the CN when managing nodes?
    74     76   
    75     77   ** Reachability vs. IP address provisioning
    76         -- Testbed spanning different CNs.
    77         -- IPv4 scarcity and incompatibility between CNs, lack of IPv6 support.
           78  +- We have IPv4 scarcity and incompatibility between CNs, lack of IPv6 support.
           79  +- support testbed spanning different CNs?
    78     80   
    79     81   * Community-Lab testbed architecture
           82  +This is the architecture developed by the CONFINE project to handle the
           83  +previous challenges.
           84  +
    80     85   ** Overall architecture
    81     86   This architecture applies to all testbeds using the CONFINE software.
    82     87   # Move over overlay diagram less overlay connections plus overlay network.
    83     88   - A testbed consists of a set of nodes managed by the same server.
    84     89     - Server managed by testbed admins.
    85         -  - Network and node managed by node admins (usually owners and CN members).
    86         -  - Node admins must adhere to testbed conditions.
           90  +  - Network and node managed by CN members.
           91  +  - Node admins must adhere to testbed terms and conditions.
    87     92     - This decouples testbed management from infrastructure ownership and mgmt.
    88     93   - Testbed management traffic uses a tinc mesh VPN:
    89     94     - Avoids problems with firewalls and private networks in nodes.
    90         -  - Uses IPv6 to avoid address scarcity and incompatibility between CNs.
           95  +  - Mgmt network uses IPv6 to avoid address scarcity and incompatibility
           96  +    between CNs.
    91     97     - Short-lived mgmt connections make components mostly autonomous and
    92     98       tolerant to link instability.
    93         -- A testbed can span multiple CNs thanks to gateways.
           99  +- Gateways allow a testbed to span multiple CNs.
    94    100     - Bridging the mgmt net over external means (e.g. FEDERICA, the Internet).
    95    101     - Gateways can route the management network to the Internet.
    96    102   - A researcher runs the experiments of a slice in slivers each running in a
    97         -  different node…
          103  +  different node.
    98    104   
    99    105   ** Nodes, slices and slivers
   100         -- …a model inspired in PlanetLab.
          106  +# Diagram: Slices and slivers, two or three nodes with a few slivers on them,
          107  +# each with a color identifying it with a slice.)
          108  +- These concepts are inspired in PlanetLab.
   101    109   - The slice (a management concept) groups a set of related slivers.
   102    110   - A sliver holds the resources (CPU, memory, disk, bandwidth, interfaces…)
   103    111     allocated for a slice in a given node.
   104         -# Diagram: Slices and slivers, two or three nodes with a few slivers on them,
   105         -# each with a color identifying it with a slice.)
   106    112   
   107    113   ** Node architecture
          114  +allows the realization of these concepts.  A node consists of:
   108    115   # Node simplified diagram, hover to interesting parts.
   109    116   - The community device
   110    117     - Completely normal CN device, so existing ones can be used.
   111         -  - Routes traffic between the CN and devices in the node's wired local
   112         -    network (which runs no routing protocol).
          118  +  - Routes traffic between the CN and the node's wired local network (which
          119  +    runs no routing protocol).
   113    120   - The research device
   114    121     - Usually more powerful than CD, since experiments run here.
   115    122     - Separating CD/RD makes integration with any CN simple and safe:
   116         -    - Little CONFINE-specific tampering with CN infrastructure.
   117         -    - Little CN-specific configuration for RDs.
          123  +    - Little CONFINE-specific tampering with CN infrastructure.?!
          124  +    - Little CN-specific configuration for RDs.?!
   118    125       - Misbehaving experiments can't crash CN infrastructure.
   119    126     - Runs OpenWrt firmware customized by CONFINE.
   120    127     - Slivers are implemented as Linux containers.
   121    128       - Lightweight virtualization supported mainstream.
   122    129       - Provides a familiar and flexible env for researchers.
   123    130     - Direct interfaces allow experiments to bypass the CD when interacting with
   124    131       the CN.
   125    132     - Control software
   126    133       - Uses LXC tools on containers to enforce resource limitation, resource
   127    134         isolation and node stability.
   128    135       - Uses traffic control, filtering and anonymization to ensure network
   129    136         stability, isolation and privacy (partialy implemented).
   130         -- The recovery device can force a hardware reboot of the RD from several
   131         -  triggers and help with upgrade and recovery (not implemented).
          137  +- The recovery device (not implemented) can force a remote hardware reboot of
          138  +  the RD in case it hangs.  It also helps with upgrade and recovery.
   132    139   
   133    140   * Supported experiments
   134    141   # Node simplified diagram, hover to interesting parts.
   135    142   Researchers can configure slivers with different types of network interfaces
   136         -depending on the connectivity needs of experiments:
          143  +depending on the connectivity needs of experiments.  For instance, to
   137    144   
   138         -- Home PC-like access: a private interface with traffic forwarded using NAT to
   139         -  the CN (filtered to ensure network stability).
   140         -- Internet service: a public interface (with a public CN address) with traffic
   141         -  routed directly to the CN (filtered to ensure network stability).
   142         -- Traffic analysis (not implemented): a passive interface capturing traffic on
   143         -  a direct interface (filtered and anonymized to ensure network privacy).
   144         -- Routing: an isolated interface using a VLAN on top of a direct interface.
   145         -  All traffic is allowed, but it can only reach other slivers of the same
   146         -  slice with isolated interfaces on the same physical link.
   147         -- Low-level testing (not implemented): the sliver is given raw access to the
          145  +- mimic a home PC: use the private interface, which has traffic forwarded
          146  +  using NAT to the CN but filtered to ensure network stability.
          147  +- implement a network service: create a public interface, which has a CN
          148  +  address and traffic routed directly to the CN but filtered to ensure network
          149  +  stability.
          150  +- experiment with routing algorithms: create an isolated interface, which uses
          151  +  a VLAN on top of a direct interface.  All traffic is allowed, but only
          152  +  between other slivers of the same slice with isolated interfaces on the same
          153  +  physical link.
          154  +
          155  +Not yet implemented:
          156  +
          157  +- analyze traffic: create a passive interface to capture traffic on a direct
          158  +  interface, which is filtered and anonymized to ensure network privacy.
          159  +- perform low-level testing: the sliver is given free raw access to a direct
   148    160     interface.  For privacy, isolation and stability reasons this should only be
   149    161     allowed in exceptional occasions.
   150    162   
   151         -Besides low level access, RDs also offer link quality and bandwidth usage
   152         -measurements for all their interfaces through DLEP (available soon).
          163  +RDs will soon be able to provide link quality and bandwidth usage measurements
          164  +for all their interfaces through the DLEP protocol.
   153    165   
   154    166   Finally, the server and nodes publish management information through an API
   155         -that can be used to study the testbed itself or to implement external services
   156         -(like node monitoring and selection).
          167  +that can be used to study the testbed itself, or to implement external
          168  +services like node monitoring and selection.
   157    169   
   158    170   ** An example experiment
   159    171   # Event diagram, hover over components explained.
   160         -To show how the testbed works: two slivers, one of them pings the other one.
   161         -Let's call them the source and target sliver, respectively.
          172  +To show how the testbed works: two slivers which ping each other.
   162    173   
   163    174   1. The researcher first contacts the server and creates a slice description
   164         -   which specifies a template for slivers (e.g. Debian Squeeze i386).  The
   165         -   researcher attaches experiment data including a program to setup slivers
   166         -   for the experiments and another one to run them.
   167         -2. This and all subsequent changes initiated by the researcher are stored in
          175  +   which specifies a template for slivers (e.g. Debian Squeeze) and includes
          176  +   data and programs to setup slivers and run experiments.
          177  +2. This and all subsequent changes performed by the researcher are stored in
   168    178      the registry, which holds the config of all components in the testbed.
   169         -3. The researcher chooses a couple of nodes and creates sliver descriptions
   170         -   for them belonging to the previous slice.  Both sliver descriptions include
   171         -   a public interface to the CN and user-defined properties to mark slivers as
   172         -   either source or target.
          179  +3. The researcher chooses two nodes and adds sliver descriptions for them in
          180  +   the previous slice.  Each one includes a public interface to the CN.
   173    181   4. Each of the previous nodes gets a sliver description for it.  If enough
   174         -   resources are available, a container is created by applying the desired
          182  +   resources are available, a container is created by applying the sliver
   175    183      configuration over the selected template.
   176    184   5. Once the researcher knows that slivers have been instantiated, the server
   177    185      can be commanded to activate the slice.
   178    186   6. When nodes get instructions to activate slivers they start the containers.
   179         -7. Containers execute the experiment's setup and run programs.  The programs
   180         -   query sliver properties to decide whether to act as source or target.
          187  +7. Containers execute the setup and run programs provided by the researcher.
   181    188   8. Researchers interact straight with containers if needed (e.g. via SSH) and
   182    189      collect results from them.
   183    190   9. When finished, the researcher tells the server to deactivate and
   184    191      deinstantiate the slice.
   185    192   10. Nodes get the instructions and they stop and remove containers.
   186    193   
   187    194   * Cooperation between community networks and Community-Lab
   188    195   # CN diagram (buildings and cloud).
   189         -There are different ways.  Given a typical CN like this, with most nodes
          196  +can take different forms.  Given a typical CN like this, with most nodes
   190    197   linked using cheap and ubiquitous WiFi technology:
   191    198   
   192    199   # CN diagram extended with CONFINE devices (hover over interesting part).
   193    200   - CN members can provide an existing CD and let CONFINE connect a RD to it via
   194    201     Ethernet.  Experiments are restricted to the application layer unless the
   195    202     node owner allows the RD to include a direct interface (i.e. antenna).
   196    203   - CN members can provide a location and let CONFINE set up a complete node
   197         -  there (CD and RD).  All but low-level experiments are possible using direct
   198         -  interfaces.  In this way CONFINE helps extend the CN.
          204  +  there (CD and RD).  In this way CONFINE helps extend the CN.
   199    205   - CONFINE can also extend the CN by setting up a physically separated cloud of
   200    206     connected nodes at a site controlled by a partner (e.g. campus).  All kinds
   201         -  of experiments are possible using direct interfaces.  Users are warned about
   202         -  the experimental nature of the network.
          207  +  of experiments are possible using direct interfaces.  Users should be warned
          208  +  about the research nature of the network.
   203    209   
   204    210   * Participate!
   205    211   We introduced you to Community-Lab, a new testbed being developed by the
   206         -CONFINE project to support research targeted to allow CNs to become a key part
   207         -of Internet infrastructure in the future.
          212  +CONFINE project to support research that can help CNs become a key part of the
          213  +Internet in a near future.
   208    214   
   209    215   Community networks and researchers: We look forward to your participation!
   210    216   - More information: http://community-lab.net/, http://confine-project.eu/
   211    217   - Questions?
   212    218   
   213    219   # Commenters: Less attention on architecture, more on global working of
   214    220   # testbed.