Behind the Closed 5G Doors: The Reality of Physical Legacy Resources in 5G Environments

Since our inception, Lumina Networks has been automating heterogeneous networks. It’s rare that you can find a company that can cross over from the virtualized world to the MPLS world seamlessly, which I suppose makes us a rare case. Add to that our leadership in the open source community, and Lumina has a very unique role in our ecosystem. Without being locked down to hardware sales and appreciating the necessity of community innovation, we find that we get to see and hear things no other organization does.

We take this role very seriously. We know we are a catalyst for change, both for our customers and the ecosystem. This unique role in the community has allowed us to get close to the real discussions behind 5G. It’s with that in mind that we wrote a book, Digital Transformation for 5G in the Real World, where we evaluated 5G perspectives. We collected input from our tier-1 customers around the world, enterprise partners and 5G users, leading analysts and publications, and influencers throughout the open source community. The opinions varied, but we found several common threads worthy of more attention. While we appreciate that there is no one right way to build and operate a 5G network, what we’ve learned is that there are a few factors with the power to be the wrong way to 5G. 

One of the 5 factors covered in this book is the role physical legacy resources will play in a 5G network. While the industry has agreed for many years that we need to remove network silos, therefore, forcing brownfield 5G, we’ve been hearing more and more that some communications service providers (CSPs) just want 5G out the door. The new plan for some is to move forward with greenfield deployments. While we expected to see greenfield trials, when it came to true deployments we were hoping the industry wouldn’t move backward, but alas….

When considering how to support legacy devices in 5G environments, there are several things to keep in mind. 

SDN Adaption Isn’t Easy, but it IS NECESSARY

SDN Adaptation involves providing a common control plane for different types of networks. In network services prior to 5G, it would be acceptable to provision and configure each part of the network separately, taking days or even weeks. This doesn’t work when providing on-demand, customizable services, and certainly, isn’t efficient or innovation-friendly. One would think this forces our hand toward greenfield deployments. On the contrary, however, if you want the efficiency improvements of network slicing and application placement, just to name a few, a 5G silo isn’t a functional possibility. Simply put, there are hundreds of millions of dollars invested in legacy devices - they aren’t going anywhere. So, we need to learn to include them in our 5G deployments. 

Another reason SDN adaption is needed to build a unified 5G network is that 5G networks will be “intent-based” (see our Intent Based Service Automation page). This means the end-to-end service will be defined in a high-level language such as TOSCA (Topology and Orchestration Specification for Cloud Applications). To enable TOSCA service definitions, the instantiation or configuration of the network functions beneath that, whether virtual or physical, will need to be automated. Closed-loop operational monitoring will help assure that the service meets pre-defined SLAs.

Delivering Cloud-Ready Services with Heterogeneous Resources is Possible

The services behind 5G will be “cloud-ready”, container-based leveraging microservices. OpenDaylight’s Container Orchestration Engine (COE) project, which is led by Lumina, is a vital tool in orchestrating the network components for container-based applications. OpenDaylight and now COE will support the NETCONF control interface that is common in today’s hardware and software routers. NETCONF is a stateful control interface, optimized for routers that publish in YANG like Cisco, Juniper and others, that was designed to allow an external controller to manage the configuration of routers. 

If you combine COE with SDN adaption, it becomes possible to orchestrate both the virtual and physical network elements to create the network slices and intent-based services necessary for 5G. OpenDaylight is a particularly well-suited controller to implement for 5G networks because it has both COE and NETCONF support, as well as a variety of other common control interfaces. This type of multi-cloud and multi-protocol support is absolutely essential for being able to leverage the existing network for 5G services.

Heterogeneous Telemetry can Close the Automation Loop

As networks transform to be more high performance and agile, closing the automation loop will require telemetry monitoring at scale. There are dozens of standards and protocols in this space, but they won’t support heterogeneous automation as they exist today. 

Collecting telemetry across a unified network isn’t easy. We’ll need to pull node-ID, ingress, egress, proof of transit, sequence number, time stamps, custom meta data from modern and traditional devices. Above this, to support 5G services, telemetry needs to be managed in real-time, needs to be massively scalable, and will require full visibility to all data (not partial data). 

A heterogeneous environment provides multiple challenges to collecting telemetry. First, different devices provide different interfaces for telemetry. Such interface requires different collection mechanisms. Second, the nature of statistics collected and the format of data is varied. Hence, the data collected from a given device needs to be interpreted specifically for the type and format of the data. Third, the frequency of hardware data collection might not align across the network. Hence, statistics collected in the network might not match across devices due to different sampling rates and offsets.

Legacy Resources Need to be DevOps-ready 

It’s simple - 5G will be all about new services, so CSPs need to start bringing more, faster. Service innovation has been tied to vendor productization for too long now. For the telcos to recapture the service innovation process, they must first make sure the physical legacy network is DevOps-ready.  

One-click service provisioning across every network resource will be necessary to allow CSPs to create and deploy services quickly. They’ll need language flexibility - to create services in whichever development language they prefer on a platform that extends the functionality of the OpenDaylight-based controller to the new services.

Traditional physical devices do not support the new interfaces preferred by NetDevOps and DevOps, such as NETCONF/RESTCONF. Typically such legacy devices have CLI interfaces only. Therefore, to manage legacy devices, we need an adaption layer to translate the newer northbound api to legacy interfaces. This adaption layer needs to be flexible to conform to and interact with varied OSS/BSS. As an example, one OSS might prefer a simple REST API to manage a given device, while another OSS might want to have scripts for interactions - different management systems have different workflows. This forces a requirement for flexible management of legacy devices to enable DevOps techniques.

Lumina Solutions Support All These Transformation Areas

Lumina Networks has been working since our spin-off from Brocade to help service providers automate their physical networks (read more on Service Automation). As we head into 5G, one thing is perfectly clear – partnering to transform is necessary. Transformation success will belong to the CSPs in-source transformative skills but understand when to partner to access expertise and leadership they don’t yet hold. Finding the right partners, with the right capabilities, the right experience, the right strategies and most importantly, the right philosophical alignment is critical. Learning to swim in the software and open source waters takes time. But having a swim coach to help you learn the strokes can accelerate your path to proficiency.  

One way Lumina has helped several worldwide CSPs transform is with Software Defined Core (SD-Core) architectures, which leverage SDN to provide end-to-end network clarity. These next-generation architectures revolutionize network capabilities by unifying network controls from the edge, to the data center, and to the core. By merging all legacy, cloud and programmable resources, SD-Core removes network silos to improve efficiencies and flexibility. The ubiquitous control streamlines security while enabling programmability and automation, regardless of interface.

The second tool that Lumina uses to enable physical resources is Intent Based Service Automation. This solution standardizes NBIs based on yang models (IETF/OpenConfig) and translates these models into multiple south-bound interfaces. From CLI commands for legacy platforms and REST APIs for EMS systems, our Service Automation platform manages heterogeneous environments including any proprietary interfaces (NETCONF, gRPC, gNMI). The solution is extensible through a microservices platform that can adapt to any network element. 

Intent Based Service Automation also allows CSPs to focus network operations around intent. The solution veils micro-configurations behind a script - the orchestrator communicates the intent to the SDN controller which is responsible for translating it into micro-configurations. By abstracting the micro-configurations, we are re-aligning the service to the business, and moving away from pure technology alignment. 

Although Lumina has several tools to enable these solutions, one of our products holds a lead role: Lumina Extension & Adaptation Platform, LEAP. LEAP enables automation of heterogeneous network elements using model-driven frameworks in an extensible fashion. LEAP extends Lumina’s OpenDayLight-based SDN controller using a microservices architecture and enables better integration with business layers. It promotes the addition of new microservices-based components in a language-agnostic manner, thereby enabling operators to use the scripting skills of their DevOps teams to extend their service automation frameworks in-house, based on business demands, without dependency on external vendors. 

Quick Technical Overview of LEAP

LEAP provides a framework to create microservices for network management applications. These microservices use a YANG modeled API to define their capabilities and enable microservices to easily interact with each other. The microservices communicate via an open source bus - as long as the services have IP connectivity and the YANG API definitions, they can interact with each other to collaboratively provide services for various networking requirements.

One such application of the LEAP framework is our CLI Management service, called CliConf. The CliConf microservice, along with a few companion microservices, was developed specifically to manage CLI for various devices. This service can mount CLI controlled devices on Lumina’s hardened OpenDaylight SDN Controller (LSC), and make them behave similarly to a NETCONF mounted device - the devices expose a YANG modeled RestConf API via Lumina’s SDN Controller

To interact with these devices, the user or operator would make the appropriate REST call to the device. For example, to read the configuration or operational state of a device, the user issues a GET call for a YANG model representing the device. This rest call will get handled by the JSON-RPC Extension application running in the LSC. JSON-RPC extension is an open-source application developed for OpenDaylight. It marshalls the GET call into a bus-based message and send to CliConf microservice.

The CliConf microservice will handle the GET call as follows:

  1. Calculates the necessary CLI needed to provide the data for the user-specified YANG model
  2. Connects to the device via SSH, execute the CLI and collect the output 
  3. Parses CLI output to extract the necessary information and is represented via JSON corresponding to the user-specified YANG model
  4. Returns the parsed output to LSC via the communication bus
  5. After extracting the parsed output, LSC returns it to the user as the response to the original REST call

The write operation is quite similar. Upon receiving the PUT or POST call, the CliConf will generate the set of CLI to be written to the device. This generated config will be sent to the device via SSH. 

For more information about how Lumina Networks has successfully helped three tier-1 CSPs transform legacy networks to enable 5G, contact us today.