One of the problems with the whole SDN thing is that it’s so abstract. We have a combination of a few dedicated researchers who are doing the usual egghead stuff, and a lot of media types picking at the topic. The good news is that this is coming to an end; we’re getting actual SDN products and that will tend (I hope) to focus the dialog better.
SDN products mean SDN switches in my view; we need SDN-specific devices to prove out an SDN endgame. The current focus on SDN controllers running software in existing devices is a transition strategy, but you have to establish what you’re transitioning to and prove its benefit case. Logically we’d expect SDN to start in the data center, where the cloud starts and the controlling software is likely to run, and Plexxi has now given us a look at an SDN data center strategy. Happily it includes both a controller and switches.
At the hardware level, Plexxi offers a modified version of a fabric switch (or a fabricized version of a rack switch, depending on your perspective), and it’s here that you find the first important element of their story. I’ve commented before about the fact that virtual networking overlay strategies like Nicira can’t manage capacity because they run over top of devices and not on them. As a result they recommend having low levels of utilization to prevent performance issues on some virtual paths due to (invisible-to-them) congestion. This suggests a pure fabric data center connection network; any-to-any seamless connectivity. The problem with THAT is that most of those “anys” don’t need to talk to most of the others; few possible paths are actually useful and some are security risks. And, of course, all this extra capacity costs.
Plexxi’s approach is to create a high-capacity optical “bus” that interconnects the chassis of their switch. The capacity isn’t infinite, but you can allocate it in an infinite number of ways. The idea is to give capacity to the paths that represent useful connectivity and deny the rest, thus saving yourself from having to pay to provide connectivity your security system will then have to limit. The cost advantage of this over a true fabric will vary, but it could be sizeable.
The trick here is how you give capacity to those useful paths. To save users from a traffic engineering marathon, Plexxi introduced something truly unique and interesting, the concept of AFFINITY. Affinity is a computational/algorithmic mechanism for analyzing traffic and connection topology and deriving the optimum topology to support it. Since the paths through the optical “bus” are flexible, you can build the structure without regard for the physical connections or device locations. Affinities create something above the physical hardware and fiber and below the protocols. The Plexxi Control software, which is the “software” that “defines” the SDN, is what manages the affinities, and the Affinity network is both a virtual network without traditional Ethernet VLAN limitations and a physical network that can manage traffic and connectivity.
Each Plexxi Switch has a Control element, all bound to a central controller that’s conceptually similar to the central concept of OpenFlow control, but different in that it contains the necessary logic to drive the path creation process, where OpenFlow Controllers manage individual forwarding tables and context to create “networks” has to come from some non-specified higher layer. There are what might be called rule sets to define Affinities of various types, and by growing the complement of these Plexxi plans to create a dynamic evolution of off-the-shelf service models. Users can still define their own approaches, of course, and all this stuff is accessible via open APIs to be integrated with other software as desired.
What Plexxi lacks at the moment is specific support for OpenFlow, either as an interface to its switch or as a southbound option from its controller (it’s likely to come along later, but nothing official yet). Some people are probably going to be fluffed up over this, but the challenge Plexxi poses is how you value functionality versus standards at a time when standards are significantly behind the state of market needs. The work on linking optics to OpenFlow, for example, is only beginning, and there’s nothing happening at that higher layer where individual forwarding tables fuse into a network, or rather ARE FUSED into one, under software control. One handoff doesn’t make a bucket brigade. My own position on this issue is clear; we need the value of SDN before we worry about the standards, since standards bodies have demonstrated they can NEVER keep up with the market.
Plexxi’s stuff is available; there are early (unnamed) customers for it, one of which is a cloud provider. The Affinity concept is, I think, a critical step forward in that it defines a way of making a virtual network physical enough to manage traffic and availability fully. There may be other ways, but until somebody offers them we can’t draw a comparison. I’m happy just to have one solid picture to look at. As I said, maybe this sort of thing will help advance the SDN dialog.