Differences From
Artifact [f759c594c4]:
26 26 researchers to experiment on real community networks.
27 27
28 28 ** Testbeds
29 29 - Environments built with real hardware for realistic experimental research on
30 30 network technologies (instead of simulations).
31 31 - Wireless: Berlin RoofNet, MIT Roofnet (outdoor); IBBT's w-iLab.t, CERTH's
32 32 NITOS, WINLAB's ORBIT (indoor). Limited local scale, controlled
33 - environment, no resource sharing mechanisms.
33 + environment, no resource sharing between experiments.
34 34 - Internet: PlanetLab, planet-scale testbed with resource sharing on nodes.
35 35 Main inspiration for Community-Lab.
36 36
37 37 ** Community-Lab: a testbed for community networks
38 38 - The testbed developed by CONFINE.
39 39 - Integrates and extends three Community Networks: guifi.net, FunkFeuer, AWMN.
40 40 # Node maps here for CNs with captures from node DBs.
................................................................................
41 41 - Also nodes in participating research centres.
42 42 - Linked together over the FEDERICA backbone.
43 43 - All its software and documentation is released under Free licenses, anyone
44 44 can setup a CONFINE testbed like Community-Lab.
45 45
46 46 * Challenges and requirements
47 47 ** Simple management vs. Distributed node ownership
48 -- In contrast with esp. indoors testbeds that belong wholly to the same
48 +- In contrast with e.g. indoors testbeds that belong wholly to the same
49 49 entity.
50 50
51 51 ** Features vs. Lightweight, low cost (free & open)
52 52 - Devices ranging from PCs to embedded boards.
53 -- Need light system able to run on a variety of devices.
53 +- Need light system able to run on very different devices.
54 54
55 55 ** Familiarity & flexibility vs. System stability
56 56 - Familiar Linux env with root access to researchers.
57 57 - Keep env isolation (nodes are shared by experiments).
58 58 - Keep node stability (to avoid in-place maintenance, some difficult to reach
59 59 node locations).
60 60 # Frozen tower.
................................................................................
85 85 # Move over overlay diagram less overlay connections plus overlay network.
86 86 - A testbed consists of a set of nodes managed by the same server.
87 87 - Server managed by testbed admins.
88 88 - Network and node managed by node admins (usually node owners).
89 89 - Node admins must adhere to a set of conditions.
90 90 - Solves management vs. ownersip problem.
91 91 - All components in testbed reachable via management network (tinc mesh VPN).
92 - - Avoids problems with firewalls and private networks.
92 + - Avoids problems with firewalls and private networks in nodes.
93 93 - Avoids address scarcity and incompatibility (well structured IPv6 schema).
94 - - Public addresses still used for experiments when available.
94 + - Public CN addresses still used for experiments when available.
95 95 - Gateways connect disjoint parts of the management network.
96 96 - Allows a testbed spanning different CNs and islands through external means
97 97 (e.g. FEDERICA, the Internet).
98 98 - A gateway reachable from the Internet can expose the management network
99 99 (if using public addresses).
100 100 - A researcher runs the experiments of a slice in slivers each running in a
101 101 different node…
102 102
103 103 ** Nodes, slices and slivers
104 104 - …a model inspired in PlanetLab.
105 -- A slice groups a set of related slivers.
105 +- The slice (a management concept) groups a set of related slivers.
106 106 - A sliver holds the resources (CPU, memory, disk, bandwidth, interfaces…)
107 107 allocated for a slice in a given node.
108 108 # Diagram: Slices and slivers, two or three nodes with a few slivers on them,
109 109 # each with a color identifying it with a slice.)
110 110
111 111 ** Node architecture
112 112 Mostly autonomous, no long-running connections to server, asynchronous
................................................................................
113 113 operation: robust under link instability.
114 114 # Node simplified diagram, hover to interesting parts.
115 115 - The community device
116 116 - Completely normal CN network device, possibly already existing.
117 117 - Routes traffic between the CN and devices in the node's local network
118 118 (wired, runs no routing protocol).
119 119 - The research device
120 - - More powerful than CD, it runs OpenWrt (Attitude Adjustment) firmware
121 - customized by CONFINE.
120 + - More powerful than CD, it runs OpenWrt firmware customized by CONFINE.
122 121 - Experiments run here. The separation between CD and RD allows:
123 122 - Minumum CONFINE-specific tampering with CN hardware.
124 123 - Minimum CN-specific configuration for RDs.
125 124 - Greater compatibility and stability for the CN.
126 125 - Slivers are implemented as Linux containers.
127 126 - LXC: lightweight virtualization (in Linux mainstream).
128 - - Easier resource limitation, resource isolation and node stability.
129 127 - Provides a familiar env for researchers.
128 + - Easier resource limitation, resource isolation and node stability.
130 129 - Control software
131 130 - Manages containers and resource isolation through LXC tools.
132 131 - Ensures network isolation and stability through traffic control (QoS)
133 132 and filtering (from L2 upwards).
134 133 - Protects users' privacy through traffic filtering and anonimization.
135 134 - Optional, controlled direct interfaces for experiments to interact
136 135 directly with the CN (avoiding the CD).
................................................................................
144 143 - Home computer behind a NAT router: a private interface with traffic
145 144 forwarded using NAT to the CN. Outgoing traffic is filtered to ensure
146 145 network stability.
147 146 - Publicly open service: a public interface (with a public CN address) with
148 147 traffic routed directly to the CN. Outgoing traffic is filtered to ensure
149 148 network stability.
150 149 - Traffic capture: a passive interface using a direct interface for capture.
151 - Incoming traffic is filtered and anonimized by control software.
150 + Incoming traffic is filtered and anonymized by control software.
152 151 - Routing: an isolated interface using a VLAN on top of a direct interface.
153 152 It only can reach other slivers of the same slice with isolated interfaces
154 153 on the same link. All traffic is allowed.
155 154 - Low-level testing: the sliver is given raw access to the interface. For
156 155 privacy, isolation and stability reasons this should only be allowed in
157 156 exceptional occasions.
158 157
................................................................................
164 163 1. The researcher first contacts the server and creates a slice description
165 164 which specifies a template for slivers (e.g. Debian Squeeze i386).
166 165 Experiment data is attached including a program to setup the experiment and
167 166 another one to run it.
168 167 2. The server updates the registry which holds all definitions of testbed,
169 168 nodes, users, slices, slivers, etc.
170 169 3. The researcher chooses a couple of nodes and creates sliver descriptions
171 - for them in the previous slice. Both sliver descriptions include a public
172 - interface to the CN and user-defined properties for telling apart the
173 - source sliver from the target one. Sliver descriptions go to the registry.
170 + for them belonging to the previous slice. Both sliver descriptions include
171 + a public interface to the CN and user-defined properties for telling apart
172 + the source sliver from the target one. Sliver descriptions go to the
173 + registry.
174 174 4. Each of the previous nodes gets a sliver description for it. If enough
175 175 resources are available, a container is created with the desired
176 176 configuration.
177 177 5. Once the researcher knows that slivers have been instantiated, the server
178 178 can be commanded to activate the slice. The server updates the registry.
179 179 6. When nodes get instructions to activate slivers they start the containers.
180 180 7. Containers run the experiment setup program and the run program. The
181 181 programs query sliver properties to decide their behaviour.
182 -8. Researchers interact with containers if needed (e.g. via SSH) and collect
183 - results straight from them.
182 +8. Researchers interact straight with containers if needed (e.g. via SSH) and
183 + collect results from them.
184 184 9. When finished, the researcher tells the server to deactivate and
185 185 deinstantiate the slice.
186 186 10. Nodes get the instructions and they stop and remove containers.
187 187
188 188 At all times there can be external services interacting with researchers,
189 189 server, nodes and slivers, e.g. to help choosing nodes, monitor nodes or
190 190 collect results.
191 191
192 192 * Community-Lab integration in existing community networks
193 193 # CN diagram (buildings and cloud).
194 -A typical CN looks like this, with most nodes linked using WiFi technology
195 -(cheap and ubiquitous), but sometimes others as optical fiber. The CONFINE
196 -project follows three strategies taking into account that CNs are production
197 -networks with distributed ownership:
194 +A typical CN looks like this, with most nodes linked using cheap and
195 +ubiquitous WiFi technology (and less frequently Ethernet, optical fiber or
196 +others). The CONFINE project follows three strategies taking into account
197 +that CNs are production networks with distributed ownership:
198 198
199 199 # CN diagram extended with CONFINE devices (hover over interesting part).
200 200 - Take an existing node owned by CN members, CONFINE provides a RD and
201 - connects it via Ethernet. Experiments are restricted to the application
202 - layer unless the node owner allows the RD to include a direct interface
203 - (i.e. antenna).
201 + connects it via Ethernet to the CD. Experiments are restricted to the
202 + application layer unless the node owner allows the RD to include a direct
203 + interface (i.e. antenna).
204 204 - Extend the CN with complete nodes, CONFINE provides both the CD and the RD
205 205 and uses a CN member's location. All but low-level experiments are possible
206 206 using direct interfaces.
207 207 - Set up a physically separated cloud of nodes, CONFINE extends the CN with a
208 208 full installation of connected nodes at a site controlled by a partner
209 209 (e.g. campus). All kinds of experiments are possible using direct
210 210 interfaces. Users are warned about the experimental nature of the network.
211 211
212 212 * Recap
213 213
214 214 - Community networks are an emerging field to provide citizens with
215 215 connectivity in a sustainable and distributed manner in which the owners of
216 216 the networks are the users themselves.
217 -- Research on this field is necessary to support CNs growth while improving
217 +- Research on this field is necessary to support CNs' growth while improving
218 218 their operation and quality.
219 219 - Experimental tools are still lacking because of the peculiarities of CNs.
220 220 - The CONFINE project aims to fill this gap by deploying Community-Lab, a
221 - testbed for community networks inside existing community networks.
221 + testbed for existing community networks.
222 222
223 223 # Commenters: Less attention on architecture, more on global working of
224 224 # testbed.
225 225
226 226 # Ivan: Describe simple experiment, show diagram (UML-like timing diagram?
227 227 # small animation?) showing the steps from slice creation to instantiation,
228 228 # activation, deactivation and deletion for that example experiment.