Lumina SD-Control: Building Blocks for Network Transformation

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 the 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 a 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 a 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.

Segment Routing

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 a 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 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.