This summer seems to have been the era of Software Defined Networks' self-analysis and self-doubt period, where wags insist SDN really stands for "Still Does Nothing," and dozens of blog posts appear that resemble Silver Peak Systems' droll inquiry about what potential users might even mean by SDN.

However, this necessary analysis needs to move up a notch. The end goal of configuring and managing networks through protocols is an admirable one. Over time, it seems natural to assume that physical-layer networks can be reconfigured from Layer 7 of the OSI Protocol stack, the application layer. In the near term, SDN advocates call for the control of physical and data-plane layers through software running on Layers 3 through 5, software that abstracts the details of the switches directly touching packets. In essence, a controller assumes the network-defining role played by routers and switches in traditional networks.

This is all well and good, and represents the way network managers will be making a slow climb up the OSI protocol stack in the way they manage modern networks. But as we focus in on particular details of real-world LANs, WANs, SANs, and clouds that cover multiple network types, we find that the benefits of using OpenFlow protocols for abstraction may not be readily apparent in every case.

The sticky part of this debate resembles that of another highly-touted software technology of the last decade, Software Defined Radio (SDR). The Defense Department poured more than $6 billion into SDR in order to gain a tactical radio that could change its air interface and frequency band through reprogrammability. Nothing was wrong with the concept in practice, nor was its utility in the real world infeasible – but true reprogrammability required several minutes of reboot time, which made SDR largely useless in a real-time battlefield environment. There is a lesson to be learned here for both enterprise and service provider wireline networks.

Network managers, and occasionally even hardware developers, have been sold on the concept that a high-layer controller speaking OpenFlow protocols could easily change the islands of virtualization, the SAN/LAN boundary, and perhaps even the Layer 2 and 3 protocols of a particular subnetwork. Sure, most networks have settled on Ethernet and TCP/IP, but there could be advantages to shifting on the fly to certain low-latency industrial or SAN-based protocols on a temporary basis.

The story in theory makes a lot of sense, but as Greg Ferro pointed out in a recent Network Computing post, SDN was never a technology in and of itself, but a usage case for modifying installed networks.

Yes, OpenFlow was a protocol defined directly for SDN by the Open Network Foundation, but the concept is not that much different from Cisco's label-switched routing, Ipsilon's IP switching, or the many deterministic protocols developed for Asynchronous Transfer Mode. Just because many hardware vendors have signed on to declare OpenFlow to be "open," does not give the protocol magical properties.

At the end of the day, a network manager must work with the physical layer network that exists. Coaxial interconnect may be replaced with multimode or single-mode fiber, specific switches may be converted from 4G Fibre Channel to 40G or 100G Ethernet, but the use of a software controller does not change the underlying qualities of the physical layer and data plane layer. The speed of packet forwarding, the opportunity for virtualization, the serial-access or storage subnetworks, all depend to a large extent on the underlying hardware.  SDN does not change that.

Here are some of the experiments network managers can run with the first-generation OpenFlow products that exist today: Users can choose between symmetric and asymmetric models of distributing information. Managers can utilize familiar flood-based multicast or broadcast methods of packet distribution, or they can play with new SDN floodless models, in which packets are only forwarded in a global exact-match, using caching and hashing methods. In a data center making heavy use of virtualization, network managers can experiment between centralized and host-based SDN models.

In all these cases, careful attention must be paid to the price of software-based SDN controllers. With the plummeting price of edge switching and routing hardware, the same capabilities may be gained at a lower price tag by adding more physical hardware, or perhaps adding PCIe cards and middleware that perform some simple protocol conversions at Layer 2.

Remember, networking technology inevitably will move up the protocol stack, allowing greater levels of abstraction that eventually move direct switch and router control all the way up to Layer 7. That does not mean that an end-to-end OpenFlow SDN topology is the best choice today for a given network that is already largely predefined by its hardware. SDN is a nascent concept that does not offer real-time software reconfiguration of a physical network today. It may never offer such a total reconfiguration and management domain. Network managers must weigh all the feature sets and price tags to determine the layer at which it makes the most sense to control the network.