Any time somebody makes a networking announcement these days, they seem to enlist a Heavenly Choir to sing “SDN!” or “NFV! In the background. Most of the time, song is about all there is to the announcement. Yesterday, Overture Networks announced something for SDN and NFV without the choir, and in fact may have announced the most understated NFV asset of all time.
At the basic level, Overture Networks announced the availability of the components of its Ensemble OSA framework for service orchestration and management. Ensemble Service Orchestrator (ESO) is the controlling logic for lifecycle management of SDN/NFV services, and Ensemble Network Controller is the link between ESO and standard network hardware. The final piece, Ensemble Solution Pack, is a combination of pre-integrated higher-layer service features that augment business connectivity services, and an ecosystem to encourage contribution and development of additional features.
We’ve had stories about SDN, NFV, and business virtual function deployment before. RAD has its “Distributed NFV” that creates a premises platform for hosted functional extensions. NetSocket uses a server-like appliance to provide a very generalized edge platform on which functions can be hosted. Cisco and Juniper also have device-hosted examples of service chaining, the same application that Overture focuses on, which they variously call “SDN” and “NFV”. On the surface, the Overture story seems more of the same. It’s not.
In my current vision of management and orchestration, we have a two-layer model where some form of management/orchestration rides on top of a series of “Infrastructure Managers”. One of the “forms” of management/orchestration the model recognizes is “Service-Specific Orchestration”, and the idea is to say that some operators wouldn’t necessarily need a complete solution for MANO, just a solution that works for the specific services they’re offering. Overture, on the face, is an SSO approach focusing on the union of NFV principles and carrier Ethernet. That’s a fairly narrow mission, but what makes Overture different is that they did something broad and general and are only positioning it for a narrow mission.
Most of the service-chaining or distributed NFV or edge NFV offerings presume that there’s some high-level process elsewhere doing most of the NFV heavy lifting. Thus, they are more like Infrastructure Managers in my terms, rather than complete NFV solutions. If there’s no higher-level process up there to appeal to, then functionality is limited. Right now, most of the time, there won’t be.
Overture Ensemble OSA is applied as Service-Specific Orchestration but executed via a fairly generalized Infrastructure Manager that could support both virtual-based (OpenStack) and “real” infrastructure (primarily but not necessarily exclusively Overture’s own carrier Ethernet gear). Overture includes real orchestration based on the Business Process Model and Notation (BPMN 2.0) framework. They also provides a lifecycle-based approach to NFV that starts with the on-boarding of virtual functions and transitions through to the “Operate” and “Maintain” phases of service and service template evolution. Finally, they have something called Ensemble Service Intelligence that provides a management-repository model for decoupling and composing management data. I need to look a bit more at this part of the offering, but on the surface it looks promising.
One reason this is different, even unique, is that Overture has accepted what I think is the most important of all NFV premises; you must support network functions out of the box, without customization, to be VNFs. There are no proprietary APIs to write to; everything including basic parameterization of VNF images can be handled by ESO. Overture does provide, through its Solution Pack strategy and partner ecosystem, pre-configured and integrated VNFs but it would be possible to on-board pretty much anything that could be made to run in a VM. They also support both in-cloud and on-device hosting of virtual functions, and can optimize function placement based on policies (via BPMN). Operators are starting to realize that proprietary VNFs with vendor-specific APIs for management and orchestration are no more open than proprietary boxes, and Overture’s approach could get them out of that mess.
And it goes on. The Overture model lets service architects build service components from primitive building-blocks and catalog the result, making it then a building-block to be dragged into (literally, via a GUI) a higher-level service. They also support both virtual-function and legacy devices, SDN northbound models, multiple controllers, and so forth. There’s even horizontal scaling of ESO domains, either to work-share or to divide up infrastructure. That means that the architecture supports basic federation. All of this adds up to something that is aimed at creating my “structural” level of orchestration, but with the twist that the “structures” can be built up from complex primitive services. That positions Overture at the low end of functional orchestration, which is a position a few others aspire to but none have demonstrated with a real you-can-order-it product.
There are specific things that you need for functional orchestration that Overture doesn’t purport to have, including strong integration with OSS/BSS systems, explicit multi-operator federation, totally open infrastructure support, and totally derived management. The interesting thing for me is that they may not purport to have this stuff, but they’re not far from delivering it. Their blurring of functional and structural orchestration boundaries may be a very good way to tie all the disparate NFV trials operators are embarking on. If Overture works on that mission, they’d likely be induced to add in many of the features they’re missing, to the point where they might be able to link to open-source tools at the operations level to do the rest.
The net is that Overture’s Ensemble OSA is pretty darn close to being not just a Service-Specific Orchestration strategy but a complete NFV MANO implementation. Certainly it’s as close as any actual product offering that anyone has demonstrated to me, and closer than most of the stuff that some of the big vendors have announced. It’s going to be interesting to see how it could be married to an operations-level toolkit, because that combination could give the Heavenly Choir I mentioned something to sing about.