The FLAME deliverable entitled “FLAME Platform Architecture and Infrastructure Specification V1” (D3.3.1) provides a first version of the component and interface level architecture of the FLAME platform. In this blog, we provide a brief overview of those main components and their relations, particularly with respect to media services provided on top of this platform.
The figure below shows the FLAME platform architecture at a component level, operating on top of an infrastructure such as the one provided in our deployments in Bristol and Barcelona. In this figure, we focus on the main layers of the overall architecture, including the FLAME platform, while showing crucial inter-layer interfaces for explanation of the overall workings. For detailed descriptions on the internal functions of the various layers, we refer the interested reader to Section 6.6 of D3.3.1.
At the very bottom, we assume the existence of the infrastructure (provider), exposing an ETSI MANO compliant interface to the FLAME platform for resource management at the wholesale level, i.e. the FLAME platform is reserving platform resources in the compute, storage and networking domain. We assume such infrastructure resource exposure to follow our observed emerging infrastructure view of virtualized and programmable resources, as discussed in Section 2.3 of D3.3, with the ability to reserve resources for the FLAME platform as part of a longer-lived relationship between FLAME platform provider and infrastructure provider, realized with an infrastructure slice.
Resources of the infrastructure provided to the FLAME platform are in turn provided as retail resources to the media services at the top of the platform through management interfaces exposed to media services. In other words, the FLAME platform orchestrates the deployment of media components as well as internal service functions. In addition, a monitoring interface allows for information exchange between media services and FLAME platform, which in turn will drive the decisions taken for the management input via the former interface. This combination of management and monitoring interfaces effectively provide the experiment API towards media services, allowing for defining and placing the compute, storage and network resources for the specific tests in the experiment. The experiment API is complemented at the data plane through standard HTTP/IP data plane interfaces of the existing Internet through which media services realize their functionality.
The management interfaces allow for initiating the orchestration of (retail) resources from the media service provider side. We see these interfaces and therefore the dialogue between media services and the FLAME platform evolving over time. In an initial realization, we see media services heavily relying on the ETSI MANO compliant interface, providing details on compute, storage and network resources being utilized in their specific experiment deployment.
However, insights obtained from the first experiments, as planned through the FLAME media user partners, will drive the evolution of the FLAME-specific (second) management interface towards one that provides a selection of orchestration templates for specific use cases and therefore removing the need for explicitly defining each orchestration template from scratch, while utilizing the ETSI MANO compliant interface to utilize this evolving template knowledge towards the FLAME platform. This evolution is based on the evolving knowledge through our initial use cases on how to best accommodate demand and supply for specific media service use cases. Through our open calls, this richness of knowledge is meant to expand, e.g., through rich control policies that allows for matching runtime-level demand and supply measurements and feeding them into the control elements of the FLAME platform. Again, instead of needing the media service provider to define all those details through their own templates and setups, we see an enriched repository of configurations that is being utilized by the FLAME-specific management interface between media services and FLAME platform rather than utilizing the ETSI MANO compliant variant. Ultimately, we see the relationship between media services and platform as being realized by high-level KPI-driven service-level agreements (SLAs), expressed through the FLAME-specific management interface and realized through an evolving CLMC component on the platform side.
As indicated in our figure above, we consider the realization of the media services outside the scope of the FLAME platform itself. We do assume, however, that a media service is realized through a set of media components, each communicating with each other through an HTTP/IP-compliant data plane interface, while utilizing the management and monitoring interfaces to the FLAME platform (see below) to facilitate and enable the deployment of those media components through the FLAME platform, i.e. media components are (computing and storage) resources from a FLAME platform perspective. Towards the end user, we see media components utilizing service-specific interfaces and interaction methods. Media components are implemented utilizing platform resources, such as servers, connectivity components (e.g., switches) and others, while also utilizing resources outside of the scope of FLAME, such as end user devices and Internet-of-thing components. With that in mind, we position FLAME as a distributed programmable resource platform, which can be used by media services for the fulfilment of a desired user experience.
It is up to the policy of the FLAME platform provider if resources are provided exclusively to a media service provider or from a shared resource pool. In the latter case, experiments conducted by the media service providers could run concurrently in the system, while the former case provides an exclusive access to the resources for a single media service provider. The governance and specificity of the experiments as well as deployment will likely drive these policies. For instance, exclusive usage of geographically defined resources might make certain media service deployments mutually exclusive since appropriate resources for another deployment are simply not available.
The orchestration component of the FLAME platform interfaces with the infrastructure resource management, through the aforementioned ETSI MANO compliant interface, to manage the compute/storage/network resources at the retail level, i.e. towards the media service provider, while it will utilize the surrogate policy control interface towards the service function (SF) endpoint management and control component to realize the orchestration-level management policies as well as to set suitable shorter-term control policies for (surrogate) service function endpoints. For the realization of the configured service function endpoint policies, the service function endpoint management and control layer will utilize the FQDN registration interface to control the registration and deregistration of the service endpoints towards the service function routing component. With this, the ‘visibility’ of said FQDN (fully qualified domain name) towards service requests being routed by said layer can be controlled. The service routing layer, in turn, will use the OpenFlow interface (e.g., via suitable platforms such as ODL) to suitably configure the switching fabric of the underlying infrastructure.
Particular consideration is given in our platform to the gathering of information across various layers, realized by the cross-layer management and control (CLMC) component. While such data is useful and needed for control-level decisions, such as the activation of service endpoints, it also provides a rich pool of data for the experiments, either as insights towards the creation of further experimentation or insights that reflect directly on the ongoing experiments, e.g., adjusting crucial longer-term strategies such as those for content placement or media adaptation. FLAME will tap into existing monitoring frameworks provided by the individual sub-systems (such as those provided directly by switching platforms such as ODL or ONOS, obtained through the aforementioned OpenFlow interface towards the underlying infrastructure), while also developing solutions for analytics and knowledge management beyond those existing ones.
With D3.3.1 providing the necessary blueprint for the FLAME platform architecture, efforts are currently underway to realize a first alpha release for early 2018, followed by an improved beta release in early 2019. These SW platform releases will form the basis for the trials being conducted by FLAME partners initially, followed by Open Call trials towards the fall of 2018.