OSM

Why OSM is the ‘smart’ choice for Open-Source Network and Service Management

October, 2018

By Dave Duggal, Founder & CEO, EnterpriseWeb LLC

The Telecom industry has set out on a journey to transform into Digital Service Providers. However, how the industry gets there is hotly contested. Given all the noise and confusion, we at EnterpriseWeb have decided to share our internal technical case for joining ETSI’s Open-Source MANO (OSM) to foster a more thoughtful industry discussion on design choices and capabilities.

OSM is born of standards and actively contributes back to ETSI NFV. It was conceived with an Information Model at its core (perhaps inspired by ETSI NFV PoC #1, CloudNFV - “model-based, event-driven, policy-controlled”), has a modular architecture, and is committed to open-interfaces.

We didn’t join OSM immediately as we weren’t initially clear on its direction. However, it has steadily evolved with ETSI NFV and the latest update OSM 4 in May 2018 presented a mature architecture with an improved separation of concerns, logical boundaries and clear interfaces. Most importantly, it de-coupled the information model from the other components to avoid being a monolith. This is critical as it means the Information Model can serve as an abstraction layer to promote interoperability and automation over a multi-vendor, multi-technology environment. After reviewing project documents, we concluded that OSM conceptual architecture was now congruent with EnterpriseWeb design principles and that we could make an impact without compromise.

This is not an endorsement of the current implementation. Honestly, there’s too much Python code required to make anything work, which undermines Interoperability claims. However, OSM is truly modular, standards-compliant and model-based. With release 4, OSM shifts away from being a stack of open-source components and towards being a set of open interfaces which support substitution and invite competition.

With Open Interfaces, the components are de-coupled from the model. Components can be mixed and matched in best of breed implementations and there is no vendor lock-in! Interoperability is based on adherence to a set of interfaces and the underlying model, not to a set of specific middleware components, versions and configuration. This was in evidence at ETSI NFV Plugtest #3 with multiple MANO vendors demonstrating support to standard APIs.

“API only open-source” is a better and more modern realization of standards. EnterpriseWeb is committed to implementing the OSM interfaces and we will innovate behind them providing an alternate reference implementation that can run at the core and the edge.

“Outside of being big trends in computing, the open source projects backing these movements are being built in a new, and perhaps unique, way. In each domain, an API-only open source interface has emerged that must be used alongside one of many supported separate back ends. The pattern may be a boon to the industry by promising less rewrite, easy adoption, performance improvements, and profitable companies… They don’t have an execution engine; instead, they are metaframeworks that provide a common interface to several different execution engines.” Eric Anderson is a Principal at Scale Venture Partners, formerly of Google and AWS

"The Simpler the standard, the less there is to agree on, and the more likely is it to make interoperability possible." Douglas Crockford, prominent Computer Programmer behind the development of the JavaScript language and the JSON data format

As anyone who knows us will affirm, we’ve been promoting Metamodels since the earliest days of NFV and pushed for the adoption of abstractions, patterns and minimum-viable interfaces to accelerate transformation, encourage participation and allow for rapid iteration. Please see the great white paper by Caroline Chappell of Analysis-Mason.

At EnterpriseWeb, we take a graph-based approach, which enables better modeling of real-world complexity and avoids the limitations of hierarchical approaches. We absolutely have some thoughts on the OSM Information Model in order to make it more flexible, extensible and adaptable to address challenges with model conformance generally, but the OSM conceptual architecture supports this. A strong abstraction layer can be used to promote interoperability and automation for Zero-touch Network and Service Management. We hope to be a bridge to ETSI ZSM ISG and bring our experience running ZSM PoC #1.

In short, conceptual and technical alignment, were key to our decision. In addition, we are really pleased with the strong new leadership with representatives from Intel, VMware and AWS.

The Interoperability and Automation Challenge

In the industry, it is popular to describe VNFs as “legos” and in a way, it would be apt if everyone used the same magic VNF cookie-cutter, but that isn’t even close to being true. VNFs of the same type aren’t the same. Even VNFs from the same vendors aren’t consistently designed. To make these ‘snowflakes’ appear to be the same (i.e. virtual legos) requires a high-level abstraction as I described above otherwise NFV will remain high-touch rather than zero-touch.

The conventional practice for interoperability is to publish a static template for a VNF Package, which is tightly-coupled to a middleware environment and infrastructure. Vendors conform by custom coding. Any change to the middleware environment, target host/VIMs, or the VNF Package templates they consume, will break interoperability. Of course, updates and upgrades of VNF Packages will also require re-integration.

Even when vendors conform with the template, interoperability is not automated. Though the template is a form of a model, it’s generally not a rich executable model. Such approaches aren’t really model-based, rather they involve a collection of models in different technologies, which require transformation between the layers, which is performed by manual integration. There is no over-arching model. Developers drop in and out of abstraction layers creating a tangle of code, which limits transparency and complicates integration, testing and debugging.

Extending this to Telecom operations, it is not likely that every deployment would be identical. That would assume each environment is running the exact same version and configuration of the middleware components and infrastructure. If they drift at all, it will break interoperability. So CSP would have to deal with custom versions of VNF Packages for each deployment, which is sub-optimal even if vendors are willing to provide the support and maintenance.

Of course, it is even less likely that all Communication Service Provider will stay in lock-step. Given the unique make up and requirements of every Network Operator, it seems inconceivable that there’d be no variance, or worse - forking. How will alignment be maintained when features drift, when there is material argument on design approach or technology choices? My experience in Telecom standards bodies is that consensus is difficult and tenuous so Vendors will have to support and maintain custom-coded versions of VNF Packages for every deployment per CSP.

Now it has been argued that Cloud vendors have managed to get vendors to play ball by forcing conformance to their stack, but let’s note a few differences. Most folks couldn’t name more than six Cloud vendors and we all know there are three leading ones. The Cloud vendors are walled gardens that scaled their operations on a homogeneous global infrastructure and homegrown Cloud-native platform services so it’s easier and more stable for vendors to comply. In addition, the Cloud vendors aren’t regulated and they don’t give Resource SLAs, let alone SLAs for applications that run on top of their IaaS platforms. This is not an apples-to-apples comparison for Telecoms, even if they could manage to replace heterogeneous legacy environments with homogeneous infrastructure.

Conclusion

Telecoms are inherently complex and so are distributed systems. If objectives matter and the goal is transformation to Digital Service Providers, then we need to be attentive to the foundation we are laying – architecture matters! Open-Source community development shouldn’t be beyond critique – that would be ruinous, it would eliminate the feedback loop that drives improvements and maintains strategic alignment. OSM is not perfect, but we believe it is the better foundation and most likely to evolve into a sustainable, scalable automation platform based on a central model and Open Interfaces. It would allow Network Operators to mix and match components, commercial and open-source, for a best of breed environment that can adapt and be extended as the industry evolves.