ECI says it is working on extending OpenFlow with autonomous behaviors to help software defined networking (SDN) live up to its potential. ECI, known for packet-optical transport, has been a telecom equipment provider since the 1960s, but the company is shifting away from hardware toward a software focus and is using SDN tactics to get there.

According to ECI, it’s a naïve view to have a single controller control large-scale networks in a reactive mode. Such a global view doesn’t scale, ECI claims. It means the first frame of each new flow is sent to the controller, where an SDN app decides on the desired behavior, derives the required network configurations and then uses the SDN controller to configure all the relevant switches.

ECI has come up with a different approach.

“The controller would be able to send not only configurations but also behaviors to OpenFlow switches, with behaviors essentially being small SDN applications coded as state machines,” says ECI’s CTO Hayim Porat. “By sending behaviors to the switches, the global view and programmatic approach of SDN is maintained while greatly enhancing its scale by distributing the desired behaviors to the switches.”

The extensions are very short code. “The idea is to not have very long pieces of code,” Porat says.

ECI will provide its code, which is still being written, to the Open Network Operating Systems (ONOS) community.

ECI is also working to advance network functions virtualization (NFV).

“The initial approach to NFV was that all of the virtual network functions (VNFs) would run at the provider’s data center,” says Porat. “This approach, while good for over-the-tops [OTTs], is not that viable for telecom providers, as VNFs are very input/output intensive in comparison to OTT services such as video streaming.”

Considering that even simple applications such as virtual customer premises equipment (vCPE) would require every DHCP request to travel from the customer’s premises all the way across the service provider’s network to the data center, and then all the way back, this is not scalable, says Porat.

ECI has come up with another approach it’s calling “Transport NFV,” wherein the NFV cloud infrastructure is deployed in carrier networks at spots determined by such factors as latency or the cost of energy per task. ECI is developing a growing number of hyperconverged edge cloud cards (or standalone appliances) that enable a carrier to have flexibility in creating its own cloud infrastructure while maintaining control.

The first release of Transport NFV is available on ECI’s Neptune platform.