Large data centers started using software-defined networking principles a few years ago to create interconnect “fabrics” out of many switches, something difficult to do with conventional routers and switches and protocols. Looking at carrier networks, moving from today’s routed network to an SDN network actually costs money because it requires buying new equipment without getting a lot in return besides flexibility. Network functions virtualization, however, can create new services faster, directly enabling creation of new service revenue in software rather than investing in new dedicated hardware, and therefore can boost top-line revenue growth without a lot of new investments. Unsurprisingly, service providers have pushed NFV much harder than SDN.
In reality, one can’t live without the other. Not all processing functions can be centralized in a large data center. A service may use a collection of data center server functions distributed across the wide-area network, some centralized, some closer to the edge of the network and some even at the customer premise itself – depending on traffic distribution, latency, bandwidth requirements and customer preferences. All those compute functions need to be interconnected to each other in a programmable way in order to create that service. Furthermore, the customers have to be connected to the distributed processing functions as well. So an appropriate characterization would be that NFV pays the bills, but a software-defined network is required to interconnect the NFV servers and virtual machines with each other and to the customer.
Most of the industry is currently talking about either NFV or SDN, and hence either focuses on managing virtualized compute infrastructure/resources, or managing networks in a programmatic way, but rarely both together. Our view is that in order to create and deliver a service that meets certain policies and service-level agreements, compute resources need to be connected to each other and then eventually to the customers. These interconnect functions – locally within the data center as well as across the WAN – must not become a bottleneck in the communication between processing functions, which means hardware-based networking functions are required, although they should be programmable in this model.
This vision not only tightly couples NFV and SDN and makes sure they can work together, but also ensures that the service can actually be delivered and guaranteed to the customer. In our view, the network of the future will consist of virtualized compute infrastructure centralized in data centers, plus other virtualized compute resources that are distributed across the network, and possibly even at the customer premise itself. It will be interconnected by Ethernet software-programmable networking and, of course, also to the customer, to create services with certain attributes such as bandwidth, latency, quality of service, etc. And, as mentioned before, certain generic functionalities such as L2 switching, OAM and performance management will need to happen in hardware elements near to the user at the service point, to deliver the services that meet user expectations. Our work is focused on how these functions are effectively combined with virtualized compute resources and create value for the end user both in capital expense and operating expense savings. In this way, NFV and SDN will become highly reliant upon each other, and compute resources need to interface tightly with networking resources in order to create the services – all, of course, in a highly programmatic and automated way.
Ideally, the broader ecosystem will work together to create an end-to-end NFV and SDN solution that actually delivers what NFV and SDN promise – generation of new services better, faster, more flexibly and with improved revenue and margins in an open-source environment.
The orchestration and operations aspects of SDN and NFV are probably the most important that need to be addressed in order to move the industry forward. Even if we implement all the nice features for SDN and NFV, service providers still would not be able to take advantage of the service agility if they continue relying on their arcane operations models. I would therefore argue that orchestration should be their highest priority, not just the underlying infrastructure and infrastructure management that most people talk about.
There are, of course, organizational and workforce skill levels that need to be addressed in order to make that happen, so this unfortunately will take some time. But if the service providers want to compete with the over-the-top players and provider better and more differentiated services to their customers, they will have to move fairly swiftly in these areas.
Since network equipment is amortized over many years, the industry also has to figure out how to utilize existing networks within the overall network evolution, otherwise the SDN/NFV revolution will not happen because the business models just won’t work out. Many companies and standards organizations have started to work on this by focusing more on programming end-to-end services, tunnels, VPN or overlays, and not requiring all nodes in the network to be fully programmable. The MEF Third Network Initiative is just one particular example, there are many more.
Martin Nuss is VP, technology and strategy and CTO at Vitesse Semiconductor. With over 25 years of technical and management experience, he is a recognized industry expert in Ethernet technology including timing and synchronization for public and private communications networks. Nuss serves on the board of directors for the Alliance for Telecommunications Industry Solutions and is a fellow of the Optical Society of America and an IEEE member. He holds a doctorate in applied physics from the Technical University in Munich, Germany.
Editor’s Note: The RCR Wireless News Reality Check section is where C-level executives and advisory firms from across the mobile industry share unique insights and experiences.
