Telcos and communications service providers (CSPs) have been relying on the promise of network functions virtualization (NFV)  and software defined networking (SDN)  to lead them into the world of rapid deployment of new services, high network automation and dynamic re-configuration, overall reduced capex/opex, ease of provisioning, and management.

The industry has responded well, delivering multiple open source initiatives. The European Telecommunications Standards Institute (ETSI) established the open source NFV framework for Management and Orchestration (MANO) and since then, a number of Tier 1 CSPs and vendors have actively participated in open source initiatives. Some of the CSPs have been carrying out field trials, and there are a few Tier 1s whose systems have gone live on parts of their network, virtualized with NFV and SDN. Solution vendors have also created enhanced NFV/SDN platforms and optimized virtual network functions (VNFs).

However, the industry has become fragmented with multiple open source initiatives, each claiming their own merits and ultimately leading to confusion for the CSPs. Complex questions that can potentially derail the benefits of NFV/SDN have also not been adequately addressed.

Today, a CSP faces confusion when adopting one of the multiple NFV/SDN open source paths. The choices include OPEN-O, AT&T's ECOMP platform, ETSI OSM, OPNFV, and many more. The Linux Foundation has combined OPEN-O and ECOMP into ONAP, which is an excellent move. And while it remains to be seen when the integration will be successful, the industry will still be left with a battle between OSM and ONAP. Meanwhile, new initiatives such as MEF LSO are gaining attention, including deeper integration with operations support system (OSS)/business support systems (BSS). On the SDN front, well-established, open source initiatives include ONOS and ODL, once again each stating their own merits.

Each of these open source initiatives are driven by well-respected organizations, communities, vendors, and a few Tier 1 CSPs, which makes it hard for most CSPs to choose one or a combination.

Open source initiatives take an inordinate amount of time to mature and aren’t fully addressing some of the core challenges necessary to take NFV/SDN systems into production.

CSPs, understandably, want to avoid vendor lock-in and are pro open source approaches. But they also need to see a path to much faster production and assurances on performance, scalability, and long term support.

System integrators are not always helpful on which open source initiative they should back and some are treating CSPs as an R&D lab for their own learning. By backing multiple open source initiatives, system integrators may try to remain in the good books of their Tier 1 customers split across multiple initiatives.

CSPs need clarity and answers to some of the questions raised below before attempting to go down the NFV/SDN path:

1. Can NFV/SDN virtualized networks meet and scale to rapidly increasing network bandwidth demands using commercial off the shelf (COTS) hardware running in a data center?

2. Can CSPs adopt one or multiple open source initiatives and go to production in a reasonable time-frame (six months to one year), within reasonable costs?

3. Will CSPs get access to appropriate test systems and tools to verify and quantify performance quality metrics against stated specifications when deploying NFV/SDN systems? Can a CSP even set a clear specification for a NFV/SDN virtualized network system to meet (e.g., latency within X milliseconds)?

4. Will the NFV/SDN network integrate with CSP’s legacy network system and provide a unified dashboard and monitoring view? How will existing legacy network tools and virtualized network tools integrate to provide a uniform view across the network? Legacy networks are not going to go away.

5. Is the CSP assured the chosen open source will remain supported and upgraded for the next decade or so? Who will give this assurance? Will it be the system integrator /component vendor, open source community, or a combination?

6. Is the NFV/SDN virtualized network post-production support, upgrade, and managed services complexity actually lower than existing legacy systems? For example, is managing the security of a private cloud data center where the NFV/SDN system is hosted less complex than managing a system of widely distributed network boxes Is managing a hybrid network less complex than managing current legacy networks?

7. How can the NFV/SDN system meet CSP’s commitments on service level agreements (SLAs), quality of service (QoS), service assurance, high availability, and reliability? Can these parameters be quantified in a virtualized/hybrid system? And if not, what will be the new norm?

8. Are individual VNFs developed by different vendors using modern micro-services, containers, DevOps, and REST API principles, along with meeting MANO guidelines on their interfaces?

9. Can CSPs run their NFV/SDN systems with a peace-of-mind experience over constant security threats? For example, centralization of the SDN controller may actually create more security vulnerabilities for attacks. Similarly, the NFV stack has OS, hypervisor, and VNFs created by different entities and vendors. Would CSPs need to get various layers analyzed for security holes and also keep adopting newer fixes?

In the legacy world of hardware box networking, CSPs have been able to scale to rapid network bandwidth increases for more than a decade. While these systems became complex to manage, they worked reliably and CSPs could set hard SLAs. Newer network box solutions are also coming with a whole range of network automation tools for ease of provisioning and management. NFV/SDN systems not only have to make systems easier to deploy and manage, but also meet all performance metrics and future network bandwidth demands.

Hard commitments on performance, scale, and long term assurances of sustainability of the open source initiatives from open source communities, system integrators, and solution vendors is needed before CSPs can make an informed decision.

CSPs may also need to consult independent companies who can test and verify the virtualized/hybrid networks independently. Similarly, there is a need for solution vendors to build test frameworks to verify performance metrics in a virtualized/hybrid network.

Open source initiatives must be driven by time-bound goals, with a focus on taking the majority of the CSPs to production. Standard bodies need to continue focusing on hardening the interface/API layers so that integration and interoperability of various vendor components is smooth. CSPs must pay equal attention to proprietary vendor solutions, which are proven to be field tested, scalable, and have brought in network automation.

Over the upcoming years, CSP networks will need to keep pace with increasing bandwidth demands. A balanced view on hardware-driven network box solutions and the NFV/SDN-based virtualized approach is required. NFV/SDN based on COTS hardware alone may not be able to scale CSPs’ networks for future bandwidth demands.

The European Advanced Networking Test Center (EANTC) NFV interop tests conducted in late 2016 for the New IP Agency (NIA) and the ETSI NFV Plugtests, conducted in early 2017, are big steps towards making the industry realize the integration complexity and longer cycle to maturity.