Both SDN and NFV have taken the telecom industry by storm in the past two years. The level of excitement, buzz, and industry activity during this time has not been seen in the telecom industry before. The potential benefits of SDN and NFV can bring a ray of hope to the stagnating telecom industry. The hype created around SDN and NFV has also meant that vendors have tried to be innovative to come up with SDN and NFV solutions. This has created a headache for the operators who cannot allocate abundant resources to research and participate in several ongoing industry initiatives. Vendors tend to direct the SDN/NFV discussions to individual use cases (of course favoring their solutions and roadmaps), but fall short of providing a complete vision of end-to-end network cloud architecture. Among this all confusion, it is important for service providers to understand pros and cons of various technology options, ensure they capitalize on the benefits promised by SDN/NFV, and avoid any vendor lock-ins that exist in current network deployments.

We have three major SDN technology solutions (OpenFlow, control Plane extensions or API-based control, and overlay abstraction) and it is not clear where the service providers should focus their energies. Each of them has its pros and cons, which should be evaluated.

Pros: OpenFlow promises to deliver on all the SDN benefits of reduced complexity, cost (especially capex, due to reduced complexity in forwarding plane), centralized control, and service agility. It does not introduce any new overhead in existing IP headers and it is possible to provide strong QoS/SLA controls.

Cons: On the flip side, it does require all nodes in the network to support OpenFlow, which might mean a fork-lift upgrade of the networks that have been built over several years and represent significant capital investment. OpenFlow is still an immature standard (currently in release 1.4), and doubts still remain about its capability of handling complex service requirements in the core network. The potential of white-box switches is very exciting, but they can’t yet carry throughput of the scale of Tb/s, or even 100s of Gb/s, that is required in the core.

Available Solutions (Examples): Big Switch Floodlight, NTT Ryu, HP VAN SDN, IBM Programmable Network Controller, NEC ProgrammableFlow Controller, Pica8, Brocade Vyatta

Top Use Cases & Analysis: Today most applications of OpenFlow-controlled SDN solutions seem to be in the DC environments; however, this is the solution to keep an eye on for the next round of your major network build-out.

Pros: Control plane extensions or southbound APIs (like PCEP, BGP-LS, ALTO, I2RS, NETCONF, and even CLI) are a good way to manage the existing networking gear. This approach provides a smooth migration toward software-defined capabilities in the network by focusing on programmability and service agility.

Cons: By keeping the control plane in a distributed manner, this approach adds complexity and will not result in capex reduction. There is no standard approach, of using which APIs, resulting in vendor silo solutions. Solutions are customized for individual installed network environments. Operators run a high risk of vendor lock-in by selecting a solution that is overly customized.

Available Solutions (Examples): Juniper OpenContrail, Cisco APIC, Tail-F (Acquired by Cisco) NCS, Cyan Blue Planet, Alcatel-Lucent Nuage VSC, Brocade Vyatta

Top Use Cases & Analysis :All WAN-related use cases (Dynamic WAN reroute, WAN interconnect, Bandwidth on Demand) are good fits with this approach. These provide good interim solutions for introducing software programmability in existing IP/MPLS WAN environments, and the incumbents are advocating this approach because it provides a way to prolong returns from their existing hardware product lines. However its long-term role and vendor lock-in should be scrutinized before deployment.

Pros: They use one of the tunneling protocols (VXLAN, DOVE, NVGRE etc.) to create network abstraction (multiple logical networks) over existing physical infrastructure. It can be very quick to deploy/integrate because it has no impact on underlying hardware/software; only the end points (e.g. VTEP in the case of VXLAN) are aware of the logical overlay networks. This was one of the early deployments of network virtualization and hence it is more mature compared to other alternatives.

Cons: It introduces additional overhead and complexity due to overlay tunnels (e.g. VXLAN adds up to 50 bytes of overhead in each packet). It has limitations for scalability and extensibility in the WAN environment.

Available Solutions (Examples): VMWare Nicira NVP, Alcatel-Lucent Nuage VSC

Top Use Cases & Analysis: Good choice in data centers, where programmability can be gained quickly without impacting the hardware. However, its long-term suitability in target network cloud architecture is questionable.

Disclaimer:  Purpose of listing example solutions is just to provide a clearer understanding of how the industry is shaping up and not to favor any company. Some of the sample solutions fall into more than one category. Due to rapid pace of development in SDN industry, the categorization of solutions might change over time.

By now, you must be thinking if there is a way to combine multiple approaches and get the best out of each, well real world solutions are following this suite. An important development is Linux foundation’s open source OpenDaylight (ODL) project, which has managed to gain the support of, by far, the largest vendor community. ODL tries to bring multiple SDN approaches together to create a solution that can be deployed in most use cases. By creating a common downloadable source code for base network functions as well as standard southbound APIs, ODL provides a way of interoperability and a vendor neutral ecosystem where vendors can still differentiate through platform services, extensions, network applications and orchestration. Currently ODL is in its second release, Helium, but it might take some time before we see integrated vendor offerings around a standard ODL code.

ETSI ISG NFV has done a good job defining a reference architecture that provides clear guidelines on various components of NFV solutions. The defined NFV use cases are very aggressive and cover almost all areas of telecom network which are dominated by purpose build appliances today. Whether it is fixed and mobile core (IMS, EPC, DNS, DHCP, FW, LB), content distribution (CDN), fixed or mobile access networks (FTTX, base stations) or even home and enterprise equipment (CPE), all of them will run as VNFs (virtual network functions) on a common NFVI (infrastructure). However, it is not straightforward to choose a NFV vendor.

Intrinsic response to NFV is that we will centralize all functions in existing cloud data centers. However, there are stark dissimilarities between telecom and traditional cloud workloads. Telecom functions require huge data plane throughput, predictable performance (comparable to current equipment), high reliability/resilience, QoS control for traffic flows, end-to-end (multi-site) interconnections and global network view for management. All of these concepts are alien to vanilla cloud computing solutions. Therefore, it is important to build a carrier-grade cloud infrastructure.

The second dilemma of NFV decision making is that most of the vendors are focusing on individual case studies that could bring immediate value to operators and hence a faster business for them. This approach brings the risk of building multiple vertical NFV solution silos each for a set of specific use cases and tied with respective vendor’s closed VNF ecosystem. A better approach is to commoditize network functions virtualization infrastructure (NFVI) and build virtual infrastructure management (VIM) completely separate from VNFs and any high layer network/service orchestration. ETSI has specified interface requirements between VNFs and orchestration/VNF manager as Ve-Vnfm and Or-Vnfm, but their support by vendors is still unclear.

Most of the vendors are migrating their current appliances by simple porting to a virtualization environment, but we have to consider that these functions were never designed to work with the cloud and provide the benefits associated with fluid resources allocation. Practically all applications need an architectural overhaul for graceful migration to the NFV and network cloud era.

Another problem that exists in current NFV solution is that cloud execution stacks (OpenStack, CloudStack etc.) are being customized by vendors to make their applications run. Configuration setup for VLANs, IPv4, NIC installations and security configurations is usually hardcoded. This means that customization/integration efforts will be required while introducing any third-party orchestration. Limitations like lack of IPv6 features and single IP address per NIC are also daunting for future network evolution. Overall IP network function deployment and manageability of VNFs are in early stages, and special attention should be given while selecting a NFV solution/ecosystem.

Last but not the least is the role of a multi-vendor system integrator, which could be assumed by the provider of orchestration platform, NFVI, operators themselves or a third-party. But in order to create a scalable NFV infrastructure that can host best-of-class VNFs, a vendor agnostic system integration capability will be required.

I will conclude with a quote from Internet Guru and IETF Executive Director Peter Löthberg:

“Program services instead of re-architecting the network and the management system for every new service.”