Architecture
FELIX aims to provide a framework for integration of resources of different kinds (e.g. computing, SDN, transit network, stitching) residing in a multi-domain heterogeneous environment.
The resulting architecture attempts to be flexible and scalable enough to assure proper interaction between various system components.
The FELIX project uses a hybrid hierarchical model for inter-domain communication, where the upper layers contain a software module that aggregates information on the lower layers and act as a central point for operations such as interworking with the monitoring module.
A FELIX testbed can be seen as a combination of two spaces:
- FELIX Space: consists of management and control tools to coordinate processes of creation of a virtual environment in a heterogeneous, multi-domain and geographically distant test-bed. The components of the FELIX space operate in a hybrid hierarchical model, to enable efficient information management and sharing across multi-domain environment.
- User Space: consists of any tool or application a user wants to deploy to control his virtual network environment or to execute a particular operation within it. The selection of tools is completely dependent on specific user requirements and is out of scope of the FELIX framework.
Both spaces play distinct roles in creation and operation of each virtual network environment, which is created by the FELIX Space upon a request from a user, and then managed by user tools in the USER Space.
The figure below depicts a more detailed view, including the main functional blocks and their dependencies:
The FELIX Space relies on the FELIX Management Stack (FMS), which consists of Resource Orchestrators (ROs), Resource Managers (RMs), the Monitoring System (MS) and Authentication, Authorisation and Accountability (AAA) modules and the physical (testbed) infrastructure to provide the resources needed for realising a user slice.
The image above shows the different modules used in FELIX and their managed resources. On the other hand, the image below shows a simplified view of the relations between modules in the FELIX Management Stack.
The User Space configuration depends mostly on FELIX end user preferences and choices. The user has a freedom to choice any Resource Controller, that is suitable for his/her needs. This controller is in charge of managing the creation, modification and deletion of slices related to the experiments (including all functionality, APIs and applications) basing on resources assigned by the FELIX Space components.
The Resource Orchestrator (RO) is a stateful entity, responsible for the orchestration of the multi-domain service in the federated infrastructure. It coordinates the reservation and provisioning of heterogeneous network and compute resources in each domain.
The RO can work in two different modes: normal and master:
- Normal: typically, an RO connects to a number of RMs within the same domain. Some background tasks run periodically to detect changes in the resources provided by the underlying RMs. Also, RO provides MS with information on the physical topology that it oversees and about the slices requested by the users.
- Master: in an upper layer, the master RO (MRO) may oversee several ROs, e.g. at a state, continental or global level; depending on the configuration on the peers that is agreed by the members of the specific FELIX testbed. In the same manner as RO, MRO will periodically fetch resources from its peers.
The Resource Managers (RMs) are software modules in charge of controlling a specific type of resource, being the equivalent of the SFA Aggregate Manager and NSA in NSI Framework.
FELIX defines four basic types of RMs:
- Transit Network RM (TNRM) for the management of Transit Network
- Software-Defined Networking RM (SDNRM) for the management of SDN (here, OpenFlow)-related resources
- Stitching Entity RM (SERM) for the mapping of the two above domains
- Computing RM (CRM) for managing Virtual Machines in different hypervisors
The TNRM is focused on the on-demand multi-domain provisioning of connectivity in the transit segment. TNRM comes in two flavours:
- NSI-TNRM
- GRE-TNRM
The image below shows the location of TNRM and its interactions.
The SDNRM controls the OpenFlow-based L2 resources. To achieve that, it uses the latest version (1.4.0-1) of the FlowVisor network controller as a proxy between the controller defined by the user in the User Space and the switches residing in the infrastructure.
The two domains above must be related to enable communication across them. The SERM is in charge of binding the devices at the boundary at each domain.
The CRM module allocates (reserves) and provisions the Virtual Machines that the different islands or domains provide. It comes in two flavours, to support two different, widely used hypervisors:
- XEN-CRM
- KVM-CRM
The FELIX Monitoring System (MS) collects the monitoring data from the resources available per experiment or slice, including information retrieved from the different SDN islands and from the transit domains, in terms of performance of the established connectivity services.
The MS can work in two different modes: normal and master:
- Normal: the MS interacts with RO to recover information on slices and physical topology, as well as some data on the devices to monitor. MS will use such data to connect to them and fetch the expected metrics.
- Master: in a similar manner to RO, the Master MS (MMS) interacts with both MS and MRO to obtain aggregated measurements and other information.
The MS and MMS also interact with the Expedient user agent to provide a visual representation of the gathered metrics, orderly by time.
The Certificate-based AAA in FELIX is a ClearingHouse implementing the GENI Federation APIv2 and providing a registry of slices and members, among others, to exert authentication and authorisation procedures on the managed resources. For instance, CBAS provides certificates to the users and verifies whether they have or not the proper permissions or roles to request any given operation, such as listing the resources of a given RM or creating a new slice.
More details on architecture and its components can be found in D2.2 and D3.* in the FELIX deliverables.