Lack of stability markets early NFV MANO deployments, analyst says
Network functions virtualization (NFV) has made significant progress moving from lab tests to early deployments over the last few years, but not without its share of hurdles. David Snow, a principal analyst of IP services infrastructure for Current Analysis, recently warned the NFV management and orchestration (MANO) market appears to be migrating into an unstable economic climate.
“Turbulence in the NFV MANO market is high; that can be good to shakeout problems, but it also makes for an uncomfortable flight,” wrote Snow in a Network Matter blog. “The NFV management and network orchestration (MANO) architectural block is a good indicator of the ‘flight status’ of the whole NFV project, which now seems to be entering a new phase of turbulence.”
NFV involves decoupling software from hardware, and running network functions on virtual machines. The evolution of physical networks into virtual network functions is a gradual process, consisting of intermediates stages where the two exist side-by-side. Consequently, the European Telecommunications Standards Institute (ETSI) developed MANO as an architectural framework that could manage both physical and virtual network functions. The architecture consists of three main blocks, including NFV orchestrators, virtual network functions (VNF) managers and virtualized infrastructure managers (VIMs).
There are a myriad of variables that can spur market turbulence, from poor financial decisions to customer dissatisfaction. Snow pointed to SK Telecom’s recent commercialization of its T-MANO as an indicator of the current state of the NFV MANO market. Before T-MANO was developed, SK Telecom had to create and operate a different NFV management platform for network providers because each provider had NFV equipment based on different specifications.
“With AT&T unashamedly pushing ECOMP-fueled ONAP as the “de facto standard” and China Mobile appearing to subsume its own MANO development into Open-O (and then also into ONAP), it’s easy to forget that some large operators are determined to sort out MANO by themselves,” Snow wrote. “It’s a reminder that it’s actually operators who are “in charge”, not vendors or even open source projects, however influential.”
Snow also noted a recent post by Sonus Networks highlighting the benefits of a vendor-specific VNF manager:
“While I believe a generic VFNM can provide vendor independence and is the right approach for certain applications, for complex, real-time applications like session border controllers and policy servers, it cannot deliver this goal of automation,” wrote Sonus Senior Product Marketing Manager Dan Teichman in a company blog post. “At this time, a vendor-specific VNFM adds significant value over a generic VNFM and is really the only way to achieve much of the automation and service resiliency that NFV is expected to deliver.”
A VNF manager is a distinct component of NFV architecture responsible for the lifecycle of a VNF. The VNF manager may be a generic component treating VNFs as a black box, or a vendor-specific component with special capabilities for the management of a particular VNF. Snow said Sonus’s praise of vendor-specific VNF managers is in stark contrast to the widespread use of generic VNF manager components.
Technology is by its very nature disruptive; otherwise, it wouldn’t be innovative. Like any burgeoning software, NFV MANO will take time to develop to achieve widespread deployment. It still needs certain features, including specifications for software-defined networking (SDN) in its architecture, to assure a graceful transition. Service providers can make it through periods of market turbulence by focusing on automation, orchestration, policies and management, while maintaining a long-term perspective.
