What is NFV?
This past October many of the world’s leading telecom network operators created a new standards group, the Network Functions Virtualization (NFV) group. Formed to address the challenges they’re facing with the ever-growing number of disparate proprietary hardware appliances in their networks and the need to implement more functions in software. The group’s mission is to develop requirements and architecture for the virtualization of various network functions. The NFV group is part of European Telecommunications Standards Institute (ETSI), and today has more than 30 operator members and many more vendor participants.
Last week, amidst snow on the French Riviera, a sizeable group of Tier 1 and other Operators (including AT&T, Verizon, Deustche Telekom, Orange, Vodafone, and many others) met at ETSI headquarters for the first meeting of the NFV group to discuss the future of their networks. A handful of network systems and software vendors also attended, including three of us from LineRate. You can read the official story of what took place here, but the main takeaway is this – operators are reexamining large swaths of their network equipment and deployment strategy, creating huge opportunities for network vendors, especially startups.
According to ETSI, operators are looking to move all network functions to software on commodity hardware to reduce capex and opex and improve service velocity. However, our perspective from the ground is that the main drivers are reduced opex through automation of deployment and management, and service velocity through the same.
The key themes that ran through all five parallel tracks at the meeting are what make this a very exciting time for software defined networking, especially for those looking beyond OpenFlow. These themes include:
- Universal agreement among operators that an all software approach is ideal if there is sufficient performance. This opens the door for those who know how to deliver high-performance networking solutions in pure software.
- Recognition that SDN needs to be more than OpenFlow and that OpenFlow cannot solve many of the software networking problems operators will face with NFV.
- A desire to move away from telecommunications specific hardware when possible, i.e., no NEBS required. This will open the door for higher performance servers, more state of the art technology in operator deployments, and faster iteration and upgrade cycles.
- A willingness to consider alternative high-availability strategies such as stateless failover with fast recovery as a way to improve the performance and reduce the cost of software networking deployments.
- A desire to work with smaller vendors for these new solutions because of the perception that larger vendors will be slow to move since they are defending existing product lines and revenue streams.
On the other hand, NFV won’t be without its challenges. We at LineRate believe that high-performance software is possible for almost all components of the network, especially when coupled with merchant silicon switches programmed via openflow. However, in looking at the industry overall, expertise in software network performance is scarce given the historical hardware focus of the industry.
Furthermore, while the operators’ labs and standards arms are very open minded about new approaches and new vendors, production deployments will face the requirements of the part of the company that actually operates the network. Will the actual operators be as accepting of new vendors, or will new vendors be limited to proof-of-concept deployments with actual purchasing for full-scale operations still pushed through an existing large vendor? How well will stateless failover be accepted in the face of 5 9’s uptime guarantees? Our initial conversations with the actual operators are promising, but only time and successful deployments will tell.
Of course, overcoming these challenges and establishing a new and better way to deploy network technology is what SDN is all about, and that is what makes this such an exciting time to be in networking.