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.”
Lumina CEO Andrew Coward, and COO Nitin Serro.
With an impressive turnout, presentations by experts in their field and of course, pizza and beer, the event offered a highly informative networking opportunity for the Open Source Networking community and marked the first OSN User Group Bay Area Meetup.
We kicked off the afternoon in our conference room with the doors wide open to a beautiful, sunny California day and heard first from Lumina customer and industry leader, Verizon with a lively discussion led by Hwa-Jung Han, Director of Emerging Technology, Verizon on building a programmable network infrastructure using Open Source SDN technologies and Verizon’s exploration of a new SDN ecosystem.
Sunny skies in San Jose.
Our very own Anil Vishnoi, Principal Software Engineer provided an overview of new offerings the OpenDaylight community is working on in the current release of Oxygen and upcoming Fluorine release as well as projects that are expanding use cases that users can solve for by using OpenDaylight. We also discussed ONAP with Bin Hu, AT&T, and explored the architectural vision of orchestrating workloads for Multicloud.
We had an energetic presentation from Rajat Chopra, R&D, Redhat who led us through an introduction to networking for large-scale container orchestration systems like Kubernetes, including an overview of requirements, common pitfalls and new technologies on the horizon.
Raymond Paik, Linux Foundation.
Raymond Paik of Linux Foundation followed up that presentation with a brief update on a new tool in the works from OPNFV Lab-as-a-Service and got us all excited about next month’s Open Networking Summit.
As presentations came to a close, we concluded the afternoon’s meetup with more mingling, live music and refreshments. A big thanks to all those who presented and attended; we look forward to see you all at the next one!
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-Core 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-Core 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-Core 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-Core.
The Lumina SDN Controller
The first building block of SD-Core 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-Core 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-Core to create the bridge from legacy networking to SDN.
Another critical component of SD-Core 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-Core 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-Core uses traditional MP-BGP signaling and discovery methods to interwork with legacy MPLS-based services (L3VPN, EVPN, L2VPN, VPLS, etc) and dynamically stich 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-Core to utilize legacy network and SDN resources for transport based on business policy.
That is SD-Core. 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-Core.
Lumina Networks is proud to announce its Founding Gold-level membership for the Linux Foundation’s new networking fund. This is a major consolidation of LF’s networking projects into a larger umbrella networking group. While it won’t change the individual projects for OpenDaylight, ONAP, OPNFV and others, it will definitely raise the stature of networking as one of the Linux Foundation’s primary areas of focus.
As a key contributor and leader of OpenDaylight, I’d like to comment from Lumina Network’s experience on how open source is playing a role in the generational change we are seeing in networking.
Open Source is Fast
Open Source is the quickest way to take ideas from concept to testing. In the past, ideas would be argued within the IETF or ETSI, sometimes for years, before vendors would create a compliant derivative. In the Open Source world, the whole approach is to write code first to prove concepts and try things that others can build upon. Bottom line, if you build your PoCs and ultimately production systems on Open Source platforms, you’re going to be moving quicker.
Open Source Changes the Balance of Power
Second, Open Source is a mechanism you can use to influence your vendors. If the vendor is supporting a platform, you should insist that platform be based on or compliant with the Open Source platform. If your vendor creates applications that run on a platform, you can insist that the application run on the Open Source platform and be portable to different distributions. This clarifies the work needed by the vendor and reduces the need for behemoth RFI/RFP documents to specify platform functions.
Open Source Attracts Innovation
Third and perhaps most important, Open Source will beckon a new class of innovators and technologists within your organization. Let’s face it, most of the “movers and shakers” in the industry are now involved in Open Source projects. When an Open Source community thrives, there’s no better way for the thought leaders in your organization to contribute their ideas at an industry-level and sharpen their skills as technologists.
All of these benefits- faster development cycles, increased influence on the vendor community and advancing the technology skills of your organization are essential in order to compete in the new software-defined world. Think of Open Source first, it’s one of the best ways to get to where you are going quickly.
During our recent webinar hosted by SDxCentral on SD-Core, we took a survey of interest on SD-Core and polled the audience on some of their preferences in where SD-Core will be applied. What is the definition of SD-Core? SD-Core is the term for the set of use cases that involve the evolution of core network technologies, such as MPLS, toward software defined networking. SD-Core is very different from SD-WAN, in that it pertains to the architecture of the service provider’s internal core network.
The term SD-Core is being coined because we at Lumina Networks are seeing the service providers looking to rapidly evolve their core networks and we are involved in several initiatives at major service providers globally. These initiatives involve both PoCs and deployments of various stages. Developments such as SD-WAN, 5G and others are putting pressure on the core networks not just in terms of traffic load, but also in terms of the need for service agility. Most of the market research I’ve seen says that carriers as a group are spending between 3 and 5 Billion dollars (US) per year on core network enhancements.
Our webinar attendees were admittedly parties interested in the SD-Core in the first place, but it’s still interesting to look at the poll results between the various options.
When asked, “if you are planning to evolve your MPLS core-based services, what underlying technologies are you considering?”, the audience was conservative.
The clear winner was adding central control to the existing network. I would interpret that to mean a desire for improved service agility and automation for the existing infrastructure. This also reflects our business at Lumina Networks as much of our NetDev activity centers on adding SDN control capabilities to already-installed switches and routers. Running in close second were the set of protocols that would involve changes to the underlying infrastructure including the desire for whiteboxes, OpenFlow or the very latest technology, P4.
So, for the next question, “what services are you looking to evolve to an SDN-based core network?” The results are not a surprise.
At a glance, this data likely reflects the service that network engineers administer today.
At Lumina Networks, we believe that core networking is ripe for a disruption. Emerging data plane technologies along with advances in open-source-based orchestration and control software are too compelling for service providers to keep doing things the old way. The question will be in how service providers transition their networks to the new technologies while maintaining their core network services. We’ll have more on hybrid core networking in a future Blog. Stay tuned to Lumina Networks!