Transport SDN

Infinera Unveils Transport SDN Tools, Slams Rivals

Infinera has joined the swelling ranks of companies offering transport SDN capabilities by unveiling its own SDN controller and accompanying applications, saying these new developments are in response to customer demands and in line with the company's strategy to promote and provide open networking capabilities.

The controller and applications make up what the vendor is calling its Xceed Software Suite. The controller has been built using OpenDaylight open source code and designed as a transport network controller that will work with Infinera's optical portfolio, from its long-haul to metro to data center interconnect (DCI) systems. The controller includes the vendor's Open Transport Switch (OTS), a software abstraction layer (a form of middleware) that enables interaction between the controller and Infinera's boxes.

The applications are: Dynamic Bandwidth, to enable on-demand provisioning of transport capacity; and Instant Virtual Networks, which enables operators to "define virtual transport network topologies on a shared physical network infrastructure." (For full details, see Infinera Unveils Suite of SDN Tools.)

The development of a controller is not something Infinera Corp. (Nasdaq: INFN) had planned all along: its initial SDN strategy had been to enable its technology to work with any third-party controller selected by its customers. That approach hasn't changed, says Geoff Bennett, the vendor's director of solutions and technology, but customers have asked for an Infinera tool "as well as having the option of sourcing a third party controller. This is not about Infinera trying to force a controller on anyone. Our philosophy is to be as open as possible," he notes.

And any reason for building it on OpenDaylight ? "It was the best code for what we needed … it has the best open interfaces for developing new applications" and customers cited OpenDaylight as the preferred option, he says. The company also looked at options based on ONOS , which GEANT has been using in conjunction with Infinera's gear, and the SDN controller technology developed by Pacnet, now part of Telstra Corp. Ltd. (ASX: TLS; NZK: TLS), which is also being used to manage an Infinera network.

As for the applications, the first two have been developed in response to customer needs, but "service providers can also write applications themselves" as Infinera is making all the relevant code and API information available. "But if they don't want to do it themselves, or don't have the staff or in-house skills to do that, then they can use third-party developers," says Bennett.

The more open, the better
The move is notable for the vendor, according to Heavy Reading senior analyst Sterling Perrin. "This is important for Infinera as it marks the company's first official SDN controller. It has had the Open Transport Switch for some time, but the actual controller that made use of OTS had to come from someone else. Xceed gives Infinera its own controller, so that's a good step," says the analyst, who also thinks the company's overall strategy is a smart one.

"Infinera's commitment to openness is also a good move in the right direction, with an open source controller, open APIs and open information models. Operators want open -- the more open, the better," he adds.

And the Xceed launch has already met with approving noises from two existing Infinera customers, Windstream Communications Inc. (Nasdaq: WIN) and GÉANT , which are both putting the new SDN controller through its paces with a view to deployment. (See the press release for further details.)

But while this is important for the vendor and its customers, it will have limited impact on the broader world of virtualization, believes Perrin. "The reality is that SDN-based optical transport is not really a major focus for most operators -- not many are looking for optical wavelengths on demand, so that's a niche play. There is greater industry interest in integrating optical and IP layers, via SDN, but that's not what the controller is about at this time. If Infinera moves in that direction, it would open up greater opportunities for revenue, but it would also require IP expertise from them, or maybe from a vendor partner," adds the Heavy Reading man.

More open than…?
With "open" the basis of new bragging rights in the vendor community, Infinera is keen to claim how its approach leaves some of its main rivals in the shade, with Ciena Corp. (NYSE: CIEN), Coriant and Nokia Corp. (NYSE: NOK) in the firing line for some subjective comparisons (not independently verified).

In particular, Infinera claims that while its SDN controller is "based on OpenDaylight" and "leveraging the open source community," alternative transport network controllers, particularly Ciena's Multi-layer Control Platform (MCP), Nokia's Network Services Platform (NSP) and Coriant's Transcend, are "repackaged versions of their Network Management Systems which are based on an older style of proprietary software." Strong words…

In addition, Infinera claims its Instant Virtual Networks application is "unique in its ability to offer full end-customer control of their own Layer 1 OTN multi-node topology," while the Dynamic Bandwidth app is "superior" to those of its rivals "because of Xceed's multi-layer PCE capabilities."

Let's see if there's any kickback…

— Ray Le Maistre, Circle me on Google+ Follow me on TwitterVisit my LinkedIn profile, Editor-in-Chief, Light Reading

Iluzun 9/3/2016 | 3:43:59 PM
Re: Controller vs. EMS/NMS http://www.utroqueconsulting.com/ "A controller is distinct from a standard Network Management System (NMS) in several ways, many of which are subtle – which has allowed multiple vendors to simply re-brand the NMS as a controller without implementing any significant changes. The biggest difference, one that is not covered by most NMSs, is that a controller must be open to multiple vendors. While some network vendors in the past have claimed an open NMS, the reality has been less than optimal. A truly open controller should be able to quickly and easily integrate systems from mulitple vendors without significant loss of functijonality. Standards like YANG data models should go a long way towards meeting this goal, but it will be the business issues that will determine the long term viability"
jefftant 9/2/2016 | 6:58:46 PM
Re: Controller vs. EMS/NMS Architecturaly - a  NMS should be NB of a controller, and this is where users explress their intent (AKA business logic), controller would be the glue/compiler/your favorite term to instantiate networking based on the intent expressed. SBI's used don't really define the name, ability to use many different SBI's wihout need to change user's intent shows proper implementation.

Hope this helps,

Sterling Perrin 9/2/2016 | 10:54:52 AM
Controller vs. EMS/NMS <repackaged versions of their Network Management Systems which are based on an older style of proprietary software>

This is an interesting comment and seems to be the main argument that that many vendors are using against their competitors.

Ciena itself used this same argument in a recent interview to attack their competitors (not against Infinera though, as they hadn't announced product yet.)

In my research I am trying to define what exactly separates an SDN controller from a next gen NMS platform. So far I haven't gotten a clear distinction. SW that only supports new interfaces is a clear controller. Something that is 100% proprietary and only handles legacy CLI, SNMP is NMS. But what about SW that has new and legacy interface support? I've seen demonstrations of SW that automates legacy CLI, for example. I welcome any thoughts on this topic - there is a lot of confusion right now.

Sign In