This week, we implemented new features in our Flow Manager product that allow large network providers to immediately evolve their BGP/MPLS networks toward SDN, using a centralized controller and lower cost infrastructure. We will be demonstrating these features at the Linux Foundation’s Open Networking Summit in Los Angeles.
SD-Core brings both existing BGP/MPLS routers and new white box switches, under the control of SDN, combining the use of BGP, PCEP, NETCONF, OpenFlow and P4, to deliver automated end-to-end services, provisioning and management.
“In every SDN deployment, bringing the existing network under an automation framework is the number one priority,” said our CEO, Andrew Coward. “What makes Lumina different, is our ability to operate a single control plane that software defines the existing routed network and enables white-box vendors to integrate into the solution with next-generation switching protocols. This allows our provider customers to offer their existing services seamlessly over both, while at the same time expanding their offers to more advanced services, thus bridging the gap between the old and new”.
Our Flow Manager now supports the ability to define VLAN, MPLS and Segment Routing intent paths over low-cost switches. Also, Flow Manager can assign packet transport services to the paths including E-Line, E-Tree, L2VPN or L3VPN. To achieve these capabilities, Flow Manager runs using the Lumina SDN Controller, Powered by OpenDaylight™, along with the OpenFlow and BGP plugins provided by the controller.
The implementation includes a centralized path policy manager function providing many of the traffic management features found in traditional BGP/MPLS networks also provides very unique features including fine grained traffic classification at the service ingress node, traffic replication and point to multi-point (P2MP) services including “anycast” destinations, and L2-L4 packet field manipulation at the service egress node.
Lumina Flow Manager release 6.1 is available as a free trial version, along with the Lumina SDN Controller, Powered by OpenDaylight™ and can be obtained at https://www.luminanetworks.com
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.