Despite the building momentum behind OpenDaylight’s open source SDN project, not everyone is behind it.
The Open Networking Lab (ON.Lab), a non-profit organization founded by SDN pioneers from Stanford University and UC Berkeley, this week launched its own open source SDN operating system as an alternative to the work coming from the vendor-driven OpenDaylight. ON.Lab’s Open Network Operating System (ONOS) is designed to enable agile service creation and deployment at scale on any hardware, including white boxes.
Vendor-driven efforts like OpenDaylight are intended to preserve the incumbency of brand name hardware, ON.Lab officials say.
+ MORE ON NETWORK WORLD: SDN company goes open source +
“All the noise around SDN is coming from vendors,” says Guru Parulkar, ON.Lab executive director, who adds that OpenDaylight is focused on automation of the command line interface used to configure legacy hardware and does not bring “SDN value” to service providers, such as lower operating expenditures, speeding service delivery and revenue, and offering white box hardware alternatives.
“Many carriers are amenable to something like ONOS because it gives them agility and flexibility and potentially freedom from hardware-based vendor lock-in,” says IDC analyst Brad Casemore. “They want to learn from how the major hyperscale players design and operate their infrastructure, but they also tend to require more help than the big hyperscale players need. ONOS potentially helps them with the move to white box hardware and to more of a DevOps model operationally.”
OpenDaylight has seen some recent momentum with two code releases, and heightened support from its own member companies. Brocade will ship this month an OpenDaylight-based SDN controller. And initial skeptics HP and Dell have raised their investment and participation in the effort.
Like OpenDaylight, ONOS delivers an SDN control plane featuring northbound and southbound APIs, and a range of management, control, and service applications. Initially targeted to service providers, the community’s goal is to extend the platform for cloud service providers, enterprises and mainstream deployments.
ONOS will be released and available for download Dec. 5. It was funded and developed by AT&T, NTT Communications, Ciena, Fujitsu, Huawei, Intel and NEC, with contributions from Infoblox, SRI, Internet2, CNIT and Create-Net.
ONOS is also supported by the Open Networking Foundation, a proponent of OpenFlow-based SDNs which has openly questioned the intent of the OpenDaylight project. OpenDaylight was founded by Cisco and IBM and is mostly populated with vendors, while ONF was founded by SDN users Google, Facebook, Yahoo, Verizon and Microsoft, among others.
As such, ONOS appears to be an ONF-endorsed alternative to OpenDaylight’s SDN framework.
“Right from the outset, there were tensions between OpenDaylight and ONF,” Casemore notes. “At least some major carriers, NTT and AT&T, are more comfortable with ON.Lab’s ONOS approach than with the model put forward by OpenDaylight.”
IDC analyst Brad Casemore
ONOS is essentially an SDN controller with northbound interfaces to application policy engines and orchestration systems, and southbound interfaces to networking devices themselves. OpenFlow and NETCONF are two of the multiple southbound protocols supported by ONOS.
The application policy framework in ONOS will be similar to the Group-based Policy Model adopted by OpenDaylight and conceived by Cisco, Parulkar says, but not identical. Indeed, the southbound policy protocol in ONOS will also be different from the OpFlex protocol conceived by Cisco which is expected to emerge in OpenDaylight’s upcoming “Lithium” release.
“OpFlex is not the right abstraction because it exposes the specifics of the devices to the applications,” Parulkar says, meaning it introduces less abstraction and more complexity than is required.
The ONOS Application Intent Framework will employ both imperative and declarative techniques to express and enforce intent, at the flow set up and application intent layers, respectively, Parulkar says. This is in contrast to Cisco’s Application Centric Infrastructure model with OpFlex, which is a fully declarative construct and upon which the OpenDaylight GBP is based.
AT&T has a highly visible SDN and Network Functions Virtualization (NFV) project underway called Domain 2.0. Many of the use cases for ONOS were conceived by AT&T, On.Lab officials say, adding they expect AT&T to adopt ONOS as a component of Domain 2.0
AT&T, which is investing $1 million per year for five years in ONOS, is optimistic but keeping its plans close to the vest.
“While it’s too soon to tell, ON.Lab is working on some impressive applications that we see complementing work done by other organizations, such as OpenDaylight,” AT&T said through a spokesperson. “Ultimately we’re really looking at anything that moves the industry forward, particularly in open source.”
OpenDaylight seems eager to dissect ONOS and participate in its development.
“We're excited to see what new technologies and approaches Stanford has come up with in ONOS that can be leveraged,” says Neela Jacques, OpenDaylight executive director. “The OpenDaylight developer community is always keen to see more code. We hope to see collaboration between the developers to bring new learnings and research into ODL so we can continue down the path of uniting the industry around an open, common codebase. We’re also very interested in seeing ONOS build mechanisms for people to participate, contribute and utilize their codebase.
“The goal of ODL remains to drive adoption of SDN by overcoming fragmentation in the industry,” Jacques says. “What we're seeing is people building a wide variety of products based on ODL that the industry can leverage. We'll see that trend continue in 2015.”
The use cases for ONOS include multi-layer optimization and traffic engineering over packet optical core; seamless peering of SDN islands with the Internet; SDN-based WAN control with segment routing; bandwidth calendaring; bandwidth and network provisioning; and a variety of configuration, management and control applications.
Another is Network Functions as a Service (NFaaS), which ON.Labs describes as a scalable, easy to deploy and manage NFV where the smallest unit of provisioning is a “service.” These services can be easily managed and scaled up or down, and combined together to create new services, ON.Lab says.
Examples of NFaaS include caching, deep packet inspection, load balancing and security applications.
ONOS will be available through the GitHub open source repository.