Community-Lab introduction

Modified script.txt from [b369864a66] to [ae0e02c8a7].

     1      1   #+title: Community-Lab: A Community Networking Testbed for the Future Internet
     2      2   
     3      3   * Introduction
            4  +Hello, I'm Blah Blah from Blah Blah, I work at the CONFINE project and I'm
            5  +going to talk you about *##* Community-Lab, a community networking testbed for
            6  +the future Internet.
     4      7   ** Community networks
     5      8   - Infrastructure deployed by organized groups of people for self-provision of
     6      9     broadband networking that works and grows according to their own interests.
     7     10   - Characteristics: Open participation, open and transparent management,
     8     11     distributed ownership.
     9         -- The EU regards CNs as fundamental for the universalization of broadband
           12  +- The EU regards CNs as fundamental for *##* the universalization of broadband
    10     13     networking.
    11         -- New research challenge: How to support the growth and sustainability of CNs
    12         -  by providing the means to conduct experimentally driven research.
           14  +- Means new research challenge: How to support the growth and sustainability
           15  +  of CNs by providing the means to conduct experimentally driven research. *##*
    13     16   
    14     17   ** The CONFINE project: Community Networks Testbed for the Future Internet
    15         -- Takes on the previous challenge.
           18  +- The CONFINE project takes on the previous challenge.
    16     19   - Project supported by the European Community Framework Programme 7 within the
    17     20     Future Internet Research and Experimentation Initiative (FIRE).
    18         -# List partner's logos.
    19         -- Partners: (community networks) guifi.net, Funkfeuer, Athens Wireless
    20         -  Metropolitan Network; (research centres) Universitat Politècnica de
           21  +- Partners: (*##* community networks) guifi.net, Funkfeuer, Athens Wireless
           22  +  Metropolitan Network; (*##* research institutions) Universitat Politècnica de
    21     23     Catalunya, Fraunhofer Institute for Communication, Information Processing
    22         -  and Ergonomics, Interdisciplinary Institute for Broadband Technology; (NGOs)
    23         -  OPLAN Foundation, Pangea.
           24  +  and Ergonomics, Interdisciplinary Institute for Broadband Technology; (*##*
           25  +  supporting NGOs) OPLAN Foundation, Pangea. *##*
    24     26   - Objective: Provide a testbed and associated tools and knowledge for
    25         -  researchers to experiment on real community networks.
           27  +  researchers to experiment on real community networks. *##*
    26     28   
    27     29   ** Testbed?
    28     30   - Environment built with real hardware for realistic experimental research on
    29         -  network technologies.
    30         -- Wireless, both indoor (IBBT's w-iLab.t, CERTH's NITOS, WINLAB's ORBIT) and
    31         -  outdoor (HU's Berlin RoofNet, MIT Roofnet).  Problems: limited local scale,
    32         -  controlled environment, no resource sharing between experiments.
           31  +  network technologies. *##*
           32  +- Some wireless testbeds, both indoor and outdoor.
           33  +  - Problems: their limited local scale, their unrealistic controlled
           34  +    environment, experiments can't share resources simultaneously.
    33     35   - Internet: PlanetLab, planet-scale testbed with resource sharing on nodes.
    34         -  Main inspiration for Community-Lab.
           36  +  Main inspiration for Community-Lab. *##*
    35     37   
    36     38   ** Community-Lab: a testbed for community networks
    37         -- The testbed developed by CONFINE.
    38         -# Node maps here for CNs with captures from node DBs.
    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.
           39  +- Community-Lab is the testbed developed by CONFINE.
           40  +- Integrates and extends the participating community networks.
           41  +# Place CN logos over green blobs of CONFINE logo,
           42  +# with FEDERICA logo in center blob.
           43  +- Using the FEDERICA research backbone for interconnection. *##*
           44  +- All Community-Lab's software and documentation is “free as in freedom” so
           45  +  people can use it to setup their own CONFINE testbed.
    44     46   
    45     47   * Requirements and challenges
    46     48   A testbed has requirements that are challenged by the unique characteristics
    47         -of CNs.  For instance, how to
           49  +of CNs.  For instance, how to *##*
    48     50   
    49     51   ** Simple management vs. Distributed node ownership
    50         -- manage devices belonging to diverse owners?
           52  +- manage devices belonging to diverse owners? *##*
    51     53   
    52     54   ** Features vs. Lightweight, low cost
    53         -- support devices ranging from PCs to embedded boards?
           55  +- support devices ranging from PCs to embedded boards? *##*
    54     56   
    55     57   ** Compatibility vs. Heterogeneity
    56     58   - work with devices which allow little customization?
    57         -- support diverse connectivity and link technologies (wireless, wired, fiber)?
           59  +- support diverse connectivity models and link technologies including
           60  +  wireless, wired and fiber? *##*
    58     61   
    59     62   ** Familiarity & flexibility vs. System stability
    60         -- Researchers prefer a familiar Linux env with root access.
           63  +- Researchers usually prefer a familiar Linux env with root access.
    61     64   - isolate experiments that share the same node?
    62         -- keep nodes stable to avoid in-place maintenance?  Accessing node locations
    63         -  can be hard.
    64         -# Frozen tower.
           65  +- *##* Sometimes accessing node locations can be hard. *##*
           66  +  - keep nodes stable to avoid in-place maintenance? *##*
    65     67   
    66     68   ** Flexibility vs. Network stability
    67         -- Network experiments run on nodes in a production network.
           69  +- Remember that network experiments run on a production network.
    68     70   - allow interaction at the lowest possible layer of the CN while not
    69         -  disrupting or overusing it?
           71  +  disrupting or saturating it? *##*
    70     72   
    71     73   ** Traffic collection vs. Privacy of CN users
    72     74   - allow experiments performing traffic collection and characterization?
    73         -- avoid researchers spying on users' data?
           75  +- While avoiding researchers spying on users' data? *##*
    74     76   
    75     77   ** Management robustness vs. Link instability
    76         -- deal with frequent network outages in the CN when managing nodes?
           78  +- deal with frequent network outages in the CN when managing nodes? *##*
    77     79   
    78     80   ** Reachability vs. IP address provisioning
    79         -- We have IPv4 scarcity and incompatibility between CNs, lack of IPv6 support.
    80         -- support testbed spanning different CNs?
           81  +- CNs have IPv4 scarcity and incompatible addressing with little IPv6 support.
           82  +- support testbed spanning different CNs? *##*
    81     83   
    82     84   * Community-Lab testbed architecture
    83         -This is the architecture developed by the CONFINE project to handle the
    84         -previous challenges.
    85         -
    86     85   ** Overall architecture
    87         -This architecture applies to all testbeds using the CONFINE software.
    88         -# Move over overlay diagram less overlay connections plus overlay network.
    89         -- A testbed consists of a set of nodes managed by the same server.
           86  +This is the architecture developed by the CONFINE project to handle the
           87  +previous challenges.  It applies to all testbeds using CONFINE software. *##*
           88  +
           89  +- A testbed consists of a set of nodes managed by the same server. *##*
    90     90     - Server managed by testbed admins.
    91         -  - Network and node managed by CN members.
           91  +  - Network and nodes managed by CN members.
    92     92     - Node admins must adhere to testbed terms and conditions.
    93         -  - This decouples testbed management from infrastructure ownership and mgmt.
           93  +  - This decouples testbed management from infrastructure ownership & mgmt. *##*
    94     94   - Testbed management traffic uses a tinc mesh VPN:
    95     95     - Avoids problems with firewalls and private networks in nodes.
    96         -  - IPv6 is used to avoid address scarcity and incompatibility between CNs.
    97         -  - Link instability is tolerated by using short-lived mgmt connections.
           96  +  - Uses IPv6 to avoid address scarcity and incompatibility between CNs.
           97  +  - Mgmt connections are short-lived to tolerate link instability. *##*
    98     98   - Gateways are entry points to the mgmt network.
    99         -  - They can extend it over multiple CNs by external means (e.g. FEDERICA, the
           99  +  - They help extend it over multiple CNs by external means (e.g. FEDERICA, the
   100    100       Internet).
   101         -  - They can also route the management network to the Internet.
   102         -- A researcher runs the experiments of a slice in slivers each running in a
   103         -  different node.
          101  +  - They can also route the management network to the Internet. *##*
          102  +- Researchers run experiments in slices spread over several nodes (as
          103  +  slivers). *##*
   104    104   
   105    105   ** Slices, slivers and nodes
   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    106   - These concepts are inspired in PlanetLab.
   109         -- The slice (a management concept) groups a set of related slivers.
          107  +- A slice is a management concept that groups a set of related slivers.
   110    108   - A sliver holds the resources (CPU, memory, disk, bandwidth, interfaces…)
   111    109     allocated for a slice in a given node.
   112         -- A node hosts several slivers at the same time.
          110  +- A node hosts several slivers at the same time. *##*
   113    111   
   114    112   ** Node architecture
   115         -allows the realization of these concepts.  A node consists of:
   116         -# Node simplified diagram, hover to interesting parts.
          113  +allows the realization of these concepts.  *##* A node consists of a CD, a RD
          114  +and a rD on a wired local network. *##*
          115  +
   117    116   - The community device
   118    117     - Completely normal CN device, so existing ones can be used.
   119         -  - Routes traffic between the CN and the node's wired local network (which
   120         -    runs no routing protocol).
          118  +  - routes traffic between the CN and the local network (which runs no routing
          119  +    protocol). *##*
   121    120   - The research device
   122    121     - Usually more powerful than CD, since experiments run here.
   123         -  - A separated RD minimizes tampering with CN infrastructure.
   124         -    - Also experiments can't crash the CD.
   125         -  - Runs the versatile, light and free OpenWrt distro, customized by CONFINE.
   126         -  - Slivers are implemented as lightweight Linux containers.
   127         -    - So researchers get root access to a familiar environment.
   128         -  - Direct interfaces allow low-level interaction of experiments with the CN
   129         -    bypassing the CD.
   130         -  - Control software
   131         -    - Uses LXC tools to manage containers and enforce resource limits,
          122  +    - Separating the RD from the CD minimizes tampering with CN infrastructure.
          123  +    - Also experiments can't crash CN devices.
          124  +  - runs the versatile, light & free OpenWrt distro, customized by CONFINE. *##*
          125  +    - Slivers are implemented as lightweight Linux containers.
          126  +    - So researchers get root access to a familiar environment. *##*
          127  +  - provides direct interfaces to allow low-level interaction of experiments
          128  +    with the CN bypassing the CD. *##*
          129  +  - runs CONFINE control software
          130  +    - uses LXC tools to manage containers and enforce resource limits,
   132    131         isolation and node stability.
   133         -    - Uses traffic control, filtering and anonymization to ensure network
   134         -      stability, isolation and privacy (partialy implemented).
          132  +    - uses traffic control, filtering and anonymization to ensure network
          133  +      stability, isolation and privacy (partialy implemented). *##*
   135    134   - The recovery device (not implemented) can force a remote hardware reboot of
   136         -  the RD in case it hangs.  It also helps with upgrade and recovery.
          135  +  the RD in case it hangs.  It also helps with upgrade and recovery. *##*
   137    136   
   138    137   * Experiments support
   139         -# Node simplified diagram, hover to interesting parts.
          138  +# Tag diagram with new title.
   140    139   Researchers can configure slivers with different types of network interfaces
   141         -depending on the connectivity needs of experiments.  For instance, to
          140  +depending on the connectivity needs of experiments.  For instance, to *##*
   142    141   
   143         -- mimic a home PC: use the private interface, which has L3 traffic forwarded
   144         -  using NAT to the CN but filtered to ensure network stability.
   145         -- implement a network service: create a public interface, which has a CN
          142  +- mimic a home PC: use the private interface, *##* which has L3 traffic
          143  +  forwarded using NAT to the CN but filtered to ensure network stability. *##*
          144  +- implement a network service: create a public interface, *##* which has a CN
   146    145     address and L3 traffic routed directly to the CN but filtered to ensure
   147         -  network stability.
   148         -- experiment with routing algorithms: create an isolated interface, which uses
   149         -  a VLAN on top of a direct interface.  All L2 traffic is allowed, but only
   150         -  between other slivers of the same slice with isolated interfaces on the same
   151         -  physical link.
          146  +  network stability. *##*
          147  +- experiment with routing algorithms: create an isolated interface, *##* which
          148  +  uses a VLAN on top of a direct interface.  All L2 traffic is allowed, but
          149  +  only between other slivers of the same slice with isolated interfaces on the
          150  +  same physical link.
   152    151   
   153    152   These were demonstrated with BitTorrent and mesh routing experiments at IEEE
   154         -P2P'12 Conference.  Future support is planned for experiments that:
          153  +P2P'12 Conference.  *##* Future support is also planned for experiments that:
   155    154   
   156         -- analyze traffic: create a passive interface to capture traffic on a direct
   157         -  interface, which is filtered and anonymized to ensure network privacy.
   158         -- perform low-level testing: the sliver is given free raw access to a direct
   159         -  interface.  For privacy, isolation and stability reasons this should only be
   160         -  allowed in exceptional occasions.
          155  +- analyze traffic: create a passive interface *##* to capture traffic on a
          156  +  direct interface, which is filtered and anonymized to ensure network
          157  +  privacy. *##*
          158  +- perform low-level testing: *##* the sliver is given free raw access to a
          159  +  direct interface.  For privacy, isolation and stability reasons this should
          160  +  only be allowed in exceptional occasions. *##*
   161    161   
   162         -# List example experiments, add these.
   163    162   Besides experiments run in slices, researchers will soon be able to collect
   164    163   link quality and bandwidth usage measurements of all RDs' interfaces through
   165         -the DLEP protocol.
          164  +the DLEP protocol. *##*
   166    165   
   167    166   Moreover, the server and nodes will soon publish management information
   168         -through an API that would be used to study the testbed itself, or to implement
          167  +through an API that can be used to study the testbed itself, or to implement
   169    168   external services like node monitoring and selection.
   170    169   
   171    170   ** An example experiment
   172         -# Event diagram, hover over components explained.
   173         -To show how the testbed works: two slivers which ping each other.
          171  +to show how the testbed works.  We'll create two slivers which ping each
          172  +other. *##*
   174    173   
   175    174   1. The researcher first contacts the server and registers a slice description
   176    175      which specifies a template for slivers (e.g. Debian Squeeze) and includes
   177         -   data and programs to setup slivers and run experiments.
          176  +   data and programs to setup slivers and run experiments. *##*
   178    177   2. This and all subsequent changes performed by the researcher are stored in
   179         -   the registry, which holds the config of all components in the testbed.
          178  +   the registry, which holds the config of all components in the testbed. *##*
   180    179   3. The researcher chooses two nodes and registers sliver descriptions for them
   181    180      in the previous slice.  Each one includes a public interface to the CN.
   182         -   The researcher tells the server to instantiate the slice.
          181  +   Then the researcher tells the server to instantiate the slice. *##*
   183    182   4. Each of the previous nodes gets a sliver description for it.  If enough
   184    183      resources are available, a container is created by applying the sliver
   185         -   configuration over the selected template.
          184  +   configuration over the selected template. *##*
   186    185   5. Once the researcher knows that slivers have been instantiated, the server
   187         -   can be commanded to activate the slice.
   188         -6. When nodes get instructions to activate slivers they start the containers.
   189         -7. Containers execute the setup and run programs provided by the researcher.
          186  +   can be commanded to activate the slice. *##*
          187  +6. When nodes get instructions to activate slivers they start containers. *##*
          188  +7. Containers execute the setup & run programs provided by the researcher. *##*
   190    189   8. Researchers interact straight with containers if needed (e.g. via SSH) and
   191         -   collect results from them.
          190  +   collect results from them. *##*
   192    191   9. When finished, the researcher tells the server to deactivate and
   193         -   deinstantiate the slice.
   194         -10. Nodes get the instructions and they stop and remove containers.
          192  +   deinstantiate the slice. *##*
          193  +10. Nodes get the instructions and they stop and remove containers. *##*
          194  +
          195  +This is a summary of all the previous steps. *##*
   195    196   
   196    197   * Cooperation between community networks and Community-Lab
   197         -# CN diagram (buildings and cloud).
   198    198   can take different forms.  Given a typical CN like this, with most nodes
   199         -linked using cheap and ubiquitous WiFi technology:
          199  +linked using cheap and ubiquitous WiFi technology: *##*
   200    200   
   201         -# CN diagram extended with CONFINE devices (hover over interesting part).
   202    201   - CN members can provide an existing CD and let CONFINE connect a RD to it via
   203    202     Ethernet.  Experiments are restricted to the application layer unless the
   204         -  node owner allows the RD to include a direct interface (i.e. antenna).
          203  +  node owner allows the RD to include a direct interface (i.e. antenna). *##*
   205    204   - CN members can provide a location and let CONFINE set up a complete node
   206         -  there (CD and RD).  In this way CONFINE helps extend the CN.
          205  +  there (CD and RD).  In this way CONFINE helps extend the CN. *##*
   207    206   - CONFINE can also extend the CN by setting up a physically separated cloud of
   208         -  connected nodes at a site controlled by a partner (e.g. campus).  All kinds
   209         -  of experiments are possible using direct interfaces.  Users should be warned
   210         -  about the research nature of the network.
          207  +  connected nodes.  Experiments in all layers are possible in this setup, but
          208  +  users should be warned about the research nature of the network. *##*
          209  +
          210  +These are only a few ways of cooperation, but more can be envisioned. *##*
   211    211   
   212    212   * Participate!
   213    213   We introduced you to Community-Lab, a new testbed being developed by the
   214    214   CONFINE project to support research that can help CNs become a key part of the
   215    215   Internet in a near future.
          216  +
          217  +More information: http://community-lab.net/, http://confine-project.eu/
   216    218   
   217    219   Community networks and researchers: We look forward to your participation!
   218         -- More information: http://community-lab.net/, http://confine-project.eu/
   219         -- Questions?
          220  +
          221  +Questions? Thanks.
   220    222   
   221    223   # Commenters: Less attention on architecture, more on global working of
   222    224   # testbed.
   223    225   
   224    226   # Ivan: Describe simple experiment, show diagram (UML-like timing diagram?
   225    227   # small animation?) showing the steps from slice creation to instantiation,
   226    228   # activation, deactivation and deletion for that example experiment.

Modified slides.svg from [0cf9ff97ce] to [807c8e33fb].

cannot compute difference between binary files