We asked Lumina Networks’ CEO Andrew Coward, how companies can make best use of open source. “Open source is not a spectator sport,” says Andrew. “Sitting around and waiting for somebody to show up and deliver the equivalent of your existing vendor’s offering is not the right approach. So we work best when our customers are very engaged. And really, it’s all about how you automate things.”
“It’s only been nine months, but what’s next from Lumina?” asked Guy.
“Productization. Up to recently we’ve been about individual customers and bringing them on this journey. So we’re now taking the best bits we’ve done and productizing them so they can be more easily adopted by mainstream, not just carriers, but large enterprises.”
Network functions virtualization is on the rise, but not in the way that many thought. TelecomTV sat down with several industry leaders to discuss the future of NFV and SDN, and the role it will play in business technology and transformation in the years to come.
Lumina doesn’t believe in selling turnkey solutions, but also doesn’t believe in leaving the introduction and integration of its products to the CSP. We believe that we can serve as the catalyst for a company’s digital transformation initiatives, helping out on the heavy lifting while teaching our customers how to manage their network from the core to the edge and think outside the (hardware) box. By working closing with a CSP’s internal NetDev team to give them the tools they need to succeed, we set them up to win the long-term process of transformation without sacrificing short-term gains.
“[We] soon came to realize that our market could be divided into early adopters and laggards. CSPs’ likely willingness (or not) to engage properly in this way could be gauged by how diligently they approached things like a [request for proposal],” he says. “We found this created a self-selection process for us because the ones that asked the right questions were more receptive to us and more willing to “play catch” with some of the open source projects.”
However some went the other way, saying “We don’t need any help, we’re going to do everything ourselves and manage everything. But inevitably some of those customers found it was a Herculean task to do all the integration, manage the new open source code, compile it, keep it reliable and keep up with the changes.”
So some of those companies that had originally struck out on their own subsequently had a change of strategy and came back saying, “You know what, it doesn’t make sense for us to manage the relationship with open source or adding new features when you guys can do that.”
That turned out to be a viable business model for Lumina. “On one level we help with the integration, but what we really do is provide abstraction,” claims Andrew. “With SDN we’re trying to separate the business logic of the carrier – which defines the services – from the underlying hardware and from the vendors […].
“The great thing is that everything that gets built gets put back into the community and makes the job much easier the next time around.”
The abstraction layer also hopefully avoids the CSP customer accruing what’s known as ‘technical debt’. That occurs when devices are integrated directly or tactically (without an abstraction layer) creating a debt that will have to be paid back with interest in integration difficulties later.
“Five years ago we didn’t comprehend the need for CSP culture change to enable transformation,” says Andrew. “But things have changed greatly with SDNFV over the past four years especially. The industry has had to move from a science project through to ‘available in the lab’ and then to something that could be deployable. In the great scheme of things I think we’ve moved remarkably quickly on the open source side of things to make that happen.”
Most importantly it’s turned out that the industry wasn’t – as it perhaps at first thought – introducing a new technical framework and, ‘Oh by the way, you might have to change how you do things a little’. It now looks as though we’re introducing new ways of engaging with customers software, services and suppliers with some necessary and useful technology coming along for the ride. Culture change in other words, has become the prize, not the price.
There’s no doubt the process has been slower than thought. Why?
Andrew thinks “a lot of stuff got stuck in the labs and there was a feeling that everything had to be new.” In too many cases that appeared to mean white boxes needed to replace legacy hardware and there was a feeling that “before we can adopt this technology we need to put data centres in,” Andrew maintains.
“Actually, on the SDN side it’s predominantly all about the existing equipment. So not about replacing, but making the ‘physical’ equipment work with the new virtual environment,” he says.
Another reason software might stay in the lab might be a pervasive fear of ‘failure’ on the part of many CSPs, somewhat at odds with the IT “fail fast” credo. Allied to this can be a reluctance to upgrade the network – in sharp contrast to the constant upgrading undertaken by the hyperscale players many carriers would like to emulate.
Overcoming the upgrade phobia would help the new software ‘escape the lab’ on a more timely basis says Andrew.
“We’re looking for customers who have captured this technology and understand what it is they want to do. Typically they have stuff in the labs and they now want to get it out and they need a partner to help them do that. They don’t want to hand the task off to an outsourcing company because they’ll lose the learnings that they have and they won’t be in control of the outcomes. So they want to keep doing it but they know they need some expertise to help them with that process.”
Lumina Networks is proud to be a partner for the Linux Foundation. We will be exhibiting our industry-leading SD Controller at the Open Networking Summit next week in Los Angeles, and look forward to meeting with attendees to help them learn how to get the most out of the network and start on the path toward full digital transformation and business digitization.
This week, we were proud to partner with NoviFlow at Mobile World Congress to demo the world’s first SD-Core networking solution in a use case that involved the siphoning of select classes of traffic to the newer, higher performance network.
What is SD-Core? SD-Core defines an architecture and technology set for deploying scalable, MPLS/Segment routing capabilities so that network providers can offer newer and more affordable services to subscribers with carrier-class reliability. The SD-Core approach uses a layered software-based architecture with adaptable components based on open source rather than vendor-proprietary system. The use cases are numerous as SD-Core enables network providers to elevate their core networks to SDN while retaining protocols, products and reliability of their existing networks. They’re also able to reduce costs by enabling traffic sharing between the switched and routed domains.
Both Lumina and NoviFlow were honored to share this groundbreaking technology with Mobile World Congress attendees!
“We believe in bringing open software networking out of the lab an into the live network, solving real problems for real customers,” said Andrew Coward, CEO of Lumina Networks. “It’s rare that a new solution is simultaneously lower cost, higher-performance and ready for production, so working with NoviFlow to evolve the core of our MPLS customers’ networks is a real demonstration of the power of SDN used with white box technology. We’re delighted to showcase this solution at Mobile World Congress.”
“The dynamic partnership provides a compelling new end-to-end solution for MPLS and Segment Routing,” said Dominique Jodoin, President and CEO of NoviFlow. “NoviFlow is honored to join forces with a key player such as Lumina Networks to offer unprecedented feature/ performance in commercial SDN solutions.”
There’s a lot of talk today among the world’s leading ISPs about the need to transform their network to keep their business viable, and to keep it from totally commoditizing. Network transformation requires being able to bring new and innovative services to market quickly and ahead of the competition. That, in turn, depends on having a flexible network that not only supports but enables new services that couldn’t reasonably be done with a legacy network alone.
This is why there’s very high interest in software-defined networking (SDN) among carriers and ISPs. They all want to be able to deliver more lucrative services, more quickly, and in a cost-effective manner—and SDN can make this possible.
As exciting as the prospect of a software-defined network is to carriers and ISPs, they can’t just rip and replace the existing legacy network they are heavily invested in. They can’t simply build a new service provider network from scratch and, on day one, be full SDN. They need a strategy to get from legacy proprietary networking infrastructure to SDN without disruption of service to customers, and with an affordable investment plan.
A Bridge to the Future
This is the problem that Lumina Networks solves with our SD-Control solution. We offer a practical strategy to bridge that gap to gracefully go from legacy to software-defined network, at a pace determined by the carrier or ISP.
When we first looked at this problem, we realized that the standard components of SDN work well in the lab, but maybe not so much in the real world where carrier and ISP networks need to scale to global levels. We really wanted to put our motto – “Out of the Lab, Into the Network” – to work on this issue.
Lumina SD-Control is an SDN design philosophy to build networks that are capable of global scaling. We’ve taken common building blocks that people might not associate with SDN – some of those building blocks are protocols, others are barely more than a concept – and put them together in conjunction with common SDN network technologies to solve the scalability problem.
For example, our SD-Control solution builds on the solutions of large MPLS networks, while reducing costs and enabling modern SDN and NFV architectures. This is not merely theoretical, and not bound to the lab, but in actual operation today for very large ISP customers.
Let’s have a look at how we build SD-Control.
The Lumina SDN Controller
The first building block of SD-Control is the Lumina SDN Controller, or LSC. It’s based on OpenDaylight (ODL), which gives us some capabilities that other SDN controllers don’t have. We chose ODL as the basis for our controller because of its mature OpenFlow implementation and support for legacy network protocols like BGP. In addition, it’s a stable and fully capable NETCONF server and a NETCONF client. NETCONF and BGP are important when legacy network, non-OpenFlow components, are requirements. The ability to manage configuration using the NETCONF protocol, in addition to being able to command the OpenFlow network, is an important distinction between LSC and other OpenFlow controllers. We at Lumina like the possibilities this opens up for us and our customers.
LSC can speak BGP and, more specifically, Multi-Protocol (MP) BGP – essentially the protocol that makes the Internet work today – gives LSC its universal translator role in the SD-Control solution. It’s a simple conclusion to bridge the gap between legacy networking and the software-defined networks by having a network controller that can control both the old network and the new network. MP-BGP is important to control of the legacy network.
The practical path forward is that the services that are delivered on the old network can be translated into equivalent functions or equivalent instructions to the SDN network. With LSC it’s possible to define, build and manage network services that traverse the legacy network and terminate on the SDN network, interworking between the old and the new. This provides the ability to move customers and data from the old network onto the new network in pretty much a seamless fashion and driven by business perspective. That’s the power of the Lumina SDN Controller, and the practical sense of Lumina SD-Control to create the bridge from legacy networking to SDN.
Another critical component of SD-Control is segment routing. This is what creates the ultimate scalability in the SDN. Though the concept of segment routing has been kicked around for a while, the technology itself is still cutting-edge. The big networking players, the Junipers and the Ciscos of the world, are still developing their technologies in this space. We just don’t hear a lot about practical implementations of segment routing.
Once again, this is something that Lumina Networks is taking out of the lab and putting into the network. Segment routing is a twist on MPLS labels in a non-traditional way. Basically, segment routing removes any kind of requirement for signaling state in the network, and it also decouples the network-paths in the network from the per-flow forwarding entries on the intermediate nodes creating aggregate flows in the core. We can already do this in a programmable SDN network, and we have demonstrated that it works on a large scale. Segment routing solves the scalability issues inherent in OpenFlow in core networks, allowing SDN based services to be implemented at global scale.
Path Computation Element Protocol (PCEP)
PCEP is a protocol that we have borrowed from the traditional IP/MPLS network world. It gives us a way to offload the traffic engineering computations from the network data-plane in a given network to an out-of-band engine. This engine runs the algorithms and analyzes how resources are used as data moves through the network in order to best organize MPLS paths based on specific business requirements. Once the optimal paths are decided, the Path Computation Element Protocol is used to give the forwarding solution details to the SDN control-plane, which in turn programs the network data-plane elements that actually move the data packets. This can be Multi-Protocol BGP for the legacy network, OpenFlow for the new network or some combination of both.
This notion of how to do this – the algorithms, the set of problems inside the PCE – is not new, but we’ve appropriated that technology to an SDN network design and built a new paradigm to solve an SDN problem. Using PCEP in this way is something new, and it’s something that SD-Control and our solution bring to the table.
The Sum of the Parts
So, to connect the dots here, we have a network controller that’s responsible for programming the forwarding on the commodity data-plane components—the white box switches. The network controller can converse with the legacy network using MP-BGP. Services are abstracted as data-models in the controller; designing, deploying and managing services between the Legacy network to SDN network is natural and effective.
We have an MPLS segment routing forwarding architecture. SD-Control uses traditional MP-BGP signaling and discovery methods to interwork with legacy MPLS-based services (L3VPN, EVPN, L2VPN, VPLS, etc) and dynamically stitch them together with OpenFlow built MPLS-SR paths. No MPLS signaling protocol or session state maintained in the SDN network data-plane. MPLS transport is a common for all services; Legacy and SDN.
The LSC uses out-of-band PCE to analyze and decide how MPLS paths use the legacy network and SDN data-plane topology. This enables SD-Control to utilize legacy network and SDN resources for transport based on business policy.
That is SD-Control. It’s not a switch feature or single software product by itself, but rather a philosophy of where decisions are made in the network and how those decisions become instructions for the data-plane. The decisions about technologies and how they are integrated are critical.
In theory, a lot of people agree that this is the way to do it; the network transformation, bridging the gap between legacy networks and SDN. There are people who say it can’t be done, but we can show you that it can be done. We’ve been developing this solution with our clients— global telecom leaders that are transforming their network using Lumina SD-Control.