10 Recommendations for Your Roadmap to Making It Work:

The seeds of network functions virtualization (NFV) and software defined networking (SDN) were planted several years ago, with the vision of helping telcos and communication service providers (CSPs) reap the benefits of virtualized networks.

In a recent survey of global service providers conducted by IHS Markit, 100% of those participating indicated they will eventually deploy NFV, and 81% anticipate doing so by 2017.

After all, the projected advantages are many: rapid service enablement, scalability, programmability, dynamic configuration, and automation for provisioning, monitoring, maintenance, and management. In turn, all would hopefully lead to reduced CapEx and OpEx.

Nonetheless, as CSPs and telcos increasingly embrace a fully virtualized network with NFV/SDN, there are important trends and realities to keep in mind.

Open Source Approach
Along the way, CSPs and the overall telco community have mostly favored a vendor-agnostic and open-source-based approach to NFV and SDN. The participation of well-respected organizations, communities, and vendors, brings a great deal of credibility towards addressing a number of practical challenges that can arise during deployment of open source initiatives.

Many Tier 1 CSPs and communities have worked hard to progress on open source based on the NFV framework for Management and Orchestration (MANO) established by the European Telecommunications Standards Institute (ETSI). Today, probably the most well-known open source choices include OPEN-O, AT&T’s ECOMP platform, ETSI OSM, OPNFV, and the Linux Foundation’s ONAP, which combines ECOMP and OPEN-O. Initiatives such as the MEF Lifecycle Services Orchestration, which includes deeper integration with OSS/BSS, are also gaining support. In addition, solution vendors have created optimized MANO-compliant VNFs, hardened and production ready NFV infrastructure, MANO and more.

On the SDN front, well-established open source initiatives include ONOS (Open Network Operating System, http://onosproject.org/) and ODL (OpenDayLight, https://www.opendaylight.org/).

Central office re-architected as a data center (CORD) (http://opencord.org/) has also gained momentum, which again nicely integrates NFV and SDN approaches.

A few of the Tier1 CSPs have already gone live with NFV/SDN in portions of their networks, with more waiting in the pipeline to hit production. As open source systems mature and the industry primarily converges on a limited number of approaches, many others will join the open source NFV/SDN movement as well, including Tier 2 CSPs.

With multiple open source paths and multiple vendor solutions, interoperability issues inevitably arise. As a result, the European Advanced Networking Test Center (EANTC) (www.eantc.de/) conducted NFV interoperability tests during the latter part of 2016, and New IP Agency and ETSI NFV plug tests were conducted in early 2017. This testing has made the industry realize the areas that need to be fine-tuned for interoperability, as well as meet the overall goals of keeping solutions vendor agnostic and easy to replace.

On the hardware side, white box switch trends in data centers and field-deployed carrier-grade boxes are also attracting interest.

Unfortunately, multiple open source initiatives with the same goals, such as the Linux Foundation’s ONAP group versus the ETSI OSM group, continue to divide the industry. Each of these initiatives will take time to fully mature for large-scale production deployment.

System integrators and CSPs may find themselves divided in their support — which also means building expertise across multiple solutions and supporting both long term. And when a CSP does deploy open-source-based systems, the question still remains as to who will assure them support on the selected open source solution and upgrades to meet future long term needs.

Another consideration to keep in mind is that virtualization uses commercial off-the-shelf (COTS) hardware. While this naturally brings flexibility benefits, meeting the performance goals at an ever-increasing line and packet rate is much harder. The heavy east-west traffic within data centers can also cause dramatic load conditions which are challenging to achieve through virtualized systems. Future packet rates are also expected to be much higher and network latencies become more variable and unpredictable as loads increase on the NFV/SDN. It remains to be seen whether COTS will suffice, especially under peak load conditions.

As the VNFs, hypervisors, NFVI, and other components of the NFV/SDN chain are all separate, it becomes a complex ecosystem to maintain and manage overall infrastructure upgrades, and maintain overall security.

Potential Roadblocks
Some of the vendors releasing VNFs are not using the modern principles of micro-services and DevOps, and containerization to completely re-design the VNF from the ground up. Instead, they are converting hardware functions into monolithic software VNFs, thereby causing challenges for their deployment and scalability.

Performance and monitoring tests are typically carried out in legacy networks with network probes. However, in a virtual network, the system is entirely dynamic — thus even probing has to be virtualized. Some of these dynamic paths are going to be increasingly difficult to monitor.

Although the legacy approach of network boxes was an expensive path, it has been a tried and tested one that ultimately helped CSPs scale to ever increasing throughput requirements. The NFV/SDN virtualized path is still relatively unknown and guarantees of line rates under peak loads remains a challenge. Plus, the nature of NFV/SDN means that it is fundamentally difficult to set hard SLAs; a major headache for CSPs who have existing SLAs and service assurances with their customers.

The total time to migrate to NFV/SDN — from commencing the program to integration into existing networks, legacy systems, and legacy OSS/BSS — may take years and is hard to predict. It is important for CSPs to obtain a unified view across their entire network. While Tier 1 CSPs have larger budgets for this phase of experimentation trials, Tier 2 CSPs may not have resources to do R&D experimentation. Hence, production-ready NFV/SDN software, hardware, and infrastructure, which they can readily integrate into their system is needed.

A TCO comparison between a legacy network and NFV/SDN-based network calls for a deeper analysis. And, interoperability from different solution vendors still remains a big challenge.

10 Recommendations
Below are 10 recommendations that will help CSPs, telcos, and others, to carefully evaluate different NFV/SDN solutions:

Recommendation #1
Performance levels, scale, long-term assurances of sustainability from open source communities, end-to-end security, applicability to primary services, integration with legacy network, OSS/BSS, and long-term vision, belong on a checklist.

Recommendation #2
CSPs should ask for long-term assurances from solution vendors and system integrators regarding support for the open source path they select. And, it is always a good idea to work with independent virtualized network test providers to verify the deployed virtualized/hybrid networks under various load conditions, and to quantify metrics as well.

Recommendation #3
It’s not enough for only a few select Tier 1s to go into production with NFV/SDN, while the rest of the industry struggles. Standards bodies and open source communities should work together to enable a majority of the CSPs to go into production with NFV/SDN.

Recommendation #4
Keep in mind that OSS/BSS must also be redesigned to adapt to new virtualized networks and even newer applications. For example, the IoT application scenarios require a fresh look at billing and monetization models. OSS/BSS must also adopt modern software architecture involving micro-services and DevOps. At the same time the legacy networks are going to remain active for many years, before complete virtualization. Hence, CSPs need to design a unified OSS/BSS system for hybrid networks.

Recommendation #5
SLAs and service assurances should also be re-examined in virtualized network systems.

Recommendation #6
COTS based on x86, even with DPDK/SR-IOV acceleration, may not suffice to meet the high throughput requirements in data centers. Thus, specialized high performance NIC cards may be required.

Recommendation #7
NFV and SDN will have to move from enabling relatively low-impact revenue secondary services to more mainstream primary services. With this in mind, CSPs, telcos, and others, should plan to migrate their primary and important services first. The challenges to migrate primary services are likely to be much more complex.

Recommendation #8
While the open source approach clearly has a lot of benefits and has maximum industry attention, it’s not prudent to ignore proprietary solutions developed by known vendors. Ultimately what matters is production-grade software, long-term support/maintenance, and scalability to future needs.

Recommendation #9
For open source approach to be successful, there has to be conformance to standards, and systems have to interop. And this is the biggest challenge. The current NFV/SDN standards are very loose ended. Standard bodies and industry need to agree to hard standards against which everyone confirms and verifies their solutions.

Recommendation #10
Time-frames and costs to deploy production grade NFV/SDN are unpredictable and large. This simply will not work for CSPs. Solution vendors and System Integrators cannot keep open-ended goals when they work with CSPs.

With the rapid strides made by industry, communities, and standard bodies, over the last year, NFV/SDN is finally moving out of the R&D shell and getting into real field/production deployments. But there are still a number of hurdles to be crossed, and some of them have been highlighted in this article. Year 2017-18 appears to be a crucial inflection period which can set the direction for NFV/SDN.

This article is originally published at ISE (ICT Solutions & Education) by Sachin Kurlekar (Associate VP – Telecom & Media Business at Persistent Systems).