An Attempt to Motivate and Clarify Software-Defined Networking (SDN) « Network Heresy. What Might an SDN Controller API Look Like? (and should we standardize it?) « Network Heresy. [This post is written by Teemu Koponen, and Martin Casado.
Teemu has architected and been involved in the implementation of multiple widely used OpenFlow controllers.] Over the last year, there has been some discussion within the OpenFlow and broader SDN community about designing and standardizing a controller API in addition to the switch interface. To be honest, standardizing a controller API sounds like a poor idea. The controller is software, not a protocol. To our knowledge there are 9 controllers in the wild today, and more than half of them are open source. (yeah ok, this comic is only tangentially relevant … ) In addition to being a waste of time, premature standardization could be detrimental to the SDN effort. Further, it’s not clear how to design and standardize an interface to a (non-existent) large software system out of whole cloth. For SDN in particular, there is really very little experience building controllers systems in the wild today. Common Controller Types. Big Switch Networks » Kyle’s Blog. Openflow Ppt Presentation.
Cisco Cert Zone: A Couple of Interesting Uses of OpenFlow. At the beginning of Interop, I wrote a post that introduced the basics of OpenFlow.
I promised to ask around and find out what problems different vendors are trying to solve using OpenFlow. This post highlights two cases: one you can order today from NEC America, and the other a case that's been tested at Stanford. NEC America's ProgrammableFlow Switch NEC America announced at Interop a new switch based on OpenFlow.
Branded ProgrammableFlow, the switches support OpenFlow. The number of hopsWeighted cost for each linkThe Number of existing flows For example, when a switch receives a frame, if there is no existing match in the forwarding table, the switch forwards the frame to the controller. Once the controller decides that the flow is allowed, the controller considers all active links, and all paths between the source and destination switches. Note that the last of these varies over time, so the number of flows will be balanced over all the available links. Scott Shenker. On data center scale, OpenFlow, and SDN. Lately I’ve been thinking about the potential applicability of OpenFlow to massively scalable data centers.
A common building block of a massive cloud data center is a cluster, a grouping of racks and servers with a common profile of inter-rack bandwidth and latency characteristics. One of the primary challenges in building networks for a massive cluster of servers (600-1000 racks) is the scalability of the network switch control plane. click to enlarge Simplistically speaking, the basic job of a network switch is to make a forwarding decision (control plane) and subsequently forward the data toward a destination (data plane).
In the networking context, the phrase “control plane” might mean different things to different people. To make forwarding decisions very quickly, the network switch is equipped with very specialized memory resources (TCAM) to hold the forwarding information. Making a forwarding decision requires having information. Exciting times ahead. Cheers, Brad. Software Load Balancing using Software Defined Networking. I invited Nikhil Handigol to present at Amazon earlier this week.
Nikhil is a Phd candidate at Stanford University working with networking legend Nick McKeown on the Software Defined Networking team. Software defined networking is an concept coined by Nick where the research team is separating the networking control plane from the data plane. The goal is a fast and dumb routing engine with the control plane factored out and supporting an open programming platform. From Nikil’s presentation, we see the control plane hoisted up to a central, replicated network O/S configuring the distributed routing engines in each switch. One implementation of software defined networking is OpenFlow where each router supports the OpenFlow protocol and a central OpenFlow Controller computes routing tables that are installed in each router: Today, most networking equipment is shipped as a vertically integrated stack including both the control and data planes.
--jrh James Hamilton e: jrh@mvdirona.com w: b: / Open vSwitch. VMware: Let’s get logical – the case for OpenFlow network virtualization (and their failed network plans) OpenFlow Group News. There has been a lot of chatter on OpenFlow lately.
Unsurprisingly, the vast majority is unguided hype and clueless naysaying. However, there have also been some very thoughtful blogs which, in my opinion, focus on some of the important issues without elevating it to something it isn’t. Here are some of my favorites: I would suggesting reading all three if you haven’t already. In any case, the goal of this post is to provide some background on OpenFlow which seems to be missing outside of the crowd in which it was created and has been used. Quickly, what is OpenFlow? Initially, OpenFlow attempted to define what a switch datpath should look like (first as one large TCAM, and then multiple in succession). And just as quickly, what isn’t OpenFlow? So, it’s reasonable to ask, why then is OpenFlow needed? Why is this? Consider system design in traditional networking versus modern distributed software development.
Traditional Networking (Protocol design): So, what sucks about this? Scale?