In this companion piece to his exploration of adoption hurdles for network virtualization in carrier and service provider networks, Kevin Fogarty considers some of the SDN solutions now on offer to help this segment modernize network environments. Specifically, he examines “ONOS,” a new open source SDN operating system designed for the carrier/service provider by ON.Lab and released this past December. If this approach appears to be out of scope for the enterprise, read on. Fogarty argues effectively that ONOS for the carrier is soon to be ONOS for the enterprise – and strong competitor to SDN targeted at smaller networks and supported by several of the commercial IT vendors. But even more importantly, he argues, ONOS is shipped with a Northbound API that provides management, HR, performance management, security or other applications with access to the SDN controls, and hence new levels of service and flexibility to the end user customer. Will this be enough to drive past the adoption hurdles Fogarty outlined in his original article, or will the confusion of standards and proprietary technologies that is exacerbated by the introduction of yet one more carrier SDN solution perpetuate “SDN Hesitation”? (ed.)
The “SDN Open Network Operation System” (ONOS) released earlier this month is intended to increase the number of end-user organizations using SDN, but is focused almost entirely on carriers and WAN providers.
The controller, which was announced Nov. 4 and released as an open-source product Dec. 5, was developed by the Open Networking Lab (ON.Lab), a non-profit launched by researchers from Stanford, Princeton and UC Berkeley who helped create the idea for SDN, with backing and support from vendors including AT&T, NTT Communications, Ciena, Huawei, Intel, NEC and others.
ONOS is designed specifically for carrier networks, and its goal is to expand their ability to offer relatively standardized SDN services instead of or in addition to the proprietary services they currently offer. (A PowerPoint presentation from an ON.Labs webinar, with more technical details is available here.)
SDN is designed to enable network administrators to create a conceptual network layout that connects users applications and servers to the groups or resources they need to use, and allows the creation of new network segments, access rights or controls as well as the addition of resources such as an external cloud or storage application without having to change the physical layout of the network to match what administrators would like it to do.
The key to making it work is the SDN controller, which sits on the network near key routers and switches, reading network traffic and telling the network how to get traffic from Workgroup A to Printer A even if there is no direct physical connection and the traffic actually has to detour through several other network segments or access points to get where it’s going.
Though its primary function is to drive the controllers that sit on top of an existing network, the scope of ONOS’ design goals are far wider. It is designed to support both generic white-box networking or computing hardware and existing brand-name hardware.
It is also, according to technical explanations ON.Labs posted following its announcement, designed to expand easily and maintain high network speeds at the vast scale and multi-layered complexity of carrier networks that may have hundreds of high-performance routers on the WAN backbone, tens of thousands of routers and millions of ports on metro networks as well as thousands more devices, many frequently mobile, on cellular access and wired-access cable networks.
It is that very complexity, compounded by the unremovable presence of several generations of legacy systems, that is creating barriers to carriers’ SDN adoption.
Those challenges, along with a sneaking suspicion that SDN might be replaced by some other technology before carriers can earn back they money they spend on upgrades needed to run standard x86-based networking services across the WAN, are a big part of the reason carriers have dragged their feet on the upgrade and are currently going through what analyst firm Infonetics Corp. calls “SDN Hesitation.”
Introducing yet another set of technology choices
“The ONOS project partnership was formed from a unique blend of service providers, vendors and ON.Lab to accelerate the adoption of SDN by providers,” according to statements from Bill Snow, VP, engineering at ON.Lab. “The first release of ONOS is the start of the journey towards service provider network transformation,” he added.
SDN controllers are designed to apply complex rules to network traffic, to monitor and filter packets, and apply often complex sets of dependent variables to every device on the network.
SDNs are most common within data centres, where the volume of traffic and the potential benefit from minor increases in efficiency are both high, but the number of destinations and networking devices to be controlled is low.
Facebook, for example, uses SDN as a performance accelerator within its Altoona, Iowa data centre, where it broke server clusters into smaller segments than it had previously and load-balanced the flow of requests from its main web app across thousands of densely interconnected clusters of servers.
Some companies have expanded SDNs to address proprietary WAN connections – dedicated long-distance telecom links that connect one facility to another – but most of those companies use the SDN to control only the single connection between each pair of facilities rather than expand to include all the myriad network segments within each location.
The cost justification for SDN is particularly strong in companies that want to build close connections between the enterprise and public cloud services, according to an August report from IDC. That report details IDC’s prediction that the enterprise/WAN/cloud segment of the SDN market will grow from $960 million to more than $8 billion by 2018 – or at a compound annual growth rate of 89.4 percent, a CAGR that includes not only SDN hardware and software, but security, SDN-management and consulting and design services.
Much of the SDN gear in service right now is proprietary, often custom-developed, and not widely interoperable.
ONOS is pretty late to a market that’s already dense with competitive offerings; however, most of these are proprietary or have little ability to scale, according to an exhaustive rundown of the options at SDNCentral.
ONOS isn’t even the only popular open-source controller. OpenFlow, the protocol on which the most of SDN has been based until now and which is managed by the Open Networking Foundation, is a communications interface that manages the negotiations between the control and forwarding layers of the network. A new version called Project Floodlight is designed to automate much of the process of building an SDN with OpenFlow.
The real competition is OpenDaylight, which is tended by the OpenDaylightProject – a support and development program supported by Juniper, Brocade, Cisco, NEC and a long list of others.
Its negative reputation is based on the notion that OpenDaylight is a tool of established networking vendors who feel threatened by the growth of and enthusiasm for SDN and are moving at a conspicuously slow pace towards the goal of having OpenDaylight serve as an integration point for the management tools of many other vendors.
But it has been evolving slowly toward the point that it might become a legitimate central integration point for the APIs of SDN tools from other vendors.
Throwing ONOS into the mix just as OpenDayLight is starting to make forward progress could start a standards war, rather than just a competition.
Because it supports both legacy and new hardware, ONOS could have a major advantage over OpenDayLight, for both carriers and end users, ON.Lab strategi advisor Ram Appalaraju told eWEEK at the time of the announcement.
However, if legacy hardware is a big deal for carriers, it is much less so for end users, Mike Fratto of Current Analysis told eWEEK for the same article. Google and Facebook might buy a lot of white-box networking equipment, but most enterprises don’t, Fratto said, shrinking ONOS’ appeal on the grounds of cost and ease of migration.
ON.Lab is focusing ONOS on carriers during the first phase of its product rollout primarily because getting their SDN services up to speed will build the road along which end-user organizations will travel – and having a core that can be distributed across several primary controllers will enable ONOS to fulfil that role by improving performance even, on large installations.
For technology managers interested as much in what interesting new things they could do with SDN – in addition to the OpEx and CapEx savings likely to come from better control over the network – the key characteristic for comparison of ONOS and OpenDayLight isn’t scalability or vendor support or even performance.
ONOS shipped with a Northbound API – a programming interface designed to give management, HR, performance management, security or other applications access to the SDN controls. That would allow the IT security department, for example to reconfigure a network under DDOS attack, or re-route a persistent-threat attacker to a honeypot rather than a key production server.
OpenDayLight supports a range of Northbound APIs from other networking products, rather than one of its own, allowing a range of ways to determine the intent of the flow of traffic and decide what to do about it, which is likely to make it more flexible, at least in the near term, than OpenDayLight APIs largely taken from other sources.
That still won’t get carriers to roll out SDN networks quickly for customers that want them, or make SDN an easy choice in product or service for enterprises. In the meantime, customers may face a choice of options that are too proprietary, and too rigid to do what they want, or options that are open and flexible, but have not yet appeared in any of the wide-area networks customers want to virtualize.
