SDN architectures

OpenFlow, SDN & an Industry Uprising

6:05 PM -- Software-defined networking (SDN) stands out as the singular concept that is both hard to define and hard to stop talking about. Dozens of companies that provide enterprise and cloud infrastructure want to separate the software elements that control the network from the network hardware itself.

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. Based on the conversations I've had this week at Interop , my feeling is that SDN -- of which the Open Networking Foundation 's OpenFlow is one example -- is nothing more than an industry uniting against entrenched powers and looking to disrupt the hold of one or two vendors that are so dominant that network innovation seems to move at the speed of their product cycles.

Would OpenFlow have momentum if cloud service providers felt like the top networking infrastructure vendors were listening to their customers and building switches and routers in a way that gave them control and the flexibility to create and provide new services?

Is it surprising that Amazon.com Inc. (Nasdaq: AMZN), Google (Nasdaq: GOOG) and some the earliest examples of major public cloud providers all wrote their own software and network stacks and used non-traditional infrastructure to start providing network services to their customers? Why? Couldn't they find a vendor to give them a cloud solution that was priced with cloud economics in mind?

This isn't to say that the networking infrastructure providers aren't cloud-capable. We ran a monster test of various Cisco Systems Inc. (Nasdaq: CSCO) cloud capabilities and you can see for yourself that Cisco does have a cloud(y) story. Cisco wants to give service providers the tools to handle delivery of any kind of content to any kind of device, where and when subscribers demand it.

But do service providers always want all those tools to be Cisco tools, delivered the way Cisco wants to build them, on Cisco's product development schedules, with Cisco's software controlling every aspect of every service? A lot will, actually. But what if some of those providers want to know if there's another way?

Each vendor I spoke to at Interop had its own take on SDN. John Roese, senior VP and general manager of Huawei Technologies Co. Ltd. 's U.S. R&D Center & Enterprise Business, told me not to get too excited about OpenFlow. It's a feature, not a product, he said. Oscar Rodriquez, Extreme Networks Inc. (Nasdaq: EXTR)'s CEO, told me that his company is better positioned to adjust the flexibility of a software-defined network because all of its products run a single operating system, a contrast to companies that grow by acquiring dozens of products and trying to make them all interoperate.

I doubt SDN will kill today's equipment giants, but it might make them more flexible. And it is safe to say that the value in this industry is shifting away from hardware. The virtualization of assets, and the control of that process, is just one element getting more attention. You can add up and double the value of Infinera Corp. (Nasdaq: INFN), Riverbed Technology Inc. (Nasdaq: RVBD), Alcatel-Lucent (NYSE: ALU), Extreme Networks and Juniper Networks Inc. (NYSE: JNPR), and you'd still need $6 billion to match VMware Inc. (NYSE: VMW)'s market capitalization. While we're measuring market caps, Cisco, with seven times as many employees, is only twice as valuable as VMWare.

So, yes, the buzz around SDN may be hard to sum up. But can it be measured? Big Switch Networks 's OpenFlowHub, a site that hosts open-source networking projects based on OpenFlow, is getting more than 28,000 page views per month. If today's networking innovation was moving as fast as the clouds forming overhead, I don't think that'd be happening.

For more

— Phil Harvey, Editor-in-Chief, Light Reading

Page 1 / 2   >   >>
Pete Baldwin 12/5/2012 | 5:33:08 PM
re: OpenFlow, SDN & an Industry Uprising

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.

DCITDave 12/5/2012 | 5:33:08 PM
re: OpenFlow, SDN & an Industry Uprising

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.

paolo.franzoi 12/5/2012 | 5:33:07 PM
re: OpenFlow, SDN & an Industry Uprising


Question:  Are customers asking for SDN or capability that could be done with SDN (and potentially dozens of other ways)?

I suspect the latter...but might want to get some interviews with the folks demanding this be in place.



fgoldstein 12/5/2012 | 5:33:03 PM
re: OpenFlow, SDN & an Industry Uprising

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.)

desiEngineer 12/5/2012 | 5:33:01 PM
re: OpenFlow, SDN & an Industry Uprising

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.


PS. A general musing: are SON and SDN somewhat at odds with each other?

fgoldstein 12/5/2012 | 5:33:00 PM
re: OpenFlow, SDN & an Industry Uprising

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).


DCITDave 12/5/2012 | 5:32:59 PM
re: OpenFlow, SDN & an Industry Uprising

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. 

tmmarvel 12/5/2012 | 5:32:57 PM
re: OpenFlow, SDN & an Industry Uprising

"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.

Sisyphus 12/5/2012 | 5:32:55 PM
re: OpenFlow, SDN & an Industry Uprising I 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.
desiEngineer 12/5/2012 | 5:32:52 PM
re: OpenFlow, SDN & an Industry Uprising


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.


Page 1 / 2   >   >>
Sign In