What does “software” mean in SDN?
SDN is a nonsense term. Let me ask you this question, if you have a computer with no software loaded on it, what does that computer do other than suck up power? Nothing. “Nothing” is the correct answer. The idea of software is somewhat fuzzy these days as it can be code loaded on some kind of ROM that is pushed onto an FPGA or some other thing at boot. Some people decided to call this kind of thing “firmware.” Its not. Its just software stored on something other than a traditional disk.
Without software (be it “firmware” or not) your network node does nothing useful. It sits there. This is a fundamental concept in Computer “Science” and it goes all the way back to when software was contained on punch cards. A network node is really just a computer with specialized hardware. It needs software to tell the hardware to do something useful. Thats what IOS or JUNOS does. As it turns out, IOS and JUNOS are quite large these days. I have never considered IOS or JUNOS to be “firmware.” It is clearly software.
The difference between IOS and JUNOS and what is referred to as SDN is that intelligence isn’t distributed across some number of nodes cooperating to form a network. With SDN the intelligence is centralized and from this central entity network state is created and communicated to network nodes or even hosts. As has been pointed out numerous times, there is already a fairly long list of network technologies that have done this in the past and do this now. Are all those things considered SDN then?
What is SDN with respect to OpenFlow?
Consider the ONF’s definition of SDN: SDN consists of the ability to program the forwarding-plane of the network through an open interface. OpenFlow could be such an interface.
The OpenFlow pipeline is modeled somewhat after how traditional forwarding works. Borrowing from “Network Processors: Architecture, Programming, and Implementation” a forwarding path pipeline has the following stages: (1) Framing, (2) Parsing/Classification, (3) Search/Lookup, (4) Modification, (5) Compression/Encryption, (6) Queueing and then ultimately transmission. OpenFlow, loosely speaking, covers Steps 2 through 4 and then 6.
As it turns out, Openflow v1.1 through the current candidate version v1.3 have challenges being fully implemented in existing forwarding hardware. One could argue that Openflow adoption beyond v1.0 (and even this is not fully supported everywhere by all vendors) is, for the time being, hindered by this fact. Isn’t it strange that OpenFlow, which is thought of by many as the cornerstone of Software Defined Networking, is having adoption issues due to hardware limitations?
We could just run OpenFlow to a host running OVS right? There are hardware limitations there as well. If you want meaningful performance, apparently, you need a “TOE.” TOE’s do not currently support anything but a single VLAN tag in the frame header. So forget about MPLS or Q-in-Q. In fact, forget about any kind of overlay or tunneling except ones that are TCP based.
It seems its not possible to separate software from hardware.
What, then, is SDN and why will it fail?
More hype-bubbles have grown and popped in Silicon Valley than anywhere. The next big thing rarely sees mass adoption. SDN is a Silicon Valley hype-bubble. OpenFlow covers a narrow slice of what networking is. Central control of network functionality and networking on general-purpose hosts are old hat and, again, cover a narrow slice of what networking is. In short, SDN concepts are not sufficient to really be a revolution in networking. They’re just more pieces.
Delivering applications through the infrastructure is already immensely complex. Encapsulating that complexity and selling a product that manages it for the user ultimately means less flexibility. Networks need to be flexible. This is why networking has evolved the way it has. We have many smaller abstractions to work with, lego blocks if you will, to build the infinite variety of networks that exist today in support of the infinite variety of applications, and built in accordance with an infinite variety of business and security policies and budgets.
Certain highly repeatable patterns in networking could be automated with network programmability such as service-insertion, networking in support of virtual-compute, and even real-time management of QoS. In this case, network engineers will not be writing their own software: They will buy third-party products that solve specific problems on top of existing network deployments. What network engineers need to build and operate their networks are clearly defined and tested mechanisms for dealing with specific problems.
Its not clear at all what SDN is or what makes it “software defined.” Networking has always been software defined because hardware does nothing without software. In turn, software does nothing without the hardware to run it on. I’m not trying to be sophistic here at all. What I’m driving towards is that maybe SDN is just networking. Thats all it is. Do we care if there is a TCAM, or if the software runs on an x86 host? Whichever algorithms and hardware are used and how state is communicated to nodes doesn’t matter: the end-state is that we have achieved networking.
SDN can not sustain distinguishing itself from just “networking,” and without an identity of its own how can it be anything other than another tech hype bubble? What will come of SDN, ultimately, is twofold: (a) Improved programmatic control of the network for third-party applications that solve specific problems and (b) increased network functionality of hosts. What we are really witnessing in this and the DC fabric wars is the inevitable reconciliation of virtual-compute and networking.
As networking adapts and these concepts evolve and become clearly defined, SDN will fade. The apocalypse is not coming.
About Fail Toad
