Community-Lab introduction

Check-in [a0366fa17f]
Login
Overview
Comment:Streamlined several points after reading, simplified ping example.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: a0366fa17f8d143bd1559f84ecc33f19a364e6d0
User & Date: ivan on 2012-09-20 11:41:53
Other Links: manifest | tags
Context
2012-09-20
12:25
Minor changes to testbeds slide. check-in: d110a1a7dc user: ivan tags: trunk
11:41
Streamlined several points after reading, simplified ping example. check-in: a0366fa17f user: ivan tags: trunk
09:23
Added FP7 and FIRE logos to slides. check-in: 65ca24d918 user: ivan tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

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

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

39
40
41
42
43
44


45
46
47
48
49
50
51
52
53

54
55
56
57
58


59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

78
79



80
81
82
83
84
85
86
87
88
89
90

91
92
93

94
95
96
97
98
99


100
101
102
103
104
105
106
107

108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147






148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166

167
168
169
170

171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
* Introduction
** Community networks
- Infrastructure deployed by organized groups of people for self-provision of
  broadband networking that works and grows according to their own interests.
- Characteristics: Open participation, open and transparent management,
  distributed ownership.
- CNs are of strategic importance for the universal availability of broadband
  networking (according to the European Digital Agenda).
- A challenge: How to support the growth and sustainability of community
  networks by providing the means to conduct experimentally driven research.

** The CONFINE project: Community Networks Testbed for the Future Internet
- Takes on the previous challenge.
- Project supported by the European Community Framework Programme 7 within the
  Future Internet Research and Experimentation Initiative (FIRE).

- Partners (list with logos): (community networks) guifi.net, Funkfeuer,
  Athens Wireless Metropolitan Network; (research centres) Universitat
  Politècnica de Catalunya, Fraunhofer Institute for Communication,
  Information Processing and Ergonomics, Interdisciplinary Institute for
  Broadband Technology; (NGOs) the OPLAN Foundation, Pangea.
- Objectives: Provide a testbed and associated tools and knowledge for
  researchers to experiment on real community networks.

** Testbeds
- Environments built with real hardware for realistic experimental research on
  network technologies (instead of simulations).
- Wireless: (outdoor) Berlin RoofNet, MIT Roofnet; (indoor) IBBT's w-iLab.t,
  CERTH's NITOS, WINLAB's ORBIT.  Limited local scale, controlled environment,
  no resource sharing between experiments.
- Internet: PlanetLab, planet-scale testbed with resource sharing on nodes.
  Main inspiration for Community-Lab.

** Community-Lab: a testbed for community networks
- The testbed developed by CONFINE.
- Integrates and extends three Community Networks: guifi.net, FunkFeuer, AWMN.
# Node maps here for CNs with captures from node DBs.

- Also nodes in participating research centres.
- Linked together over the FEDERICA academic backbone.
- All its software and documentation is released under Free licenses, anyone
  can setup a CONFINE testbed like Community-Lab.

* Challenges and requirements


** Simple management vs. Distributed node ownership
- How to manage devices belonging to diverse owners.

** Features vs. Lightweight, low cost (free & open)
- Devices ranging from PCs to embedded boards.
- Need light system able to run on very different devices.

** Heterogeneity vs. Compatibility
- Some devices allow hacking while others don't.

- Diverse connectivity and link technologies (wireless, wired, fiber).

** Familiarity & flexibility vs. System stability
- Researchers prefer a familiar Linux env with root access.
- But experiments sharing the same node must be isolated.


# Frozen tower.
- Accessing node locations can be hard, so keep node stability to avoid
  in-place maintenance.

** Flexibility vs. Network stability
- Network experiments running on nodes in a production network.
- Allow interaction at the lowest possible layer of the CN while not
  disrupting or overusing it.

** Traffic collection vs. Privacy of CN users
- Experiments performing traffic collection and characterization.
- Avoid researchers spying on users' data.

** Link instability vs. Management robustness
- Management must deal with frequent network outages in the CN.

** Reachability vs. IP address provisioning
- Testbed spanning different CNs.
- IPv4 scarcity and incompatibility between CNs, lack of IPv6 support.


* 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 (partialy implemented).
- The recovery device can force a hardware reboot of the RD from several
  triggers and help with upgrade and recovery (not implemented).

* Supported experiments
# Node simplified diagram, hover to interesting parts.
Researchers can configure slivers with different types of network interfaces
depending on the connectivity needs of experiments:

- Home PC-like access: a private interface with traffic forwarded using NAT to
  the CN (filtered to ensure network stability).
- Internet service: a public interface (with a public CN address) with traffic
  routed directly to the CN (filtered to ensure network stability).
- Traffic analysis (not implemented): a passive interface capturing traffic on
  a direct interface (filtered and anonymized to ensure network privacy).
- Routing: an isolated interface using a VLAN on top of a direct interface.
  All traffic is allowed, but it can only reach other slivers of the same
  slice with isolated interfaces on the same physical link.
- Low-level testing (not implemented): the sliver is given raw access to the






  interface.  For privacy, isolation and stability reasons this should only be
  allowed in exceptional occasions.

Besides low level access, RDs also offer link quality and bandwidth usage
measurements for all their interfaces through DLEP (available soon).

Finally, the server and nodes publish management information through an API
that can be used to study the testbed itself or to implement external services
(like node monitoring and selection).

** An example experiment
# Event diagram, hover over components explained.
To show how the testbed works: two slivers, one of them pings the other one.
Let's call them the source and target sliver, respectively.

1. The researcher first contacts the server and creates a slice description
   which specifies a template for slivers (e.g. Debian Squeeze i386).  The
   researcher attaches experiment data including a program to setup slivers
   for the experiments and another one to run them.

2. This and all subsequent changes initiated by the researcher are stored in
   the registry, which holds the config of all components in the testbed.
3. The researcher chooses a couple of nodes and creates sliver descriptions
   for them belonging to the previous slice.  Both sliver descriptions include

   a public interface to the CN and user-defined properties to mark slivers as
   either source or target.
4. Each of the previous nodes gets a sliver description for it.  If enough
   resources are available, a container is created by applying the desired
   configuration over the selected template.
5. Once the researcher knows that slivers have been instantiated, the server
   can be commanded to activate the slice.
6. When nodes get instructions to activate slivers they start the containers.
7. Containers execute the experiment's setup and run programs.  The programs
   query sliver properties to decide whether to act as source or target.
8. Researchers interact straight with containers if needed (e.g. via SSH) and
   collect results from them.
9. When finished, the researcher tells the server to deactivate and
   deinstantiate the slice.
10. Nodes get the instructions and they stop and remove containers.

* Cooperation between community networks and Community-Lab
# CN diagram (buildings and cloud).
There are different ways.  Given a typical CN like this, with most nodes
linked using cheap and ubiquitous WiFi technology:

# CN diagram extended with CONFINE devices (hover over interesting part).
- CN members can provide an existing CD and let CONFINE connect a RD to it via
  Ethernet.  Experiments are restricted to the application layer unless the
  node owner allows the RD to include a direct interface (i.e. antenna).
- CN members can provide a location and let CONFINE set up a complete node
  there (CD and RD).  All but low-level experiments are possible using direct
  interfaces.  In this way CONFINE helps extend the CN.
- CONFINE can also extend the CN by setting up a physically separated cloud of
  connected nodes at a site controlled by a partner (e.g. campus).  All kinds
  of experiments are possible using direct interfaces.  Users are warned about
  the experimental nature of the network.

* Participate!
We introduced you to Community-Lab, a new testbed being developed by the
CONFINE project to support research targeted to allow CNs to become a key part
of Internet infrastructure in the future.

Community networks and researchers: We look forward to your participation!
- More information: http://community-lab.net/, http://confine-project.eu/
- Questions?

# Commenters: Less attention on architecture, more on global working of
# testbed.







|
|
|





>
|
|
|
|
|
|




|
|
|
|





<

>
|
|
|
|


>
>

|


|
<


<
>
|



|
>
>

<
<


|
|
|


|
|


|


<
|
>


>
>
>





|
|



|
>


<
>



|


>
>
|



<
<


>



|
|



|
|












|
|




|

|
|
|
|
|
|
|
|
|
<
>
>
>
>
>
>



|
|


|
|



|
<


|
<
<
>
|

<
<
>
|
<

|




|
<








|







<
|


|
|



|
|







3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

53
54

55
56
57
58
59
60
61
62
63


64
65
66
67
68
69
70
71
72
73
74
75
76
77

78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98

99
100
101
102
103
104
105
106
107
108
109
110
111


112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153

154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172

173
174
175


176
177
178


179
180

181
182
183
184
185
186
187

188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203

204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
* Introduction
** Community networks
- Infrastructure deployed by organized groups of people for self-provision of
  broadband networking that works and grows according to their own interests.
- Characteristics: Open participation, open and transparent management,
  distributed ownership.
- CNs are of strategic importance for the universal availability of broadband
  networking (an initiative for the European Digital Agenda).
- A challenge for researchers: How to support the growth and sustainability of
  CNs by providing the means to conduct experimentally driven research.

** The CONFINE project: Community Networks Testbed for the Future Internet
- Takes on the previous challenge.
- Project supported by the European Community Framework Programme 7 within the
  Future Internet Research and Experimentation Initiative (FIRE).
# List partner's logos.
- Partners: (community networks) guifi.net, Funkfeuer, Athens Wireless
  Metropolitan Network; (research centres) Universitat Politècnica de
  Catalunya, Fraunhofer Institute for Communication, Information Processing
  and Ergonomics, Interdisciplinary Institute for Broadband Technology; (NGOs)
  OPLAN Foundation, Pangea.
- Objective: Provide a testbed and associated tools and knowledge for
  researchers to experiment on real community networks.

** Testbeds
- Environments built with real hardware for realistic experimental research on
  network technologies.
- Wireless, both outdoor (HU's Berlin RoofNet, MIT Roofnet) and indoor (IBBT's
  w-iLab.t, CERTH's NITOS, WINLAB's ORBIT).  Problems: limited local scale,
  controlled environment, no resource sharing between experiments.
- Internet: PlanetLab, planet-scale testbed with resource sharing on nodes.
  Main inspiration for Community-Lab.

** Community-Lab: a testbed for community networks
- The testbed developed by CONFINE.

# Node maps here for CNs with captures from node DBs.
- Integrates and extends three community networks: guifi.net, FunkFeuer, AWMN.
- Also includes nodes in participating research centres.
- All linked together over the FEDERICA research backbone.
- All its software and documentation is “free as in freedom”, anyone can setup
  a CONFINE testbed like Community-Lab.

* Challenges and requirements
CNs pose unique challenges for a testbed.  How to

** Simple management vs. Distributed node ownership
- manage devices belonging to diverse owners?

** Features vs. Lightweight, low cost (free & open)
- support devices ranging from PCs to embedded boards?


** Heterogeneity vs. Compatibility

- work with devices which allow little customization?
- support diverse connectivity and link technologies (wireless, wired, fiber)?

** Familiarity & flexibility vs. System stability
- Researchers prefer a familiar Linux env with root access.
- isolate experiments that share the same node?
- keep nodes stable to avoid in-place maintenance?  Accessing node locations
  can be hard.
# Frozen tower.



** Flexibility vs. Network stability
- Network experiments run on nodes in a production network.
- allow interaction at the lowest possible layer of the CN while not
  disrupting or overusing it?

** Traffic collection vs. Privacy of CN users
- allow experiments performing traffic collection and characterization?
- avoid researchers spying on users' data?

** Link instability vs. Management robustness
- deal with frequent network outages in the CN when managing nodes?

** Reachability vs. IP address provisioning

- We have IPv4 scarcity and incompatibility between CNs, lack of IPv6 support.
- support testbed spanning different CNs?

* Community-Lab testbed architecture
This is the architecture developed by the CONFINE project to handle the
previous challenges.

** 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 CN members.
  - Node admins must adhere to testbed terms and 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.
  - Mgmt network uses IPv6 to avoid address scarcity and incompatibility
    between CNs.
  - Short-lived mgmt connections make components mostly autonomous and
    tolerant to link instability.

- Gateways allow a testbed to span multiple CNs.
  - 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
# Diagram: Slices and slivers, two or three nodes with a few slivers on them,
# each with a color identifying it with a slice.)
- These concepts are 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.



** Node architecture
allows the realization of these concepts.  A node consists of:
# 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 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 (partialy implemented).
- The recovery device (not implemented) can force a remote hardware reboot of
  the RD in case it hangs.  It also helps with upgrade and recovery.

* Supported experiments
# Node simplified diagram, hover to interesting parts.
Researchers can configure slivers with different types of network interfaces
depending on the connectivity needs of experiments.  For instance, to

- mimic a home PC: use the private interface, which has traffic forwarded
  using NAT to the CN but filtered to ensure network stability.
- implement a network service: create a public interface, which has a CN
  address and traffic routed directly to the CN but filtered to ensure network
  stability.
- experiment with routing algorithms: create an isolated interface, which uses
  a VLAN on top of a direct interface.  All traffic is allowed, but only
  between other slivers of the same slice with isolated interfaces on the same
  physical link.


Not yet implemented:

- analyze traffic: create a passive interface to capture traffic on a direct
  interface, which is filtered and anonymized to ensure network privacy.
- perform low-level testing: the sliver is given free raw access to a direct
  interface.  For privacy, isolation and stability reasons this should only be
  allowed in exceptional occasions.

RDs will soon be able to provide link quality and bandwidth usage measurements
for all their interfaces through the DLEP protocol.

Finally, the server and nodes publish management information through an API
that can be used to study the testbed itself, or to implement external
services like node monitoring and selection.

** An example experiment
# Event diagram, hover over components explained.
To show how the testbed works: two slivers which ping each other.


1. The researcher first contacts the server and creates a slice description
   which specifies a template for slivers (e.g. Debian Squeeze) and includes


   data and programs to setup slivers and run experiments.
2. This and all subsequent changes performed by the researcher are stored in
   the registry, which holds the config of all components in the testbed.


3. The researcher chooses two nodes and adds sliver descriptions for them in
   the previous slice.  Each one includes a public interface to the CN.

4. Each of the previous nodes gets a sliver description for it.  If enough
   resources are available, a container is created by applying the sliver
   configuration over the selected template.
5. Once the researcher knows that slivers have been instantiated, the server
   can be commanded to activate the slice.
6. When nodes get instructions to activate slivers they start the containers.
7. Containers execute the setup and run programs provided by the researcher.

8. Researchers interact straight with containers if needed (e.g. via SSH) and
   collect results from them.
9. When finished, the researcher tells the server to deactivate and
   deinstantiate the slice.
10. Nodes get the instructions and they stop and remove containers.

* Cooperation between community networks and Community-Lab
# CN diagram (buildings and cloud).
can take different forms.  Given a typical CN like this, with most nodes
linked using cheap and ubiquitous WiFi technology:

# CN diagram extended with CONFINE devices (hover over interesting part).
- CN members can provide an existing CD and let CONFINE connect a RD to it via
  Ethernet.  Experiments are restricted to the application layer unless the
  node owner allows the RD to include a direct interface (i.e. antenna).
- CN members can provide a location and let CONFINE set up a complete node

  there (CD and RD).  In this way CONFINE helps extend the CN.
- CONFINE can also extend the CN by setting up a physically separated cloud of
  connected nodes at a site controlled by a partner (e.g. campus).  All kinds
  of experiments are possible using direct interfaces.  Users should be warned
  about the research nature of the network.

* Participate!
We introduced you to Community-Lab, a new testbed being developed by the
CONFINE project to support research that can help CNs become a key part of the
Internet in a near future.

Community networks and researchers: We look forward to your participation!
- More information: http://community-lab.net/, http://confine-project.eu/
- Questions?

# Commenters: Less attention on architecture, more on global working of
# testbed.