CONFINE testbeds work following a pull strategy: components in the testbed query the testbed registry in order to discover changes to their configuration and new actions to perform. In fact, this registry holds the configuration of all elements in the testbed, including users, nodes and slices.
The registry is kept by servers, and it is updated by testbed users (both node and slice administrators, a.k.a. technicians and researchers) by means of their interaction with registry servers (e.g. through a web portal or using specific tools). The configuration information in the registry is complemented by state information kept by nodes.
All this contrasts with the push strategy where servers actively contact nodes to manage them. However, the experience in other testbeds like PlanetLab has shown that this centralized approach of keeping state puts much complexity and load onto servers, especially when nodes become unreachable because of network shortages (which are common in wireless CNs) and commands must be retried. On the contrary, the pull strategy distributes this complexity and load among nodes in the edges of the testbed. It also eases the replication of configuration, which changes less rapidly than state.
Both configuration and state information are published by servers and nodes through a simple REST API (see CONFINE REST API for a detailed specification). Since all testbed management data is thus made publicly available, it can be used to study the workings of the testbed itself or to build external services like testbed node monitors.
This API is actually the protocol used by testbed components for implementing the pull strategy for testbed management. In particular, the registry API provided by servers also allows authenticated testbed users to update information in the registry. Testbed management shows the different management interactions between users, nodes and the registry through the REST API and other means.
Management interactions in a CONFINE testbed (source)
The REST API is implemented on top of HTTP secured with SSL so that recipients can be sure that the information was not forged. Using HTTP allows management connections to be short-lived, which helps tolerate intermittent network failures.