D3.2 Interworking Reference Model

Experimenters from Verticals willing to execute an experiment on top of the 5G EVE infrastructure will be able to interact with 5G EVE Experimentation Portal in order to completely define their interests and requirements. However, it is not the Portal the component that directly interacts with the elements at the different sites to deploy such experiment, or modify the testing conditions after different repetitions, for example. That component is the 5G EVE Interworking (I/W) Layer, which provides the required abstraction to permit the Portal not to be aware of the different underlying technologies, and to permit the parallel evolution of the different sites without affecting our single and common frontend for Verticals.
The present D3.2 document, Interworking Reference Model, is the specification of the Interworking Framework for 5G EVE, further developing the initial specification provided in Deliverable D3.1 (Interworking Capability Definition and Gap Analysis).
The foundations of the architecture have not been changed. The proposed I/W Framework is composed of five modules, with the following summarized functionalities:
• The Multi-Site Network Service Orchestrator (NSO), Multi-site Catalogue and Multi-site Inventory are responsible for the management of the lifecycle of the deployed components, jointly allowing for multi-site slices supporting Verticals’ experiments.
• The Data Collection Manager collects the required performance metrics to ensure the correct operation of the infrastructure and to validate the targeted KPIs.
• The Runtime Configurator applies the required runtime configurations to the provisioned services.
In this document, a detailed description of the features required to those five modules is provided, together with the specifications of north-bound and south-bound reference points allowing for the envisioned interactions. In that sense, the Interworking API or NBI (North-Bound Interface) allows for the communication with the Experimentation Portal, while the Adaptation Layer or SBI (South-Bound Interface) is the one abstracting the heterogeneous site capabilities. Both interfaces have been defined for the Data Collection Manager, the Runtime Configurator and the Multi-site NSO. However, the Multi-site Catalogue and Inventory will only interact with the sites using the Multi-site Orchestrator as a proxy. The reason is that we can leverage on features already supported by available orchestrators to simplify the Adaptation Layer.
A very important decision, valid for the first release of the I/W Framework, is that only the local NFVO components will be exposed to the Multi-site Orchestrator. This means that local orchestrators will maintain the direct control over the local infrastructure, with other local components like the VIM or the SDN controller not exposed directly to the upper layers. This approach can be revisited in future versions of the I/W Framework, depending on new interworking requirements. In any case, we have also accounted for the possibility of any site deploying an additional SDN controller, for example for the WAN, in which case it should be possible for the I/W Framework to interact directly with it via the WIM.
The biggest complexity, however, comes from the wide range of components which could be targeted by the Runtime Configurator and the Data Collection Manager. The amount of software drivers to be implemented in the I/W Layer will depend on the number of Vertical experiments, the complexity of those experiments in terms of number of required VNFs or PNFs, the tools that are available in the different sites, the vendors providing those tools, etc. Although some level of harmonization will be sought in the project as a whole, the I/W Layer will have to be deal with a very heterogeneous environment, therefore subject to interoperability issues.
From the design point of view, it is not realistic to try and define an SBI valid for all the uses cases. Therefore, for these components, we will follow an approach based on continuous integration of new features, starting from the ones required by the Verticals participating on 5G EVE, and building on top of those as new requirements appear.
Another design decision taken to minimize integrations is to rely on standards whenever these are available, even in a very preliminary stage. That should guarantee the design being future-proof, leveraging on subsequent industry implementations, and also opens the possibility to contribute on the standards that need extensions. For
5G EVE (H2020-ICT-17-2018)
Deliverable D3.1 Page 16 / 124
that purpose, the work on D3.2 began with a State of the Art covering the main references regarding NFV, network slicing and SDN control. That study was complemented with a detailed analysis of other European projects dealing with concepts similar to those of 5G EVE. The main goal was to understand what results were reusable from these projects, and where we needed to put the main focus for new implementations.
The first conclusion was the confirmation that, until 5G EVE, there had not been an effort to build a system allowing for multi-site Vertical experimentation across such a complex and heterogeneous environment. Therefore, all the adoptions made in 5G EVE will have to be carefully assessed, as they most probably will not be valid straight away. The second conclusion was that if there is a component that has not been sufficiently tackled yet is precisely the Runtime Configurator, for the reasons mentioned above.
Apart from a technical description of the I/W Framework itself, the document also describes the services it will offer to the Verticals, in line with the ongoing work in WP1.
In the first stage, experiments will only be deployed in a single site, so the I/W Framework will be able to support single-site Applications Deployment, Experiment Monitoring and Network Automation, the latter to build the required connectivity services (e.g., a VLAN or a VxLAN tunnel) among the deployed components. In the second phase, the I/W Framework will be upgraded with additional capabilities, like the multi-site E2E Orchestration and extended Experiment Monitoring. The E2E Orchestration feature includes the capability to deploy multi-site slices, and VNFs on top of them, across all the sites participating in a given experiment.
Even with all these considerations, experiments will only be possible in 5G EVE with the deployment of an underlying connectivity supporting the identified requirements. The first part of the activity, the requirements definition, was already included in D3.1; in D3.2, we have complemented the analysis by studying all the technical possibilities to achieve this connectivity in the different communication Planes (orchestration, control and data). Although the final implementation decision corresponds to WP2, a proposal is outlined here aiming at securing compliance with the needs of the I/W Layer in the Orchestration Plane: a star-based topology, with the I/W Framework components located in the hub, placed in the Turin site to minimize the delay. The technical implementation would be based on IPSec VPN tunnels, and an addressing scheme should have to be agreed among all the sites to avoid duplications.
We have also defined additional services or functionalities required from the 5G EVE site facilities, some of them fundamental to ensure the correct operation, and others to provide added value to the Verticals. An example of the first ones is the adoption of appropriate security measures, even more importantly, taking into account the multi-site characteristic of the 5G EVE environment. Therefore, items like hardening of the infrastructure, authentication in the Orchestration Plane, firewalling, filtering, etc., are discussed. On the other hand, the necessity of services like the remote access for Vertical to their deployed VNFs, or the availability of a ticketing tool even in scenarios as automated as 5G EVE, has also been included.
Finally, another objective of the document is to define the requirements or capabilities that WP3 is imposing to 5G EVE sites that want to participate of the interworking solution that will be developed. And more specifically, a list of requirements for the site hosting the I/W Layer has been identified, together with some considerations in case new sites wanted to join the 5G EVE ecosystem.
Beyond the obvious need to make available the required compute capacity to actually install all the software modules forming the I/W Framework, the central site will have to consider topics like the required encryption capability to ensure correct communications across the star, the operational costs (updates, troubleshooting, bug resolution, resolution of physical impairments…), the capability to monitor the status of all the Orchestration Layer components from the hub, or the potential availability of mirror platforms which can be used for preliminary testing without affecting the system in production.