The promise of bringing software-defined networking (SDN) to optical networks was a big topic at OFC this week, but you didn't have to dive down far to see how difficult that task is going to be.

Lyndon Ong, chair of the ONF's Optical Transport working group, explained some of the difficulty in a talk at OFC on Wednesday.

One issue is that the optical network has analog concerns that packet networks don't — the transmission power of a laser, for instance. But maybe more importantly, optical networking is mostly a service-provider concern. Optical's incursion into SDN is helping emphasize how different carrier networks are from the data centers and the small networks where OpenFlow got its start

Covering SDN at OFC felt a little like trespassing. The letters stand for "optical fiber communications," and the conference — which I've attended for 12 straight years, maybe more — attracts Ph.Ds worldwide to discuss the physics and chemistry of lasers, amplifiers, and, yes, the optical fiber itself. Software has never been a headliner.

About a decade ago, OFC broadened to include network-level issues as well. It took a few years to really take hold, but the component-dominated exhibit floor has seen more of the systems vendors in recent years, and they're the ones who brought SDN into OFC. The laser vendors mentioned it, too, but don't worry. The only software-defined laser I heard about was a joke. I think.

The OpenFlow 1.4 specification, published in October, is the first version to include extensions for optical networking. (Rather than link directly to the 205-page PDF, we'll refer you to this ONF page.)

They include a way to declare (or detect) that a port is optical — an important first step, because OpenFlow previously dealt only with Ethernet ports.

OpenFlow 1.4 also lets the controller know the power being transmitted and received at an optical port, a concern that just doesn't exist in Ethernet.

Beyond that point, though, OpenFlow needs to adapt to the carrier environment. For example, the idea of one controller that talks to all the network elements is too simple. A service provider network more likely needs a hierarchy, Ong said. Individual controllers could span different domains of the optical network, with a controller-of-controllers sitting northbound of all that.

Physical distances also matter in the service-provider network, as a faraway controller can cause latency problems. For monitoring and protection, for instance, round-trip time to the controller might be too long, even at the speed of light. You'd want the controller to be able to view and manage an abstraction so it could take action more quickly, Ong said.

The Optical Transport group will publish its first recommendations this quarter, including things like auto-discovery for optical elements; further definitions for optical ports and optical connection attributes in OpenFlow; and monitoring, protection, and control.

The ONF is also doing joint prototyping with the Optical Internetworking Forum (OIF), a group that standardizes some of the specifics of carrier optical networking. They'll be prototyping and testing the OpenFlow optical extensions and hope to show some results in the fall, Ong said.

Some of the OpenFlow 1.4 technology is emerging in a reference system designed by Vello Systems. It's part of the Open Source Optics (OSO) initiative that Vello announced this week. (Vello says it contributed the optical extensions to OpenFlow 1.4, so it got a jump on things.)

OSO's goal is to simplify optical networking enough for the enterprise. Optical networks aren't like packet networks; tiny analog-signal details matter, and the software doesn't match what you see in packet networks. There's no optical auto-discovery, for instance. In a packet network, a switch learns about its neighbors on its own. No such thing happens with the optical network.

Like so many other open-source networking projects, OSO wants to abstract all that detail.

"OSO makes it as easy as configuring a 48-port white box Ethernet switch. It's an OpenFlow configuration; it's integrated with the Ethernet side," says Jeff Paine, Vello's vice president of marketing.

To make optical feel even more at home for enterprises, Vello used OSO as the basis for a reference platform, an optical pizza box for the enterprise.

The box's development borrowed from Vello's history as a packet-optical equipment vendor. But Vello, which rebooted as a pure software play in 2009, has no plans to sell the pizza box itself.

At least one vendor has been working on it since mid-2013, though. A system with 12 10-Gb/s ports could come available in 90 to 120 days, and a 100-Gb/s version might arrive by the end of the year, Paine says.

That the box is one rack unit tall is an accomplishment. Vello re-engineered items such as optical ROADM cards, integrating them together into smaller and more power-frugal forms. (ROADMs are optical amplifiers that allow for flexible assigning of wavelengths on the network.)

The vendors involved with OSO are mostly small players: Accelink, CoAdna, CrossFiber, O-net, Packetlight, Vello, and, from the customer side, Pacnet. The lineup is a product of the press-release deadline, which left some companies still considering their involvement, Paine says. (Another theory, noted by Network World, is that Vello intentionally kept big optical vendors out. That would mirror the strategy forged by the CloudNFV open-source project.)

Photo: The OFC exhibit floor, where you can spot OSO member CoAdna.