Software-defined networking first emerged as an answer to a problem: the increasing difficulty of trying to manage...
networks of devices for which traffic-handling was based on adaptive exchanges of information among the devices. While traditional traffic management requires explicit route control, adaptive route behavior that allows the path through the network to change as network conditions change makes that difficult. In addition, adaptive networks carry whatever traffic is presented, so they need to be secured by adding firewalls or other mechanisms outside the forwarding part of the network.
SDN was supposed to replace these traffic management issues with centrally managed connectivity. But, like many network technology shifts, it confronts the almost insurmountable barrier of the installed base. More than $300 billion of existing network assets have not been fully depreciated in existing networks. And writing down these assets so network operators can convert to software-defined networks simply isn't financially realistic.
By contrast, SDN has succeeded in areas that don't have a significant installed base to worry about. But most of these areas have been inside data centers. SDN's role in transport networks and in the WAN has been slow to develop -- in no small part because these networks evolve, rather than explode.
Where can SDN go from here? An obvious answer is still waiting for SDN players to claim it -- a new SDN transport role where it functions as virtual wire that can underlay SD-WAN, for traffic grooming in optical networks and to eliminate network latency -- an important mission to promote the internet of things.
SDN use for network transport as IP and Ethernet alternative
Let's look at the facts. The largest single area of network investment today is in IP infrastructure. IP absorbs the majority of network Opex, so current practices are also built around managing IP. The largest source of IP infrastructure is in the internet, and the scope of the internet is so vast that no existing software-defined networks are remotely comparable in scale.
A transition from IP to SDN seems risky and expensive, so it's unlikely to happen quickly -- if at all. That doesn't mean SDN can't play a role -- and quickly. In fact, by supporting a new transport role, SDN could be an alternative to Ethernet in the Metro Ethernet Forum's Third Network vision to move from static to dynamic, orchestrated network connectivity using SDN as one of the technologies. SDN could also be the universal network underlay for the exploding software-defined WAN opportunity.
A transport role for SDN makes sense, because it can forward IP packets in two ways without creating or being a part of an IP network. First, SDN can create a tunnel over which any kind of network traffic can pass seamlessly. In effect, this generates a virtual wire above the optical layer, but below traditional Layer 2 and 3 protocols. Second, SDN and OpenFlow forwarding can extend a simple point-to-point virtual wire model to a multipoint or multicast model -- one that includes IP or Ethernet routing and bridging capability using shared switches, but being partitioned fully from other services and users on those switches.
SDN's potential as SD-WAN network underlay
The reason creating smart-wires is interesting goes back to one of the fundamental concepts of layered protocols. In the old OSI model, higher layers, like IP and Ethernet, build on the services of the lower layers. If you make wires smart instead of dumb, the new capabilities they can support will simplify the demands of the layers above them. For example, if virtual wires can route themselves around failures using SDN's central control, fewer or even no failures will be reported on Ethernet or IP.
Smarter virtual wires could also be used to deliver LAN-like services, but they would do so much more efficiently. IP networks are built on Ethernet subnets, which is fine when the members of a subnet are all in the same place. But subnets can be wasteful and complicated if a virtual subnet is spread across a continent. Virtual wires with multipoint and multicast capabilities could deliver critical subnet features right to IP, and the connectivity could be laser-focused on the specific places where it's needed.
This is where SDN's potential as the underlay network technology for SD-WAN comes in. If you had smart virtual wires with multipoint and multicast capabilities, you could combine them with SD-WAN endpoints and build what looks like an IP or Ethernet service that has no routers or switches at all, except for the SDN switches that build the invisible tunnel layer below.
On the surface, an SDN mission as an underlay for SD-WAN may seem like another path requiring forklift infrastructure upgrades, but that's not necessarily true. SDN forwarding control, including virtual wire capability, can be provided in most switches and routers in use today, in parallel with traditional switching and routing. Network operators could offer agile virtual wire services without changing out their equipment. And if those services came to dominate, they could then gradually evolve to white box SDN switches, where appropriate.
SD-WAN is a tunnel overlay technology built over something else. In the past, usually that something else is Ethernet or IP. But if the purpose of the overlay is to build the entire network experience, then any service behavior built into the underlay network just adds to network operations complexity. A shift from smart underlays like Ethernet or IP to dumb underlays like SDN virtual wires will decrease operations difficulties and cost.
Using SDN where electrical meets optical
Virtual wire changes driven from above have a lot of potential, but the endgame for SDN in network transport applications is still where electrical meets optical. Optical network paths -- the wavelengths, or lambdas, in dense wavelength division multiplexing -- have steadily growing capacity. But there is a limit to the number of wavelengths a fiber strand can support, so you can't build the network of the future by providing everyone a wavelength to reach everyone else. Electrical traffic grooming is essential, and this is a perfect place to introduce transport-driven virtual wires.
Even if transport-level virtual wires were limited to point-to-point behavior, imagine a future network where every switch and router could be directly connected to all other switches and routers in the network, or at least to those with significant mutual traffic exchange. All of the latency created by handling traffic through interior switches and routers would disappear. This could be essential for internet-of-things applications, where latency issues could threaten the business case or even lives -- in the case of self-driving vehicles, for example.
SDN limited by lack of vision, not potential
Clearly, SDN isn't threatened by lack of opportunity as much as by lack of vision or commitment. Vendors are always reluctant to promote revolutionary changes in their markets, and operators and enterprises are often slow to take what they perceive as major risks to adopt a new technology. But those risks don't exist. SDN success simply builds on network behavior as old as networking itself. And that realization will be the real driver for SDN acceptance.
Take a look at three networking problems that benefit from SDN
How SDN will help IoT devices learn to share network resources
SD-WAN delivers benefits to those who know how to design it