WavebreakmediaMicro - Fotolia
Editor's note: The final article in our three-part series on the network of the future looks at the benefits and challenges of network standards in terms of promoting SDN/NFV adoption in the hardware-to-software transition. Check out part one on the need for changes in network infrastructure, and part two on the need for modernizing network operations.
Network operators have always known they have to build their infrastructure from open components that present open interfaces and conform to compatible specifications. Anything else would lock them into a single vendor and pose a risk of high cost or a forklift change in technology if that vendor changed course or failed. Setting network standards has been the traditional way operators address this. And while standards still play a role in next-generation networks that make greater use of software, they also create a major problem.
The current network evolution is generally considered a transformation from reliance on proprietary hardware appliances to software. Software-defined networking (SDN) and network functions virtualization (NFV) are initiatives designed to address that shift to software, with each assigned to a standards group to develop specifications -- the Open Network Foundation for SDN and the ETSI Industry Specification Group for NFV. Here are the differences in SDN/NFV functions:
- SDN targets the data plane behavior -- the actual service of connectivity. The goal of SDN was to replace the complex adaptive processes of route discovery and forwarding-table creation in routers and switches with a centralized process that builds traffic routes explicitly. A central controller that has knowledge of the topology and state of the network would decide how to route traffic to optimize quality of service, meet service-level agreements, and manage traffic to reduce the cost of infrastructure.
Users of SDN services would generally see the same things they see today with traditional infrastructure, but they would presumably have a more stable service experience and could turn services on and off more quickly.
- NFV targets non-connectivity devices like firewalls and VPN tools used at the points of service connection and the control-plane elements of services like the IP Multimedia Subsystem, Evolved Packet Core (both part of mobile infrastructure), and content delivery networks used for all forms of business and consumer broadband. The specific goal of NFV is to shift service features and functions from fixed appliances often sold at large profit margins to commodity servers and software.
With NFV, instead of sending a device to a particular place to add a function, an operations center simply spins up a virtual machine in a cloud data center and loads a software image of that function -- a virtual network function. This image can be replicated if loads increase, can be easily replaced in case of failure, and offers lower costs than the proprietary appliances it replaces.
SDN and NFV, if deployed fully, would substitute white-box switches and SDN controllers for traditional IP routers and Ethernet switches. NFV would host all other network service features in cloud data centers. The result would be the elimination of Layer 2 and Layer 3 as we know them, and a massive increase in the number of network operator data centers (up to as many as 100,000 additional data centers worldwide).
All of these devices would be simple and open, which means profits on equipment would fall radically for network vendors. Some vendors, like Ericsson, see an opportunity to make up any loss in professional services like integration. Others like Cisco see other ways of securing some of the benefits of SDN and NFV with less impact on vendor profits.
SDN/NFV network standards don't define operating practices
SDN and NFV have created a wave of enthusiastic interest, but they have yet to create a wave of deployment. Modest examples of both are in place today, offering service to customers, but progress in transforming operator infrastructure has been slow, even by telecom industry standards.
Why? The traditional role of network standards was to promote openness and interoperability. This meant SDN/NFV specifications started with components and interfaces, which is where open interface properties are developed. We know how an SDN switch or controller works, and we can define the interfaces and behaviors in an open way, so there's plenty of competition in making the components. We know how to deploy and connect virtual functions to mimic appliance behavior, too.
The problem is with the benefits. Neither SDN nor NFV defined new operating practices to match the new technologies. Yet both are dependent on cost savings from operations efficiency and on new service revenues gained from more agile service development and deployment. In effect, standards-driven initiatives to transform the network depend on the will of operators to take a step into an unknown future without specific benefits to justify the steps, and even without the hooks that link their new technologies to their current business systems and customers.
SDN and NFV solve real technical problems, and they present avenues to derive real bottom-line benefits. The standards-writers' view of network evolution focuses on solving technical problems, and there is little question that, in time, we would achieve a transformation to the cloud, data center and white-box future based on technical considerations alone. We'd achieve it faster if the benefits were properly harnessed.
This truth has generated a second wave of "standards" activity, in the form of open source projects. Unlike standards, open source projects create something directly consumable, something operators can build into networks directly. The OpenDaylight Project is an example of an open source project launched from SDN work. OPNFV, OPEN-O and OpenMANO (both open source orchestration projects), and Central Office Re-architected as a Datacenter are all aimed at producing the software needed for transformation. They include SDN and NFV standards, but extend them and complete them by defining how they relate to current service lifecycle processes and how they support evolution to the future from current infrastructure.
Standards define a future where vendors are consigned more to the role of building basic interchangeable elements rather than differentiable product families. This places a greater burden on the network operators because vendor profits cannot then guarantee vendor-driven innovation. Can the network of the future be built that way? Standards supporters believe it can be, but we have yet to prove that point. So, a standards vision of the network of the future is still in the future.
Show me the business benefits of SDN/NFV
Lack of device standards and tools hinder SDN
network orchestration and virtualization: Key to SDN flexibility
Where do OpenStack and NFV MANO meet?