Equipment makers should delve into OpenFlow and software-defined networking (SDN) aggressively, so that the eventual standards can be as robust as possible, Verizon Communications Inc. executive Stuart Elby said earlier this week.

That message, as well as an insistence that Verizon doesn't want pure OpenFlow switches any time soon, was part of Elby's keynote talk at the Advaced/MicroTCA Summit.

Elby, in casual dress appropriate for an engineering-heavy conference, spoke on Tuesday and spent generous time hanging out with vendors at the show. He's also been speaking at events such as the symposium put on by the ONF, the group shepherding the OpenFlow specification.

It's all part of Verizon's eager dive into SDN, where the carrier senses the potential to use the network more efficiently (i.e., save money).

Verizon is already using SDN-based traffic engineering in its mobile network. If congestion is preventing a stream from being received at its maximum rate, Verizon dials down that rate to avoid wasting bandwidth.

The process is run by lots of servers overlaying parts of the mobile network, and it's inefficient, with traffic doing "a lot of hairpinning in and out of routers," Elby said. Verizon is working on using OpenFlow or some similar protocol to carve more direct paths through the network.

Verizon also thinks OpenFlow could help with troubleshooting the network. The network is watched by probes everywhere, but it's not feasible to sort through all the data they could gather. ("I'd look like a government agency," Elby said.)

Verizon would rather trigger data collection from certain probes any time something starts going wrong. It would be an ad-hoc data-collection network. That's another project that's in Verizon's labs.

This kind of work-in-progress is essential to making SDN useful, Elby said. OpenFlow "is going to change, but we've got to get experience as to where the pitfalls are."

And it's true that as OpenFlow has dominated conversations for the past year or more, more of its pitfalls have come under study and are now being worked on. Scalability is one; it's still difficult to see OpenFlow being expanded to Internet routing.

The fact that controllers are logically centralized -- you can have more than one, but they're expected to work in concert -- is another, noted David Meyer, an engineer at Cisco Systems Inc. and one of the speakers at the conference's OpenFlow seminar.

There's also an issue with memory chips. OpenFlow was written to take advantage of chips already in switches and routers -- namely, ternary content-addressable memories (TCAMs). But the TCAM is the "hottest, most expensive, least efficient part of the forwarding plane," as Meyer put it.

Vendors are already working around that. IBM Corp.'s OpenFlow implementation allows some switching rules to get stored in more ordinary memory chips, IBM presenter Rakesh Saha said.

Due to these practical realities, most vendors contend OpenFlow will have to be implemented in hybrid switches -- those that can do OpenFlow but also retain normal Layer 2 forwarding. An implementation like that "allows me to phase in -- carefully, methodically -- OpenFlow/SDN technology without causing the network to crash," Elby said.

— Craig Matsumoto, Managing Editor, Light Reading