Community-Lab introduction

Check-in [8bc1c13885]
Login
Overview
Comment:Some notes from Axel for simplifying the presentation.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 8bc1c13885ca25dfb82238b1716253b716b6d4f4
User & Date: ivan on 2012-10-07 14:21:17
Other Links: manifest | tags
Context
2012-10-07
18:06
Applied some suggestions by Axel. check-in: 29ee45c594 user: ivan tags: trunk
14:21
Some notes from Axel for simplifying the presentation. check-in: 8bc1c13885 user: ivan tags: trunk
2012-09-28
09:46
Argh, forgot to include FIRE name with logo. check-in: 896dcfe009 user: ivan tags: trunk, cnbub-2012-1.0.4
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Modified script.txt from [777bb9d984] to [63bbd39286].

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
..
82
83
84
85
86
87
88


89
90
91
92
93
94
95
..
99
100
101
102
103
104
105

106
107
108
109
110
111
112


113
114
115
116
117
118
119
...
131
132
133
134
135
136
137

138
139
140
141
142
143
144
...
166
167
168
169
170
171
172

173
174
175
176
177
178
179
...
193
194
195
196
197
198
199

200
201
202
203
204
205
206
  supporting NGOs) OPLAN Foundation, Pangea. *##*
- Objective: Provide a testbed and associated tools and knowledge for
  researchers to experiment on real community networks. *##*

** Testbed?
- Environment built with real hardware for realistic experimental research on
  network technologies. *##*

- Some wireless testbeds, both indoor and outdoor.
  - Problems: their limited local scale, their unrealistic controlled
    environment, experiments can't share resources simultaneously.
- Internet: PlanetLab, planet-scale testbed with resource sharing on nodes.
  Main inspiration for Community-Lab. *##*

** Community-Lab: a testbed for community networks
- Community-Lab is the testbed developed by CONFINE.
- Integrates and extends the participating community networks.
- Using the FEDERICA research backbone for interconnection. *##*
- All Community-Lab's software and documentation is “free as in freedom” so
  people can use it to setup their own CONFINE testbed.


* Requirements and challenges
A testbed has requirements that are challenged by the unique characteristics
of CNs.  For instance, how to *##*

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

................................................................................
- support testbed spanning different CNs? *##*

* Community-Lab testbed architecture
** Overall architecture
This is the architecture developed by the CONFINE project to handle the
previous challenges.  It applies to all testbeds using CONFINE software. *##*



- A testbed consists of a set of nodes managed by the same server. *##*
  - Server managed by testbed admins.
  - Network and nodes managed by CN members.
  - Node admins must adhere to testbed terms and conditions.
  - This decouples testbed management from infrastructure ownership & mgmt. *##*
- Testbed management traffic uses a tinc mesh VPN:
  - Avoids problems with firewalls and private networks in nodes.
................................................................................
  - They help extend it over multiple CNs by external means (e.g. FEDERICA, the
    Internet).
  - They can also route the management network to the Internet. *##*
- Researchers run experiments in slices spread over several nodes (as
  slivers). *##*

** Slices, slivers and nodes

- These concepts are inspired in PlanetLab.
- A slice is a management concept that groups a set of related slivers.
- A sliver holds the resources (CPU, memory, disk, bandwidth, interfaces…)
  allocated for a slice in a given node.
- A node hosts several slivers at the same time. *##*

** Node architecture


allows the realization of these concepts.  *##* A node consists of a CD, a RD
and a rD connected to the same wired local network. *##*

- The community device
  - Completely normal CN device, so existing ones can be used.
  - routes traffic between the CN and the local network (which runs no routing
    protocol). *##*
................................................................................
      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. *##*

* Experiments support

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 L3 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 L3 traffic routed directly to the CN but filtered to ensure
................................................................................
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
to show how the testbed works.  We'll create two slivers which ping each
other. *##*


1. The researcher first contacts the server and registers 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 registers sliver descriptions for them
   in the previous slice.  Each one includes a public interface to the CN.
................................................................................

This is a summary of all the previous steps. *##*

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


- 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.  Experiments in all layers are possible in this setup, but







>













>







 







>
>







 







>







>
>







 







>







 







>







 







>







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
..
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
...
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
...
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
...
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
...
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
  supporting NGOs) OPLAN Foundation, Pangea. *##*
- Objective: Provide a testbed and associated tools and knowledge for
  researchers to experiment on real community networks. *##*

** Testbed?
- Environment built with real hardware for realistic experimental research on
  network technologies. *##*
# Axel: Insert headline "Examples of existing testbeds".
- Some wireless testbeds, both indoor and outdoor.
  - Problems: their limited local scale, their unrealistic controlled
    environment, experiments can't share resources simultaneously.
- Internet: PlanetLab, planet-scale testbed with resource sharing on nodes.
  Main inspiration for Community-Lab. *##*

** Community-Lab: a testbed for community networks
- Community-Lab is the testbed developed by CONFINE.
- Integrates and extends the participating community networks.
- Using the FEDERICA research backbone for interconnection. *##*
- All Community-Lab's software and documentation is “free as in freedom” so
  people can use it to setup their own CONFINE testbed.

# Axel: Headline: for what?
* Requirements and challenges
A testbed has requirements that are challenged by the unique characteristics
of CNs.  For instance, how to *##*

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

................................................................................
- support testbed spanning different CNs? *##*

* Community-Lab testbed architecture
** Overall architecture
This is the architecture developed by the CONFINE project to handle the
previous challenges.  It applies to all testbeds using CONFINE software. *##*

# Axel: Introduce scenario: CNs, nodes, admins.
# Ivan: Don't zoom.
- A testbed consists of a set of nodes managed by the same server. *##*
  - Server managed by testbed admins.
  - Network and nodes managed by CN members.
  - Node admins must adhere to testbed terms and conditions.
  - This decouples testbed management from infrastructure ownership & mgmt. *##*
- Testbed management traffic uses a tinc mesh VPN:
  - Avoids problems with firewalls and private networks in nodes.
................................................................................
  - They help extend it over multiple CNs by external means (e.g. FEDERICA, the
    Internet).
  - They can also route the management network to the Internet. *##*
- Researchers run experiments in slices spread over several nodes (as
  slivers). *##*

** Slices, slivers and nodes
# Axel: Reverse, from PoV of researcher: select nodes, run as slivers, gruop in slices.
- These concepts are inspired in PlanetLab.
- A slice is a management concept that groups a set of related slivers.
- A sliver holds the resources (CPU, memory, disk, bandwidth, interfaces…)
  allocated for a slice in a given node.
- A node hosts several slivers at the same time. *##*

** Node architecture
# Axel: More stress on node itself.
# Ivan: Don't zoom!!
allows the realization of these concepts.  *##* A node consists of a CD, a RD
and a rD connected to the same wired local network. *##*

- The community device
  - Completely normal CN device, so existing ones can be used.
  - routes traffic between the CN and the local network (which runs no routing
    protocol). *##*
................................................................................
      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. *##*

* Experiments support
# Axel: Turn around as of mail: from PoV of researcher: 1) testbed through API, choose nodes, 2) login OoB, 3) auto creation, 4) specific interfaces.
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 L3 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 L3 traffic routed directly to the CN but filtered to ensure
................................................................................
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
to show how the testbed works.  We'll create two slivers which ping each
other. *##*

# Use summary diagram, maybe colorise labels.
1. The researcher first contacts the server and registers 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 registers sliver descriptions for them
   in the previous slice.  Each one includes a public interface to the CN.
................................................................................

This is a summary of all the previous steps. *##*

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

# Axel: Keep CN on sight, explain RDs and RD links (DIs) in cloud.
- 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.  Experiments in all layers are possible in this setup, but