Overview
Comment: | More compact versions of testbed and node architecture and connectivity. |
---|---|
Downloads: | Tarball | ZIP archive | SQL archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA1: |
6f21a572580b718bc4a6d77ccd9d15fb |
User & Date: | ivan on 2012-09-18 22:37:26 |
Other Links: | manifest | tags |
Context
2012-09-19
| ||
07:58 | Added diagram of testbed component interactions. check-in: 48254b948d user: ivan tags: trunk | |
2012-09-18
| ||
22:37 | More compact versions of testbed and node architecture and connectivity. check-in: 6f21a57258 user: ivan tags: trunk | |
17:48 | Mention the template on sliver creation. check-in: d01b126555 user: ivan tags: trunk | |
Changes
Modified script.txt from [4fedc4f1ce] to [0c2f6f03b8].
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 |
* 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 node owners). - Node admins must adhere to a set of conditions. - Solves management vs. ownersip problem. - All components in testbed reachable via management network (tinc mesh VPN). - Avoids problems with firewalls and private networks in nodes. - Avoids address scarcity and incompatibility (well structured IPv6 schema). - Public CN addresses still used for experiments when available. - Gateways connect disjoint parts of the management network. - Allows a testbed spanning different CNs and islands through external means (e.g. FEDERICA, the Internet). - A gateway reachable from the Internet can expose the management network (if using public addresses). - 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 Mostly autonomous, no long-running connections to server, asynchronous operation: robust under link instability. # Node simplified diagram, hover to interesting parts. - The community device - Completely normal CN network device, possibly already existing. - Routes traffic between the CN and devices in the node's local network (wired, runs no routing protocol). - The research device - More powerful than CD, it runs OpenWrt firmware customized by CONFINE. - Experiments run here. The separation between CD and RD allows: - Minumum CONFINE-specific tampering with CN hardware. - Minimum CN-specific configuration for RDs. - Greater compatibility and stability for the CN. - Slivers are implemented as Linux containers. - LXC: lightweight virtualization (in Linux mainstream). - Provides a familiar env for researchers. - Easier resource limitation, resource isolation and node stability. - Control software - Manages containers and resource isolation through LXC tools. - Ensures network isolation and stability through traffic control (QoS) and filtering (from L2 upwards). - Protects users' privacy through traffic filtering and anonimization. - Optional, controlled direct interfaces for experiments to interact directly with the CN (avoiding the CD). - The recovery device can force a hardware reboot of the RD from several triggers and help with upgrade and recovery. ** Node and sliver connectivity # Node simplified diagram, hover to interesting parts. Slivers can be configured with different types of network interfaces depending on what connectivity researchers need for experiments: - Home computer behind a NAT router: a private interface with traffic forwarded using NAT to the CN. Outgoing traffic is filtered to ensure network stability. - Publicly open service: a public interface (with a public CN address) with traffic routed directly to the CN. Outgoing traffic is filtered to ensure network stability. - Traffic capture: a passive interface using a direct interface for capture. Incoming traffic is filtered and anonymized by control software. - Routing: an isolated interface using a VLAN on top of a direct interface. It only can reach other slivers of the same slice with isolated interfaces on the same link. All traffic is allowed. - Low-level testing: the sliver is given raw access to the interface. For privacy, isolation and stability reasons this should only be allowed in exceptional occasions. |
| | | | | | | | | | < < < | | | < < > > | | < > > | | > | | | | | < < | < | < | |
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 |
* 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. - The recovery device can force a hardware reboot of the RD from several triggers and help with upgrade and recovery. ** Node and sliver connectivity # Node simplified diagram, hover to interesting parts. Slivers can be configured with different types of network interfaces depending on what connectivity researchers need for experiments: - Home computer behind a NAT router: a private interface with traffic forwarded using NAT to the CN and filtered to ensure network stability. - Publicly open service: a public interface (with a public CN address) with traffic routed directly to the CN and filtered to ensure network stability. - Traffic capture: a passive interface using a direct interface for capture. Incoming traffic is filtered and anonymized to ensure network privacy. - Routing: an isolated interface using a VLAN on top of a direct interface. It only can reach other slivers of the same slice with isolated interfaces on the same link. All traffic is allowed. - Low-level testing: the sliver is given raw access to the interface. For privacy, isolation and stability reasons this should only be allowed in exceptional occasions. |