NEC released the market's first commercial OpenFlow 1.3 controller, enabling much greater scalability in its ProgrammableFlow SDN ecosystem. NEC execs said the release is another step toward OpenFlow SDN interoperability.
NEC demonstrated the new ProgrammableFlow version 5 controller and switches, along with applications from a group of partners at Interop NYC last week. New apps that work in the ProgrammableFlow ecosystem range from application delivery controllers to security, and most notably a Red Hat Linux OpenStack integration.
Previously we didn't have API capabilities for managing virtual routers. We can now manage Layer 3 networks for each tenant in the virtual networks.
director of business development, NEC
ProgrammableFlow includes a controller, switches and a management console that allows for visibility across a switching fabric, as well as virtual network provisioning without the need for software overlays. Until now, NEC has been running a 1.3 feature set, but has been "using vendor extensions to make that happen," said Don Clark, the company's director of business development.
NEC's goal is to make its controller and management console work with switches from any hardware vendor that supports OpenFlow 1.0 or 1.3. It released three hardware switches and a virtual switch for the Windows environment that are 1.3-capable.
This week, the Open Networking Foundation is expected to announce the first round of companies with products that have been conformance tested and certified for OpenFlow 1.0. Sources said NEC's switches are among that group.
Enabling OpenFlow 1.3 will provide richer functionality in the data center, as well as scalability and reliability, according to IDC Research Director Brad Casemore. NEC and other OpenFlow proponents hope that filling the technical gaps that existed in earlier versions of OpenFlow will lead to further customer demand -- and a pressure for vendors to produce OpenFlow 1.3-capable switches. This will lead to controllers that work across multi-vendor environments. But for now, not enough vendors are supplying OpenFlow switches, and those who have are working with disparate versions or implementing the protocol differently.
If vendors do jump on board with OpenFlow 1.3 switches, chip manufacturers will need to step up production -- and that could be a challenge, according to Casemore.
"On the merchant silicon side, there is a limited supply of the Trident II chipsets from Broadcom," Casemore said. "There's lots of functionality in Trident II that is useful in OpenFlow. NEC is OK for their supply of switches, so if you go with an all-NEC solution, you're OK. But if you go into a brownfield environment, things could get interesting."
How NEC's OpenFlow 1.3 fills technical gaps
Early adopters of OpenFlow have complained that it couldn't scale to large enterprise production environments. With OpenFlow 1.3, NEC can handle 200 switches per controller, as opposed to 100 in previous versions. ProgrammableFlow controllers can now manage up to 10,000 ports.
"One of the key scalability capabilities that the NEC controller now has is managing broadcast traffic. In the original OpenFlow model, all broadcast traffic went to the controller. That can be an intense amount of traffic that has to be transferred through the OS in the switch and up to the controller … [especially in an] environment running hundreds thousands of VMs [virtual machines]," Clark said.
In version 1.3, it's easier to identify which broadcast traffic must be sent to the controller -- and that can occur at line rate, Clark said. The traffic that doesn't have to pass through the controller can go straight to the data network.
Carrier-class reliability in SDN environments with OpenFlow 1.3?
Beyond scalability, NEC is aiming for the kind of availability in an SDN environment that carriers and cloud providers demand from traditional networks.
NEC's architecture clusters controllers for high-availability and failover. When there is a problem, there can be "cluster switch over at the millisecond level," Casemore said.
More on OpenFlow networking
A guide to understanding the OpenFlow protocol
Not all OpenFlow hardware is created equal
Video: Ethan Banks on OpenFlow implementation
Working toward OpenFlow conformance
Now NEC has brought its Ether Operations Administration and Management (OAM) capabilities --generally used in carrier networks -- into the ProgrammableFlow environment to ensure availability, Clark said.
"With Ether OAM, when we see that an optical link is down, it notifies the controller," Clark said. "NEC controllers will migrate the flow if the link is down."
Meanwhile, there are also new IP Multicast features on switches, which deliver a single stream of information simultaneously to multiple users in order to reduce network congestion, he explained.
Integration with OpenStack Grizzly; Layer 3 virtual tenants
NEC joined a host of other SDN vendors to provide an OpenStack Grizzly plug-in, which means users running an orchestrated cloud can provision networking along with storage and compute through the same portal, Clark said.
With ProgrammableFlow, NEC has always enabled users to spin up virtual tenants over the network with full visibility of each and without relying on overlay networks. With ProgrammableFlow v5, these features can be extended over Layer 3 networks, meaning virtual tenants can have distinct policy and can be extended across an entire WAN.
"Previously we didn't have API [application programming interface] capabilities for managing virtual routers. We can now manage Layer 3 networks for each tenant in the virtual networks," Clark said. "In the use case of a research cloud, for example, each researcher can get a subnet and provision VMs within their subnet, and it will have connectivity down to the host and up to the Internet or the rest of the WAN."
That overall functionality can also be integrated into the OpenStack framework so these virtual tenants can be provisioned in conjunction with compute and storage and in response to the needs of migrating VMs and other applications.