The central administration and management of the DFN-GVS service is handled by the CSF (Central Server Facility), which consists of three Dell 530 servers and performs gateway (CSF1), storage (CSF2) and orchestration (CSF0) tasks. The so-called GVS PoPs (Point of Presence), which contain the actual resources of the individual user testbeds, are managed here. A Central Server Facility and any number of GTS PoPs are required for the GVS domain. Initially, a CSF and a PoP are planned for the Erlangen site.

In addition to the actual compute resources, which are provided by VMs and BMSs, the test environments can also be supplemented with routing/switching components and data transport resources in order to map complete and independent virtual networks. There is no fear of interference from other users or disruption of other testbeds. Particularly noteworthy is the fact that physical infrastructure is used proportionally and no simulation takes place.

Due to the multi-domain capabilities of the service, resources outside the Erlangen site are also accessible if necessary, which are part of the GÉANT network domain.

To build a testbed in GVS, a user first describes how exactly the testbed should look like and which resources it should contain. This is done with the help of a document, which can be uploaded via a web interface. There, a resource manager receives the document, checks it for syntax and availability with respect to the required resources, and then, in case of a positive evaluation of the document, provides the user with the resource identifiers of the testbed components so that the user can control these resources and work with them in his testbed. The above document for describing a testbed contains Domain Specific Language (DSL) code based on Groovy (an object-oriented language for the Java platform). For advanced users, this has the advantage that looping can be used to construct very complex and large networks quickly and easily. To make it easier to get started, a “drag and drop” based graphical user interface (GUI) is also available in which testbeds can be designed and resources connected by clicking and dragging icons. The DSL code is automatically generated in the background.

Currently, GVS allows virtual machines (VMs), virtual links (VCs) and OpenFlow instances to be reserved, activated, deactivated and released as network resources in the testbed. However, the architecture of GVS is scalable and can be expanded with new resources at any time. For this purpose, it is only necessary to develop five control modules for the new resource, i.e., the new resource must be able to be (1) reserved, (2) activated, (3) deactivated and (4) released as described above; furthermore, a (5) status query must be possible. This means that any type of resource can be integrated, e.g., resources such as public IP addresses, timestamps or LTE components, etc. In addition to the resources already offered, hardware/bare metal servers (BMS) will soon be available in the GVS.