The Open Networking Lab (On.Lab) is ready to release its Open Network Operating System (ONOS) as open source code, offering an alternative to the controller and ecosystem being developed by the OpenDaylight Project.
ONOS first came to SDNCentral’s attention in December 2013, described by sources as an OpenDaylight alternative that On.Lab — a non-profit based in Menlo Park, Calif. — was scrambling to collect sponsors for.
And sponsors did come around. In 2013, AT&T and Intel committed to contribute $5 million apiece during the span of five years. Several other sponsors have signed on for a smaller, undisclosed amount. (SDNCentral’s Matt Palmer heard it was $500,000.) They include Ciena, Ericsson, Fujitsu, Huawei, the National Science Foundation (NSF), NEC, and NTT Communications.
The question all along has been how “open” ONOS would be. Every initiative related to software-defined networking (SDN) calls itself “open,” but some end up more open than others. ONOS has taken an important first step by at least taking the code open source.
A crucial second step would be to make the code actually available. That’s not due to happen until Dec. 5, with a small ONOS Summit to convene in Menlo Park on Dec. 9. On.Lab has no intention of offering a commercial version of ONOS, but that’s something that vendors would be welcome to do, says Guru Parulkar, On.Lab’s executive director.
ONOS for Service Providers
On.Lab is a research organization founded to produce software defined networking (SDN) tools for the benefit of the general industry. It shares offices with the Open Networking Foundation and the Open Networking Summit but is a separately funded entity. (But there is a common thread: Nick McKeown of Stanford University helped found all three.)
ONOS is an SDN operating system for service providers’ networks, meant to handle deployment of services at large scale. Satisfying the core SDN tenet of separating the control and data planes, ONOS is a distributed control plane for the network, meant to run on multiple servers while behaving as one system.
It’s the “distributed” part that’s hard to do; the fact that On.Lab tackled it first is one key factor setting ONOS apart from OpenDaylight, says Prajakta Joshi, On.Lab’s product director.
More revolutionary is the idea that ONOS could be a first step toward a white box infrastructure, where carriers would buy nearly generic hardware and implement ONOS on top of it. On.Lab is convinced white boxes are the future for carriers, but the change can’t happen overnight. So, ONOS is built to run on today’s networks and provide a migration path toward white boxes, Parulkar says.
ONOS also includes requisite carrier-grade features such as high availability (the ability to move work to a new machine if one fails) and hitless recovery of network state in the event of a failure.
For now, ONOS uses OpenFlow as the southbound interface to discover the network; keep track of network state; and program and configure network devices. Other options such as Netconf will likely be added over time, Parulkar says, but ONOS is an OpenFlow beast for the moment.
Northbound, ONOS points to On.Lab’s Application Intent Framework. It’s a policy-driven abstraction, where application developers can explain what they want from the network, leaving ONOS to translate it into network configurations (and to make sure the new commands don’t cause any conflicts in the network). It’s a declarative model, like the one being pursued by the Group Based Policy project in OpenStack or by Cisco with its Application-Centric Infrastructure (ACI).