We’re likely going to see a lot of “SDN announcements” in 2013, most of which will (like most of what we’ve seen already) be marketing crap. The simple truth is that SDN is about central control over packet forwarding. If you’re not centrally controlled, you’re not SDN. If you aren’t about forwarding packets you aren’t SDN. If you don’t want me to say “They’re not SDN!” about your stuff then don’t brief me—you might get lucky and I’ll overlook you. But I digress. If SDN is central control over packet forwarding, then you have to tune the control to the forwarding mission, and it may be that the archetypal SDN element, OpenFlow, is tuned to something less than the optimum mission.
The problem is that if you look at OpenFlow, you find a concept of “mother-may-I” forwarding in there. The SDN device gets a packet for which it has no flow rule, so it sends it off to the central controller for analysis, and the controller presumably then sets up forwarding rules not only in the requesting SDN device but in other devices that would make up a path for packets of that type. Obviously this is not scalable to Internet or even large enterprise size. And nearly all the SDN types I talk with say “Hey, we know that; we’d build the routes from a route source without those central-hand-off packets.” So problem solved? Maybe not.
If you look at OpenFlow even more closely, you’ll be struck by the fact that the protocol sends forwarding table changes in something very close to what a forwarding table would look like. There are also discussions about how difficult it might be to “compile” the forwarding table changes into an actual table entry at a high speed. At the same time, you see that it’s necessary to get pretty specific about what parts of a packet header you look at and how you look, and also that it’s hard to cleanly define how OpenFlow might be used to command forwarding changes where the packets aren’t visible. Think optics. It’s clear that we’re seeing a compromise in design, a balancing between having a protocol exchange in a format easily converted into a forwarding entry and having one that’s more flexible. And we’re seeing features that are more justified by an open connectivity model in a protocol likely to be used in a closed, non-volatile, domain.
So here’s my point. Suppose we were to take that domain mission and design a protocol for it. We’d likely say that we need to have a generalized way of representing what we want to connect, not just packet mask-and-match, so perhaps we’d have several classes of flow designators, one being packet-header, a second being lambda in WDM, and perhaps a third being TDM channel. We’d also likely want to think beyond forwarding as the only action. OpenFlow already has to deal with encapsulating and “de-capsulating”. Don’t we have other initiatives like NFV out there? Doesn’t NFV work more on deeper inspection and doesn’t it have more actions than simply forwarding?
I suspect that if we were to design a switch control protocol for the real mission, for all the kinds of traffic we might like to control, we’d end up with something more like an XML schema than like OpenFlow. Yes, I know that some will cry out here that it would be terribly inefficient, but efficiency has to be measured against the total impact of the overhead it creates, and if you’re using OpenFlow to push lambda connections around you’re probably not doing so at the speed of a Keystone Kop directing traffic. And if we had a more schema-oriented structure we could accommodate port parameterization, state and status exchange, and all of the stuff we’re kludging in—or ignoring—now.
No matter what, we are not going to software-host high-performance routers and switches. Look at Cisco’s virtual router and its performance requirements; it needs to own pretty much all of the CPU resources of a typical multi-core server just to run. Communications devices will be specialized in the data handling plane because it’s worthwhile. That specialization has to be matched with flexibility at the mission level, and the matching means having some control software than can decode general statements of requirements and translate them to “handling rules” and not just forwarding rules. So before we get too far with SDN, and before we get anywhere at all with NFV, we need to think about the question of the best way to control data-plane handling from off the box.
