Sergey Nivens - Fotolia
Continued from part one, virtual wires could emerge for use in network infrastructure of the future.
Software-defined networking and network functions virtualization are critical elements in the transformation of network infrastructure's journey to virtualization, and they are applied at opposite ends of the network infrastructure design spectrum. SDN is aimed at changing things from the bottom of the Open Systems Interconnection, or OSI, model -- redefining connection services and even networks by manipulating the forwarding of packets at the device level. So far, NFV is aiming above the connection layers of the network, adding features such as firewalls or Network Address Translation, or building mobile or content delivery services on top of IP. This could give new technologies two shots at driving changes -- or two places to fall short.
In an SDN-driven transformation of connection services, a virtual wire approach, discussed in part one of this article, would guarantee that a service-independent infrastructure would emerge, leaving a network infrastructure made up of optical devices, white box virtual-wire grooming devices and servers.
Since most current switches and routers can accept SDN controller management through the OpenFlow protocol, the use of virtual wires for a connection model could evolve. The challenge is to create benefits to justify each step along the way, since the use of virtual wires in small-scale SDN deployments wouldn't reduce Layer 2 or Layer 3 infrastructure costs, or improve its agility or operations efficiency. And operators would need to stay the course long enough to see benefits.
NFV's top-down transformation focuses on where service value is likely to be added -- above the connection layers of the network. Applications for NFV's approach exist in mobile and content delivery infrastructure today, but these transformations depend not only on deploying new hosted virtual functions to replace custom devices, but on creating service automation tools from the operational support system and billing support system level all the way down to deploying and connecting hosted service functions. Early NFV trials and tests haven't validated that level of service automation yet, and it's not clear what standards group or open source activity will provide the necessary tools.
Quickly addressing the challenges of NFV and SDN would transform network infrastructure design quickly, but even if neither NFV nor SDN moves as fast as operators hope, we will eventually end up in the age of virtual wires and software-defined, server-hosted features. It's important to remember when IP convergence was first introduced, most people thought the transformation it represented was too radical, yet convergence has been almost universally accepted today.
One reason for the inevitability of the transformation of network infrastructure design via NFV and SDN is the collateral explosion of interest in open source software tools to build both of these new technologies. Operators and vendors cooperating -- some more willingly than others -- in open source are driving new technologies forward, even where vendors are reluctant to make aggressive changes in order to protect their markets. In fact, if open source proves to be the fastest or only way to achieve next-generation network infrastructure design, it may be that vendor independence from the infrastructure of the future is as transforming as its technology options.
The network is changing, as it always has been. The pace of change is still a question, and it will be answered as we compare the costs, benefits and risks associated with new technology choices. One thing we know for sure is that virtualization of both services and resources will be the transforming force in the network of the future.
SDN and NFV: Check out how they complement each other
How NFV can make network architectures flexible and less costly
Where carriers can go to get help with NFV implementation
A look at NFV and SDN benefits in providers' network architecture