In our 5G eBook, we talked about the critical need for unified orchestration in communication service provider (CSP) networks. To review: 5G services will make CSP networks even more complex than they are now while raising customer expectations. The only way to deal with this complexity (and deliver the dynamic, high-quality experiences that customers expect) is to automate practically every aspect of service delivery.
To do it, CSPs will need to unify orchestration of their heterogeneous networks. That is, they’ll need some way to orchestrate end-to-end across physical, virtualized, and containerized network elements. This means the controllers handling the various southbound segments of the network need to be able to communicate seamlessly with each other and with the overall orchestrator in real-time.
Of course, this is easier said than done. In fact, solving this challenge is one of the big reasons CSPs come to Lumina in the first place. So how do we solve it? Let’s take a closer look.
Inside SDN Adaption
As the centerpiece of the unified orchestration section, the eBook discusses SDN adaption—providing a common control plane for different types of networks. We cover container orchestration of virtualized applications, tying in legacy routers, and the role of the SDN controller in end-to-end orchestration.
The best way to think about these concepts (and the way we do when responding to RFIs and RFPs), is to think in terms of workflows. What’s actually happening at the micro-level between various elements in the network, and in what sequence does it happen? What inputs do controllers receive, which modules do they attach to, and how do they operate? The answers will be different depending on the CSP’s use case and environment. But let’s examine one common 5G use case, mobile edge computing (MEC).
We start with the underlay technology. For our purposes, say we’re using Lumina’s SD-Core architecture—a segment routing-based framework CSPs can use to define, establish, and monitor customized paths for traffic traversing the network. In a real RFP, we would then describe the signaling protocols used to request paths through the network and stitch them together, the model types used to model those paths, and the path computation algorithms that would be employed.
Depending on the specific scenario, path reservations could be based on a number of factors—delay, available bandwidth, time of day, costs of assets, etc. We’d then detail the service models that would match what the customer would need to orchestrate the service. That is a YANG model for the path (which will be handled by the SD-Core path computation engine) and an edge attachment to that path. For MEC, that attachment may be a compute domain provided as an OpenStack pod or kernel-based virtual machine (KVM). Underneath the YANG model for the service would be the specific network element configurations, done via OpenConfig or other Models defined in YANG, depending on the network domain.
To define an MEC service that extends across the CSP network, we’d write an application that would work with Projects that reside in the Lumina SDN Controller (LSC) that would receive service Intent from an orchestration system and then enact the model to instantiate and end-to-end from path to service, typically we see that orchestration platforms are using TOSCA templates to define Services. The end result: a template for a network service where the CSP can specify intent. That intent could entail applying any number of path constraints the service requires. In production, the LSC’s role would be to receive that network intent, set up the path, receive the service model stitching the service to the actual path, and then build the service in the network.
For MEC, we also have to attach the actual virtual network function (VNF). Here, the SDN controller may provide a service that functions as the element abstracting that VNF and modeling its configuration and attachment points. Alternately, if the customer is implementing MEC via an external resource, they might be using VMware vSphere or one of the projects in OpenStack to configure that compute pod resources. In that case, LSC would just link the orchestration of that compute element into the service we’re defining through the orchestration template.
Preparing for a 5G World
Note that for 5G applications, we need more than just a basic connection service, as we would with 2G or 3G applications. In those legacy cases, you’re typically just building a path to the nearest gateway. With 5G (especially a case like MEC), those resources are dynamic, and their location is expected to change at any time. This is where SDN adaption becomes critical, ensuring that the handset can get to the data services it needs anywhere in the backhaul network. The LSC abstracts the applications that control those dynamic connectivity services and executes the business intent—ensuring that the connection to that data resource traverses a specific route, uses a particular network slice, receives a specific service data performance profile, etc.
Of course, it’s possible to implement business intent without unified orchestration. You can get human beings and/or scripting to configure all these things—they just can’t do it very quickly or they can’t scale efficiently to meet the longer-term performance metric requirements. Whereas once we start to abstract these network functions and abstract the way we specify intent for these applications, it now becomes possible to provide for programmatic logic required for software to program the network autonomously—and deliver highly customized 5G services in real-time.
Understanding the Division of Labor Between Orchestrator and Controller
One question we sometimes hear is, “Can’t my orchestrator handle this? Why do I need to do this with LSC?” The question gets to the core differences between orchestrators and controllers, as well as the value of open device integration versus proprietary.
In terms of pure technical capabilities, orchestration platforms do have a controller component. At some layer, they perform some kind of normalization function to model a device and introduce a southbound connector (or sometimes a protocol interconnection). But this is really just one partial controller function as far as connecting to southbound network elements. The controller goes beyond this by providing full network element abstraction—that’s its core function. It normalizes network/domain functions from diverse southbound network elements to templates that northbound systems (including orchestration systems) can interface to.
When Lumina implements abstraction in our SDN controllers, we normalize to a common YANG model or even just common protocols like REST. By providing a single common system to abstract all the different network functions, it becomes much easier for the orchestrator to model—using a similar language, with similar constructs and ways of doing things. It also becomes much easier to change and adapt southbound network devices.
Want to bring a new network element into your orchestration? You define the model to conform to your existing way of working and just push that model onto the controller. The LSC handles all the translation and southbound mapping. Everything uses common, open models, and you now have a consistent, effectively guaranteed abstraction layer for everything in your network.
Keep it Open
The other key advantage of an open-source controller approach is, well, it’s open. Because that’s the other big downside of trying to handle southbound device abstraction with an orchestrator—it’s almost always going to be proprietary. That means:
- There’s likely no way for you to change it.
- The device integration code will be developed to follow the orchestration vendor’s business model, not yours. If the vendor is off chasing deals in Domain A, there likely won’t be much focus on Domains B, C, and D.
- You have no way of controlling the direction of the architecture and no idea how it will scale to multiple domains.
- You can easily get locked into a data plane where it becomes difficult and expensive to introduce new functions.
- If you use multiple orchestration platforms (as many CSPs do), you end up paying a lot for duplicate functions to have closed, vertically integrated systems for every domain.
Alternatively, when you use an open-source controller like LSC to handle abstraction, you have an open platform, backed by an active developer community, that can deliver consistent device and configuration template models for all network domains. You have the freedom to invest in the technology if you choose via the community—pulling code, reading code, pushing code, and changing and enhancing it. You have the flexibility to build a broad range of applications with intent-based abstraction. And you can integrate into any orchestration system via standard northbound APIs and YANG models.
These are just some of the advantages of using an open-source controller-based architecture. It makes end-to-end orchestration much more scalable across all network domains and devices—whether virtualized, containerized, or legacy. And it’s that business and technical flexibility that CSPs need to thrive in a 5G world.