Yesterday, Brocade announced enhancements to its SDN Controller that advanced SDN in an operations sense. I think these were important; they move SDN toward the architecture it should have been from the first. They also show us just how far SDN still has to go for it to achieve all it can.
What Brocade has announced is a Flow Manager and a Topology Manager that essentially ride the SDN controller and provide a way of visualizing the structure of SDN switches and the way that consecutive forwarding processes (imposed per-switch as the OpenFlow approach mandates) add up to supporting a flow or route. The products are highly visual, meaning that you can easily see what’s happening and manipulate connectivity to suit your specific needs.
Way back in the early days of SDN, I hypothesized an architecture of three layers. On the bottom was the topologizer, an element responsible for determining what the physical device and trunk structure of the network was. In the middle was what I called SDN central, the critical piece that aligned flows and topology. The top layer was what I called the “cloudifier”, a layer that would frame SDN’s almost infinitely variable connectivity options into services that could really be consumed. The “northbound interface” of the SDN controller would logically fit below these layers.
Brocade has taken an important step by providing us with specific implementations of the bottom two of my layers. Instead of blowing kisses at a vague notion of a northbound interface, users can see what they are doing. It’s an important step in operationalizing SDN for sure. But it’s not a home run, at least not yet.
One specific statement from Brocade’s website sets the stage for the “miles-to-go-before-we-sleep” part of this discussion. “Software-Defined Networking provides dynamic, end-to-end views and control of data center traffic.” Obviously SDN isn’t limited to the data center, but it does seem as though Brocade is telling us something important. SDN has been successful largely within the data center, and so SDN’s longer-term success will likely depend on extending from that base into the rest of the network. I described such an evolution for network operators in my blog yesterday. SDN has to make the transition to the network from the data center, for both enterprises and operators, if it’s to be really important.
The notion of flows and topologies that Brocade has introduced could play a role in that. The first thing you have to do to get SDN out of the data center is to automate operations and management. If we can use a GUI to drop flow paths where we want them, it is clearly possible to provide a tool that would define the paths based on policy. I don’t think this would be a big technical issue for Brocade. The larger problem to address is the management side.
Inside a data center you have unusually high reliability and you can probably stand on a chair and survey your network domain, looking presumably for smoke or some sign of failure. The number of flows you have to support is also likely to be limited. Get into the wider network and you need to have automated service management, and that means you have to be able to associate physical device and trunk conditions to connectivity. Brocade takes a step in that direction too, because they have in a flow a map of the resource commitments. If you drew data from MIBs along a flow, you could figure out what the flow state was. If you had a flow problem you could trace it to the likely fault point.
The notion of a flow problem leads to the question of a flow standard, meaning an SLA, and the need to connect flows into groups to make up a logical service. Brocade still needs to mature a vision of my “cloudifier”, the service layer that converts application/user requests for cohesive network behaviors into a series of flows that can map to the real device topology.
There may be help on the way here. The ONF is taking up the notion of an intent model for northbound interfaces. A true intent model would include an SLA, and that implies that an implementation would be able to collect management variables not only for a flow but for a set of related flows, and present them as a composite service state to be compared with the performance guarantees set for the service. Brocade could implement this, and if they did they’d climb the SDN value chain up to the top.
A lot of the things needed to achieve SDN’s optimum future is at least partially supported within the SDN controller, at least the OpenDaylight version that Brocade and many others use. What’s missing? Interestingly, it might be the vision of service/resource management and operations that many have talked about for both SDN and NFV in the operator space.
In an SDN age, enterprises are “network operators” at least to the extent that they build SDN overlays on more traditional services. In the future, if operators themselves expose “cloudifier” types of service interfaces to permit flow composition into services, the enterprises will still have to harmonize those with internal site connectivity. We already know that the “enterprise network” is the sum of its LANs and WANs. We may not need all the tools for enterprise SDN that we’d need for operator SDN, but it’s easy to see that we’d want a subset of those tools. And it’s easier to subset something if you’ve got it to begin with, in a complete and cohesive form.
I think Brocade’s move is demonstrating that “network management” for the enterprise is going to shift just as decisively as service and network operations are shifting for the operators. I also think that a future SDN network where users compose their connectivity by application and job type is going to demand a complete rethinking of how we know what a network is. The “I’ll-know-it-when-I-see-it” model isn’t going to work in the virtual world. Brocade may be working on the replacement.