VDC Use Case. Requirements and Mapping to SDN Controller Section 4.1.4 of deliverable [D4.2] already described the infrastructure-driven interactions and requirements that the VDC use case imposes towards the SDN controller, its NBI and services, which constitute the relevant ones for this section. Thus, the main interactions and requirements towards the SDN controller are: Advertisement of network resource utilisation and availability Continuous monitoring and updates Explicit resource allocation and slicing VDC network isolation and QoS guarantees The matching among these interactions and requirements with the options enabled by the COSIGN controller NBI is fundamental to ensure the proper behavior of the VDC use case operations. Thus, in this section we go deeper into the details on how previously enounced requirements can be mapped to the interfaces and services facilitated from the control plane. For the purpose of the discussion, the primary actors and entities involved on the VDC use case are: The VDC service provider, which must orchestrate requests for VDC instances coming from external tenants. The VDC service instance, which is a virtual infrastructure realizing a VDC client request. The VDC instance owner. Each VDC owner (i.e. tenant) must be able to access and configure all the virtual resources belonging to its own VDC instance through programmable, Representational State Transfer (REST)-enabled Application Programming Interfaces (APIs). VDC instances belonging to different VDC owners must be properly isolated and the performance of each owner’s traffic must be not impacted by the whole traffic at the physical infrastructure. In general, the VDC provider and service must be able to see the underlying physical resources. They must be able to provision and monitor these physical resources. In addition, they should be able to monitor statistics and activity of individual VDC instances. The VDC owner and instance must be restricted so that any programming of network behaviour is limited to only affect its VDC instance. Based on the monitoring of the whole physical resources, the orchestrator can optimally decide the placement of a new VDC instance and trigger the configuration of both compute and network resources, relying on the entities that are responsible for these actions: Nova for the compute and Neutron plus ODL for the network. Figure 2 depicts a schematic of the whole interaction for the request of a new VDC instance.
VDC Use Case. The development of the COSIGN orchestrator for the Virtual Data Centre (VDC) use case aimed at providing an automated and intuitive way to create VDC instances on demand according to the requirements of the end user (i.e. the tenant) while coordinating the provisioning of the computing and network resources to achieve an optimal utilization of the data plane infrastructure. To this end, the development of the orchestrator involved the customization of some of the OpenStack services (mainly the Horizon dashboard service) while taking advantage of several others (Heat, Nova, Neutron, Keystone) [1], the creation and development of a completely new Algorithms module dedicated to the computation of the optimal mapping of VDC instances and several client modules to interact with the OpenStack software suite. Additionally, to achieve a global view of the DC network (DCN) infrastructure and be able to provide the virtual link route mapping details to the COSIGN Control Plane (CP), specific interfaces to interact with the OpenDaylight (ODL) controller have also been developed. The details of the software development, its functionalities and integration have been reported in deliverables D4.3 [2] and D4.4 [3]. The full integrated orchestrator has been publicly show cased at the COSIGN demonstrator held in ECOC 2016 in Düsseldorf, where we successfully demonstrated the automated and dynamic configuration of VDC instances employing the COSIGN architecture. In what follows below, we will elaborate on the benefits that the COSIGN orchestrator brings to the other layers besides the orchestration layer. Additionally, we will discuss on potential exploitation of the developed software beyond the scope of the COSIGN project.
