TI, Stanford explore OpenFlow silicon

SAN JOSE – Researchers from Stanford University, Texas Instruments and at least one other company are exploring ways to optimize networking chips for the emerging OpenFlow specification. The effort is part of a wider trend toward software-defined networking shaking up the communications industry.

Software-defined networks (SDNs) aim to cut through the complexities of a growing variety of protocols and techniques often coded into silicon that make today’s nets difficult to manage. SDNs also aim to bring the same kind of virtualization capabilities to networks that are now widely used in computers.

The OpenFlow specification developed at Stanford is leading the charge, gaining support in products from Hewlett-Packard, IBM, NEC and and a handful of startups. But some say it is just one approach to creating a software defined network.

The trend could be disruptive for established companies such as Cisco Systems that have deep investments in systems and chips geared to handle today’s protocols.

In an effort to get ahead of the curve, Cisco recently announced a broad initiative called Open Network Environment that it says goes beyond OpenFlow. Meanwhile the company also is developing systems for OpenFlow as part of an internal startup called Insieme, according to a New York Times report.

“In short, Cisco is planning on offering multiple approaches to program networks across its portfolio,” said Nick Lippis, a network analyst, writing for a GigaOM Pro report.

Meanwhile at Stanford, TI and others are collaborating on “a paper design of an OpenFlow optimized switch fabric,” said Martin Izzard, director of systems and applications research at TI.

The project, expected to run through the end of the year, aims to define in silicon “a classification pipeline variable in length and able to look at different kinds of labels or tags,” said Izzard.

The packet lookup and classification techniques in an OpenFlow switch are expected to be relatively generic so they can be flexibly configured as needed by network managers. Indeed, engineers are hammering out a high-level applications programming interface for routers and switches as the next big step in the evolution of the OpenFlow specification.

The goal of OpenFlow is to let end users program network systems using servers as controllers. However, the switches and routers will still require some embedded processing to interpret the APIs and carry out their jobs.

“My gut feel is the [OpenFlow] machines will be more efficient than ones that have to serve a large number of protocols,” said Izzard. “These boxes could be software configured for different protocols and topologies so they could be less power hungry,” he said.

“This is an inflection point in how networks are developed, and that means there’s a chance for markets to change,” Izzard said. “My timeline is this year to understand this market well and see which way it’s going,” he added.

“In data centers there’s a clear case for OpenFlow, but how quickly it moves into the WAN is a big discussion,” he said. “It’s not completely clear if it will move into public networks, but I expect this year it will become clear,” he added.

Huge progress has been made at University of Stanford, OpenFlow, and its community since its inception few years ago. It is about time to implement OpenFlow FPGA, ASIC, and SoC at wider scale, starting with servers, storage, and networking in data center, LAN and enteprise networks. Implement OpenFlow in WAN will take time and can be develope in parallel. We must take a bold steps and working hard for future.

"The goal of OpenFlow is to let end users program network systems using servers as controllers. However, the switches and routers will still require some embedded processing to interpret the APIs and carry out their jobs."
Does that mean they want to move the processing power to the servers. I would expect finding ways to eliminate than transfer processing power to be the driver of innovation.
Can someone explain the cost benefits here?

Hi goafrit,
You are basically dumbing down the forwarding boxes (read Switches,routers and middle boxes)by retaining only the well-defined data plane and moving the control to a logically centralised controller.
The cost benefits are tremendous if you look at the way forwarding boxes get highly commoditized by using merchant silicon and the control plane benefiting from cheap and increasingly powerful x86 servers.
There are additional benefits by way of much simpler network management as SDN spells the end of complex proprietary and open standards protocols!