Pretty much everybody agrees the SDN craze is being driven by customer requirements. This is a more blunt translation of that statement, and I think there might be a lot of truth to it.
And it could be that even if it fails it succeeds, if indeed a lot of the interest around SDN is coming from the feeling that networking platforms aren't flexible enough now, are too hard to manage, don't support enough virtual machines per rack, etc.
Openflow is a good idea, viewed by itself, though less radical than they make it sound. If you think about it, current mainstream router architecture is daft. Every router in an AS or on the backbone typiically needs to know about every link or at least address block, and od its own routing calculations. So the IGPs or BGP pass around huge volumes of information which is processed asynchronously by all of the routers.
Now i can understand why this is needed on the BGP backbone, since the routers are owned by different parties. But within an AS, it would make more sense to let a server compute the routes for everyone and download them into the machines, which is what Openflow is doing. Not that this is a new idea; Tymnet was doing it in the 1970s. It's just that the IP world went the other way and everyone assumed it was The One True Path. One more example of the naked emperor called TCP/IP.
What the Openflow folks seem to not realize is that maintaining these tables is really a network management function. They don't need a new protocol; they should be doing with a network management protocol. Of course SNMP is far too lame for this. CMIP would be fine, though. (Actually, there are hardly any applications that couldn't be coded in CMIP, a general-purpose application protocol whose most common application happens to be management.)
I echo the sentiment that OpenFlow is not a radical idea: it sort of boils down, in SNMP-ese, to whose Enterprise MIB we vote is the best. But before you dismiss the IP routing paradigm summarily, recognize that:
- networks have grown since the Tymnet days
- a central compute server is never going to be timely enough (aka Heisenberg's Uncertainty Principle of Networking: "You can know or you can route, but you can't do both perfectly.")
- you are sort of advocating SONET over IP
In general, the whole world is going to distributed processing with many, smaller devices, acting in concert, rather than a centralized model. Take mainframes vs. supercomputers; multi-core processors vs. single mammoth processors; even how DES was hacked.
If we just clothe the emperor, wouldn't that be easier than finding a new emperor? I don't see the current emperor abdicating its throne just yet.
-desi
PS. A general musing: are SON and SDN somewhat at odds with each other?
desi, Tymnet was a reasonably large network; most corporate networks and data centers are not all that much larger. Centralized routing allows the decision to be made based upon a relatively consistent view of the network, from the point of view of the controller. Fully-distributed routing, as it is done more often, allows for loops and other error conditions caused by inconsitent information. When you run the SPF algorithm on a set of links, you can compute the best path from any node to any other, so why does every node need all of the link information? It's redundant and inefficient.
It also seems to me that you're attempting to bring up SONET as a pejorative. I would never advocate SONET over IP. SONET's beauty is in synchrony and its ability to preicsely pass clock; that's lost over IP. And IP in practice is horribly complex. IP over SONET makes more sense, as it lets you use SONET without the IP too. TCP/IP is the real problem; it's a senescent ancient lab experiment that, like a Canticle for Liebowitz, got accidentally turned into canon. And since most people under 50 years old never used anything else, they have no idea that there could be alternatives (not older protocols, but newer ones -- in the old days, we didn't have a monoculture so we didn't equate all of networking to one thing).
I think the core attributes of SDN can probably be accomplished in several ways. The industry support around OpenFlow, I think, is mainly a reaction from cloud and data center providers that say the big networking vendors aren't listening to them.
"The big idea -- and this is a classic tech industry argument -- is that you can accomplish more by separating the operating system from the applications, the operating system from the hardware and, in cloud computing, the server from the service."
Certainly in agreement with the last part: services need to be abstracted from any server hw/sw/vm. And we need to focus on the services, not on hardware OR software.
Regarding the layered model with independent apps, OS and hardware layers: like it or not, this leads to SDN becoming hardware-limited-networking, and OS-limited-networking. Apps cannot do what OS does not support, and OS software cannot make up for lack of hardware capabilities.
This apps/OS/hw perspective comes from computing world, where there are fewer (often none) hard-realtime constraints. In networking, vast majority of the system functionality absolutely has to happen in hardware, without software involvement -- the router/switch interfaces need to process hundreds of millions of packets/frames per second, individual packet requiring thousands of operations (plus the need for inter process coordination between packets) so software on regular microprocessors cannot handle traffic on these line rates.
The hardware capabilities thus are critical. And even more essential is service innovation, irrespective of how the services are implemented (with or without SDN etc.). In practice, in networking, innovation does have to reach to the hardware level to have a noticeable impact. In fact, one should look for hardware(+app software)-as-a-service type of cross-layer innovation.
It is much easier to be inter-operable at high-level service (e.g. network connectivity service, or application service) layers, than to be compatible with legacy products at lower layers (e.g. IP/Ethernet control and data plane protocol layers). And the cross-layer optimization approach also provides much greater potential for efficiency gains and novel application and service concepts.
We need novel services, enabled by free-thinking innovation from hardware level up.
re: OpenFlow, SDN & an Industry UprisingI think SDN and openflow should not be confused - one is an architectural principle, the other a protocol-API. The latter is definitely driven by 2 major forces: academia, and massively scalable data center architectures that are hampered by several of the traditional network protocol constructs.
Clearly you read more into what I wrote than what I wrote. SONET vs TCP/IP is more of a model question: SONET as the "lay out your network" and TCP/IP as the "let the network figure itself out". I put them up for comparison because the world has chosen to go in one direction.
Other network protocols than TCP/IP have run in large networks, not as science projects, but have also fallen by the wayside. Much of that has been done because openness and participation by academia are viewed as a virtue. I think when one protocol or style dominates, it becomes closed because it is too big to change. That's why IPv6 or TCP SACK are not widespread.
I suggested fixing TCP/IP as the path of lesser resistance. Wishing TCP/IP away is not a practical alternative. It's one of those "too big to fail" kinds of situations where we are being forced to pick between Armageddon and the unknown, and we choose the status quo.
Pretty much everybody agrees the SDN craze is being driven by customer requirements. This is a more blunt translation of that statement, and I think there might be a lot of truth to it.