Community-Lab introduction

Check-in [a413d4ac9a]
Login
Overview
Comment:Some changes suggested by Axel Neumann.

- Rewording of intro to challenges slide (also reversed title). - Indicate interesting features of OpenWrt. - Mention root access to containers. - LXC is used to manage containers. - Change title of experiments slide. - Indicate minimum layer available to experiments. - Mention IEEE P2P'12 demos. - Indicate that DLEP and API experiments don't require slices. - Also, API experiments will soon be supported, but not yet.

Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: a413d4ac9afead45660c5d7fbea71c4279971295
User & Date: ivan on 2012-09-25 22:02:39
Other Links: manifest | tags
Context
2012-09-26
08:10
More correct definition of gateways as entry points to mgmt net. check-in: b44e59136a user: ivan tags: trunk
2012-09-25
22:02
Some changes suggested by Axel Neumann.

- Rewording of intro to challenges slide (also reversed title). - Indicate interesting features of OpenWrt. - Mention root access to containers. - LXC is used to manage containers. - Change title of experiments slide. - Indicate minimum layer available to experiments. - Mention IEEE P2P'12 demos. - Indicate that DLEP and API experiments don't require slices. - Also, API experiments will soon be supported, but not yet. check-in: a413d4ac9a user: ivan tags: trunk

19:16
Put all challenges as "testbed requirement vs. CN characteristic/requirement". check-in: 542baf991d user: ivan tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Modified script.txt from [2552d02c56] to [adbf65b445].

38
39
40
41
42
43
44
45
46

47
48
49
50
51
52
53
...
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
# 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
- support devices ranging from PCs to embedded boards?

................................................................................
  - 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.
  - A separated RD minimizes tampering with CN infrastructure.
    - Also experiments can't crash the CD.
  - Runs OpenWrt firmware customized by CONFINE.
  - Slivers are implemented as lightweight Linux containers.
    - Provide a familiar and flexible env for researchers.
  - Direct interfaces allow low-level interaction of experiments with the CN
    bypassing the CD.
  - 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 registers a slice description
   which specifies a template for slivers (e.g. Debian Squeeze) and includes







|
|
>







 







|

|



|






|




|


|
|

|



|
>







>
>
|
|

|
|
|







38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
...
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
# 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.

* 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?

** Features vs. Lightweight, low cost
- support devices ranging from PCs to embedded boards?

................................................................................
  - 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.
  - A separated RD minimizes tampering with CN infrastructure.
    - Also experiments can't crash the CD.
  - Runs the versatile, light and free OpenWrt distro, customized by CONFINE.
  - Slivers are implemented as lightweight Linux containers.
    - So researchers get root access to a familiar environment.
  - Direct interfaces allow low-level interaction of experiments with the CN
    bypassing the CD.
  - Control software
    - Uses LXC tools to manage containers and enforce resource limits,
      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
# 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 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
  network stability.
- experiment with routing algorithms: create an isolated interface, which uses
  a VLAN on top of a direct interface.  All L2 traffic is allowed, but only
  between other slivers of the same slice with isolated interfaces on the same
  physical link.

These were demonstrated with BitTorrent and mesh routing experiments at IEEE
P2P'12 Conference.  Future support is planned for experiments that:

- 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.

# List example experiments, add these.
Besides experiments run in slices, researchers will soon be able to collect
link quality and bandwidth usage measurements of all RDs' interfaces through
the DLEP protocol.

Moreover, the server and nodes will soon publish management information
through an API that would 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 registers a slice description
   which specifies a template for slivers (e.g. Debian Squeeze) and includes

Modified slides.svg from [0e2fe8a887] to [f13c92b71a].

cannot compute difference between binary files