ETSI & Cloudify

Open-source as a way to drive open standard has been one of the founding concepts behind Cloudify’s strategy since day-one.
The speed in which the cloud infrastructure world is evolving is fast leading towards continued fragmentation and changes. Driving open standard in such a world is therefore challenging to say the least. One of the keys to a successful open API and standard strategy is to design for continued transformation across the stack- this has been success factor for Cloudify, previously noted in this recent post :
“We need to accept the fact that the cloud world will be comprised of many domain-specific modeling languages and that lead to even more hybrid environments as we extend the cloud towards the edge.”
ETSI plays a key role in supporting regulation and legislation with technical standards and specifications. Its importance within Cloudify is just as bold. Read below our quick guide on everything ETSI at Cloudify, direct from our CTO, Nati Shalom.

About ETSI NFV Vs. Other standardization initiatives (ONAP, ONF, MEF)

Cloudify sees several instances in the industry where open standards are getting tighter:

  • ONF is focusing more on the virtual access world, recently taking a very cloud-native – K8s centric approach, exposing K8s to create light open-source components rather than set specifications.
  • ONAP is an E2E system view that covers the entire operator view from an orchestration and provisioning perspective. ETSI was established in the pre-cloud-native world and so far the reference to K8s is as a VIM.The API spec process took a long time to get agreement and maturity, and only when ETSI joined forces with the open-source community as OSM & ONAP it got to a point where API specs aligned with real-world use cases.

Etsi_CloudifyTMForum: Open source and the future of OSS

 

Do you see more demand for ETSI support today from carriers? 

As ETSI is the first to present NFV as an architecture reference and coined the relevant terminology and acronyms,  the last 4 years have seen a need and demand from carriers to align with this architecture.

Over the past year, more collaborations between ONAP and ETSI  have played out, which is helping to drive more consolidation and broad industry support.
Indeed we’ve seen a growing uptake from an increasing number of carriers that are now demanding ETSI support.

What is Cloudify’s approach to supporting ETSI?

Cloudify takes a pragmatic approach towards supporting ETSI, in particular for SOL002 & SOL003. Since Cloudify takes on a NFVO and/or VNFM role, based on customer needs, we focused on building an architecture around those domains and the interops to other ETSI supported platforms.

 

ETSI NFV MANOETSI focus for NFVO & VNFM interop using SOL002 and SOL003

 

For these domains, Cloudify follows its common approach of adding ‘domain specific logic’ via plugins. They are represented by TOSCA nodes and derived workflows published from the plugin towards the orchestration engine. In addition, API specific support is required. For this, an API GW (a mapper) is added, providing REST APIS, based on the ETSI SOL002 & SOL003 information model.

For each Cloudify role in ETSI NFV architecture (NFVO or VNFM), a set of southbound plugin and API GW are added.

Cloudify acts as ETSI NFVOCloudify acts as ETSI NFVO

 

Cloudify acts as ETSI VNFMCloudify acts as ETSI VNFM

Resource Management & Grant Mechanism

A big part 0f ETSI specification is related to the way the NFVO controls the resources that are allocated per service. Since each infrastructure and resource management policies tend to vary between different clients, Cloudify will provide a generic plugin that will address resource management in a way that is customizable.

An example of such an implementation is provided by one of Cloudify’s system integrators. Here, the SI implemented multi-site resource management allows the customer to control the overall quota and resources across all sites through a common interface on top of Cloudify; as seen in the screenshot below:

Etsi infrastructure

 

We see ETSI NFV as a domain that has a spec – so why did Cloudify choose to add support for ETSI now?

We’ve been involved in NFV and ETSI for quite a while and even had a chair position at ETSI (Michael Brenner) up until recently. In general, we need to realize that ETSI isn’t just an API specification. We tend to separate the ETSI architecture, features and the API specification into different parts that evolve through different timelines and maturity levels. Over the past few years, we made sure that Cloudify will be aligned with the ETSI architecture and support the main features, but we delayed the API support until the specification reached the maturity level and market demand that made such an investment worthwhile. The recent consolidation work that started to take place in ONAP played a big factor in our decision to add ETSI NFV API support to Cloudify – this aligned with the demand that we are seeing from our clients.

comments

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    Back to top