A Couple of Interesting Uses of OpenFlow

What can OpenFlow do to make your Network better?

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 interesting part of the story, though, is what  features the controller gives you. NEC America's ProgrammableFlow controller software chooses the best path for a new flow based on the following following items:

  • The number of hops
  • Weighted cost for each link
  • The 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.  The controller then looks at a various fields in the frame - typically source/destination MAC, IP, or port numbers - to make a decision about how to forward the frame. This part of the logic could be used to disallow a flow, for instance.

Once the controller decides that the flow is allowed, the controller considers all active links, and all paths between the source and destination switches. The choice of best path is based on the logic on the OpenFlow controller; in NEC America's ProgrammableFlow controller, it calculates the best path based on the least hops, least weighted cost, and least concurrent flows.

Note that the last of these varies over time, so the number of flows will be balanced over all the available links. For example, often times, multiple equal-hop paths exist for redundancy. Many of the OpenFlow proponents at the show said that automatic active balancing was one reason to use OpenFlow.  Yes, you can balance with Spanning Tree by changing the STP topology per VLAN or per STP instance, but in NEC America's implementation, you get balancing inside a VLAN, based on the number of flows.

Once the controller chooses the path for that flow, the controller pushes the forwarding table entries onto to the forwarding ASICs of all the switches in the chosen path. For future frames in that same flow, the switches already have a forwarding path programmed for their ASICs. And just in case it isn't obvious, the forwarding isn't based solely on the destination address, unlike the typical layer 2 switch logic today.

One other nice feature of the NEC switch that is enabled by the use of OpenFlow is something NEC calls a Virtual Network. Without OpenFlow, you of course create VLANs, assign access ports to VLANs, and possibly limit which VLANs flow over which trunks. In effect, you create a virtual local area network. When you move a server image, one of your tasks is to make sure the server still has connectivity to the same VLAN. And STP dictates the forwarding path to that server, or by whatever you might use for multipathing in your Data Center.

With these NEC switches, you can create a virtual network from a GUI. Say you want 10 servers to share the network, so you put them in the same virtual network. Later, when you move the devices, or a server through virtualization, the virtual network still exists, because the controller adjusts flows to accommodate the changes. Visually, the management tool hides the complexity at one level, and reacts to changes while you build out or change infrastructure - at least that's what I understand from a couple of conversations at the show.

Stanford's Elastic Tree

I also spoke with Nick Bastien, one of the Stanford researchers working on OpenFlow. He confirmed that while a lot of people understand the need for OpenFlow to aid research and development, many people at the show were asking him about what problems switch and router customers would solve by purchasing products that support OpenFlow. Nik discussed one such case that definitely thinks outside the box, and its a good example of the possibilities.

Nick described the concept called Elastic Tree, which is meant to be a better option than STP. As with most every OpenFlow application at layer 2, it replaces STP, because the controller chooses the path rather than relying on STP.  The question isn't whether OpenFlow replaces the traditional means of choosing a path (STP, OSPF, etc), but rather what logic it uses to choose that path, and that it does so on a per-flow rather than a per-destination basis.

The Elastic Tree concept adds the following features beyond simply choosing a good loop-free path:

  • Considers server performance (Perfmon) data to balance traffic across servers
  • Considers frame counts when adding new flows to load balance over all links
  • Monitors per-flow frame counts, and re-programs the flow path to prevent high-volume flows from impacting other flows

For instance, on the first item, imagine you have 10 servers that serve the same pages and data, and you balance traffic across those servers. The Elastic Tree logic on the controller considers server performance data, as fed from the servers to the OpenFlow controller. If one server is taking 10 ms to process requests, and another is taking 300 ms to service requests, the controller could choose the server instance with lower loading when programming the next flow.

Another cool idea is that flows are not necessarily static for their entire lives. Say a user cranks up a large FTP. The switches count the frames on interfaces, and that info can be fed to the controller. The controller, independent of a new flow being created, can watch for large volume flows, and re-program that flow path of flows to reduce contention. 

All of these features go far beyond what you could get with STP at least. Various server balancing features already in switched could be used to achieve similar results as well. But the idea that these kinds of features might be included in switches  across the board one day is a good example of what some of the folks pushing OpenFlow are trying to achieve. 

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Now read: Getting grounded in IoT