It’s obvious that software defined networking is the “next big thing”, at least from the perspective of the media and those few VCs prepared to invest in infrastructure. In the last couple weeks we’ve seen some new details on SDN plans from Plexxi, a long-standing stealth startup in the space, and news that “MPLS fiend” Kireeti Kompella has left Juniper for another SDN startup, Contrail Systems. These developments have a narrow and broader context, and I propose to address both, with the broader one first.
In our industry, “next big things” are always characterized by a phenomena I’ll call “tagging on”. A player in the market knows the media loves novelty (which is what “news” means, after all) and so they know that a story on SDN is going to play better with editors than one on data center switching or fabrics. Thus, they bend the outlines of the concept of SDN a bit to make their own stuff fit, and sing away. The result is that popular notions quickly lose shape and substance. That’s surely the case with SDNs. Software defined networking, as I’ve pointed out, isn’t “software defined data centers” or “software defined virtualization”. A network is a cooperating collection of devices that generate the service of connectivity, and to software-define it is to software-define how that service works. I don’t think that you can call an approach that software-defines a piece of a network or one of its missions as an SDN.
That doesn’t mean that these things can’t be a piece of the SDN puzzle, or that these missions can’t be contained within the broader SDN mission. In fact, the interesting thing about SDN is that there are things—lots of things—that belong in it and aren’t being put there. Let me give you the biggest example; APIs.
All sorts of network devices and network software elements expose application program interfaces. Presumably the purpose of these interfaces is to control behavior of the devices/elements, and since they’re “network devices” and “network software elements” the thing they’re controlling is the network, right? OK, let’s continue on this track. An API is exercised by software, right? That means that EVERY NETWORK DEVICE OR FUNCTIONAL API SHOULD HAVE A PLACE IN AN SDN FRAMEWORK. Otherwise we’re controlling the network with stuff that’s outside the scope of the concept we’ve designed for application control of the network!
Before you rush to the barricades on a wanton expansion of things like OpenFlow, let me explain that I don’t mean that SDN standards have to embrace every API out there. SDN concepts are based on the familiar principle of abstraction; a network is a cooperative system and can be represented by a black box that is described by the relationship between its inputs and outputs, another way of saying “by its services”. A high-level network abstraction (like “LAN” or “Tree” or “Line”) has to map downward to devices to create the cooperative behavior we need. The SDN standards will eventually have to deal with how those high-level abstractions are communicated, but they also have to deal with how they’re decomposed to the device level. That’s critical in building SDNs from current equipment and also critical for building SDN equipment, if it comes to that.
Every single vendor who purports to support SDNs should be providing us with a nice map that shows how their SDN solution builds upward from devices to a set of abstractions that an application could be expected to use as its description of the network services it needs. Pretty much every vendor in the network space says they support SDNs, and yet we don’t have that map from any of them. I, for one, want to see it from them all because only with that sort of map can we relate the current infrastructure with the evolution to SDN.
On the narrow side, you can see from what Plexxi has said and by the limited comment on Contrail Systems’ website that their focus is on the data center. Plexxi is an optical-linked data center fabric; Contrail’s details aren’t yet known but its focus is the same. Why the push on the data center? I think there are three reasons—budget influence, infrastructure inertia, and the cloud. Network budgets have been controlled by the data center for years. Infrastructure in the broad Internet has too much sunk cost to be quickly displaced, so it’s an unattractive startup target. Finally, the cloud is first and foremost a network of IT resources, which is a data center network.
But a data center network is not SDN, or at least not all of it. The data center focus, which is a focus of convenience, is a part of the network but not the whole of it. To get to the rest, you need to envelope the notion of data center virtualization in a real SDN abstraction, then link that abstraction to the APIs that control current device and network behavior. This is the SDN mission that incumbent vendors should embrace, not only because they have that current equipment and APIs but because they then elevate the marketing dialog to a level where they can win over limited-focus startups. Unless, of course, one of those startups does the job first. Might Plexii or Contrail or Big Switch do that? We’ll see.