Aug 16, 2012

What does OpenFlow/SDN do differently than existing network technologies?

I've heard some buzz about OpenFlow/SDN being innovative and I know that there is a lot of support, but to be honest I'm not really sure what is all that new about it. I know the architecture is different, but HOW is it different, and what is the benefit of that difference? I guess the short way of asking it is, what does OpenFlow/SDN do differently from what we have now?


At CohesiveFT, we believe SDN is a broader domain than just OpenFlow as we elucidate below.  On the OpenFlow front we are big fans and becoming advocates as it is unbundling the monolithic service provider network stack and creating junctures for innovation.  Some of these innovations will be appearing in a data center near you next year, and some will take many years.  OpenFlow is an elegant opening foray into the kind of flexibility we have come to expect from componentized hardware and software - but have never had for the network. 

Virtual infrastructure is vastly different from “what we have now,” by the network segmentations for security, organizational, or application purposes that are now vestigial since application nodes run anywhere within a virtualized compute pool, and ideally the infrastructure operators know nothing about the application, its semantics, relationships or behaviors.

To emphasize the point, a cloud service provider wants to be able to spin up virtual computers as quickly as possible, terminate them quickly, provide access to virtualized storage slices, and give access to network resources (mostly in the form of "bulk anonymous transport"), and from a business success point of view needs this infrastructure to be easy to own, manage and operate, as well as increasingly, to federate.

Where does this meet with the concerns of the cloud application? As the cloud application and its "owner," I want application nodes in the form of virtual machines to go up and down quickly, I want access to storage, I want access to network resources, and from a business success point of view I need my applications in this infrastructure easy to own, manage and operate - as well as increasingly - to federate.

The needs and concerns of the cloud service provider are distinctly different than the needs and concerns of the cloud service user (the application topology deployed to the cloud and its owner). We call this the service provider-controlled layers and the application-controlled layer.

In the symmetry above, the needs and concerns of cloud provider and application user sound similar if not the same, but they are not. One set is from the point of view of the "landlord" and the other from the point of view of the "tenant.”

We, at CohesiveFT, embrace the terms of software defined networking and network virtualization, and believe that like the phrases computer virtualization and storage virtualization, network virtualization will be a "big tent" encompassing many overlapping, orthogonal, and complementary facets of the broad concept. Please check out our White Paper for more of our thoughts on SDN and our “big tent” proposal. 



Thanks for the answer and link.  I'll have to read some more about OpenFlow.  The potential increase in  network efficiency by separating packet switching and management is intriguing.  I would love to be able to achieve significantly higher percentage network usage, so that usable network capacity could be increased without actually increasing capacity!  I will have to do some more reading on this.  Thanks again!  

Here's a good background article:


"OpenFlow is a communications protocol that gives access to the forwarding plane of a network switch or router over the network.[1] In simpler terms, OpenFlow allows the path of network packets through the network of switches to be determined by software running on multiple routers (minimum two of them — primary and secondary — has a role of observers). This separation of the control from the forwarding allows for more sophisticated traffic management than is feasible using access control lists (ACLs) and routing protocols. Its inventors consider OpenFlow an enabler of Software Defined Networking.[2]"

Here's another:


"What is OpenFlow?
OpenFlow is an open standard that enables researchers to run experimental protocols in the campus networks we use every day. OpenFlow is added as a feature to commercial Ethernet switches, routers and wireless access points – and provides a standardized hook to allow researchers to run experiments, without requiring vendors to expose the internal workings of their network devices. OpenFlow is currently being implemented by major vendors, with OpenFlow-enabled switches now commercially available.

How does OpenFlow work?
In a classical router or switch, the fast packet forwarding (data path) and the high level routing decisions (control path) occur on the same device. An OpenFlow Switch separates these two functions. The data path portion still resides on the switch, while high-level routing decisions are moved to a separate controller, typically a standard server. The OpenFlow Switch and Controller communicate via the OpenFlow protocol, which defines messages, such as packet-received, send-packet-out, modify-forwarding-table, and get-stats.

The data path of an OpenFlow Switch presents a clean flow table abstraction; each flow table entry contains a set of packet fields to match, and an action (such as send-out-port, modify-field, or drop). When an OpenFlow Switch receives a packet it has never seen before, for which it has no matching flow entries, it sends this packet to the controller. The controller then makes a decision on how to handle this packet. It can drop the packet, or it can add a flow entry directing the switch on how to forward similar packets in the future."
Answer this