Testbed architecture shows two community networks (CNs) with several community nodes connected to them. These community nodes are integral parts of a CN and form the actual network infrastructure by relaying other nodes’ traffic while respecting the rules and peering agreements of the CN. The community nodes and the network infrastructure itself is managed by community members (depicted as the golden person on the right).
The architecture of a CONFINE testbed (source)
In this context, a CONFINE testbed consists of a testbed registry (hosted by a set of servers) and a set of associated testbed nodes spread among the existing community nodes of one or several CNs. The testbed nodes follow the configuration stored in its testbed registry.
A CONFINE testbed registry is a configuration store, uniquely associated with a testbed, which may be distributed or replicated among a number of servers. There is at least one registry server per testbed, and all its registry servers contain equivalent configuration data to be accessed by testbed nodes and users through an API. A server is most probably directly reachable from inside a CN using this network’s IP addresses, and usually also from the Internet using public IP addresses. Testbed registry servers are managed by testbed operators (the red person in the centre of Testbed architecture) who need not be community members.
A CONFINE testbed node is a device that plugs behind existing community nodes and implements access control, resource isolation and management capabilities with the objective to grant external users a confined acces to the node’s processing and network resources, while enforcing respect of the CN rules. Nodes (which may be owned by community members as depicted in Testbed architecture) are managed by node administrators (a.k.a. "technicians") who must adhere to the testbed policies and conditions, thus decoupling testbed management from infrastructure ownership and management. The architecture of CONFINE testbed nodes is described in Node architecture.
Finally, applications (like experiments and services) are managed by slice administrators (a.k.a. "researchers", the blue person on the left of Testbed architecture) who use testbed registry to configure their applications and run them in testbed nodes, possibly with direct interaction.