Cisco announced that it would support OpenFlow, the protocol that’s sometimes seen as the pathway to an open-source router market that could kill Cisco off. The move only demonstrates how useless it is to read stuff these days! In a neutrality-driven world with no settlement for QoS among ISPs and no regulatory basis for creating premium for-pay Internet services, there’s precious little to be gained by a protocol that lets software control the network’s forwarding tables. Such gain as there is would be best accommodated inside a current router framework, not in a replacement to one. I have an exploration of OpenFlow in the October Netwatcher, so if you’re interested you might want to check it out (if you subscribe!)
The most significant thing about OpenFlow is the notion of a “Software-Defined Network”, meaning a layer of service/network control that’s explicitly software and explicitly hosted above the devices. I think this is a technology-level driver toward an independent service layer, something that’s mandatory for top-down reasons as well. Cisco’s support of SDNs may mean that Cisco will rejuvenate its own service-layer plans, since it rarely supports populizing standards except in the context of a larger proprietary envelope to supply Cisco differentiation.
Alcatel-Lucent had an interesting announcement too, a Bluetooth-based application called the Intelligent Travel Time System (ITTS) that gathers traffic information from the RF that various car and phone gadgets emit and provides information on the management of vehicle flow and a framework for optimizing the way that traffic lights and other stuff works. This is an example of what I’ve called “the Network Knows” applications; things that can become feeders into services that can then be sold. The same concept is being reviewed, I’m told, by Google and Apple, who would propose to use their handset data to feed it rather than Bluetooth.
Right now the Alcatel-Lucent concept is orthogonal to “networking” as we’d know it except that obviously sensors have to be connected. In the future, this kind of input could be used to help people make restaurant choices as well as to pick routes, and even change the bias of LBS by creating a traffic context into which to insert ads or suggestions (“Tired of waiting in traffic? Try our metro!”)
Cisco is also firing back at Juniper’s QFabric with a new module for Nexus and claims that they can support twice the data center connection density of QFabric. This is one of those “how-many-angels-can-dance-on-the-head-of-a-pin” arguments in my view; most enterprises won’t be able to justify a transition to a fabric, and those who do will not likely scale outside the capacity of either company’s products. The thing that neither Cisco nor Juniper has focused on is the context of a fabric deployment. What verticals are likely to deploy? What drivers create the opportunity, and what other things are needed to support the business cases? There are answers to these questions that neither player seems to care to get into. It’s easier to shadow-box than to be substantive, which is sad because only substance can sell.
OpenFlow is in fact a decent counterpoint to fabric data centers because it could be used to extend orderly-path behavior over an enterprise WAN, between data centers to create clouds, etc. Both OpenFlow/SDN and fabrics are likely to be embedded in application performance management or service-layer contexts. Either could be linked with the OTN moves that both Cisco and Juniper have already announced. So why atomize all this ecosystemic stuff? I despair of logic in this industry sometimes!