network management white paper · the time and costs are spent in the network integration aspects...

NETWORK MANAGEMENTWHITE PAPER

Lumina Networks, Inc.2077 Gateway Place, Suite# 500San Jose CA 95110

+ 1 (669) 231-3838+ 1 (800) 930-5144

[email protected]

www.luminanetworks.com2

Network Management White Paper

Lumina Networks’ Service Abstraction Simplifies Network Management With Lumina’s software-defined networking tools and service abstraction methodology, service providers can allow business logic – rather than vendors’ proprietary hardware and software – to define their network technology. The time it takes to make changes in the network or turn up new services is reduced from months to days (or less). Plus the reliability of change increases and flexibility enables typically disparate domains to be automated.

Network management is a complex space and can add significantly to the cost of network operations

Telcos and service providers are under tremendous competitive pressures today as new technologies blur their tradi-

tional lines of business. At the same time, new opportunities abound. Service providers want to grow their business,

grab market share, increase service agility, and gain a competitive advantage by bringing innovative services like 5G and

messaging platforms to market quickly.

This often means making significant changes or upgrades to their network. With a legacy network, this is no trivial task.

Every time there is a significant change in the network OS or a new vendor’s network element, it costs the SP “a million

dollars and six months.” This phrase is uttered in half-hearted jest, but service providers know it holds the truth.

Introduction

www.luminanetworks.com 3


The time and costs are spent in the network integration aspects of the change—to the network operations center, the

operations support system, and the business support system. The development effort is in the workflow provisioning and

other tasks necessary to turn up a new service. Every change in the network is a custom integration. The more equipment

and more vendors involved in the changes or additions to turn up the new service, the more integration work required.

Even iterating within a single vendor’s proprietary data models can require entirely new constructs in the CLI or the XML

API that leads to significant work (i.e., time and money). All the integration work comes at the cost of lost time-to-market.

For example, deploying a second vendor into a metro network, xCPE, or SD-WAN project normally costs at least 100%

of the same time, money, and effort as deploying the first vendor. This legacy approach is due to each vendor requiring

the exact same OSS, BSS, and other integrations to be redone each iteration. The same can be said for seemingly simple

network OS upgrades, where vendors make major changes to their data models. It’s functionally identical to deploying a

second vendor in parallel.

Telcos are not at fault in how they got here. Network vendors have only ever provided propriety and bespoke interfaces

to this equipment. Some even bespoke for each device from a single vendor. Similarly, the software approaches employed

in the development and lifecycle management of their operational support systems were good for the time but are now

out of date. Add to this that telcos have no control over either of these technology domains and you have the rationale

for a new approach.

Evolving network management in the traditional way adds to the growing

complexity of tools, dependencies and vendor limitations



When a service provider product team wants to introduce a new service, it thinks in terms of function, not in terms of

vendors who can help provide that function. When the team says, “We want to deploy this metro service that has an ‘A’

endpoint and a ‘Z’ endpoint,” they aren’t thinking in terms of the underlying technology being from Cisco, or Juniper, or

Calix. The product team has a business use case in mind for earning revenue, and the sooner they can bring the product

to market, the better.

While this ideal approach to product development has the service provider in control, there are cases when they get sold

to by vendors. When a product manager bases his product on the latest bell or whistle from Vendor A, he creates the

lock-in his engineering team wants to avoid. And then when Vendor A sells the same bells and whistles to his competitor

down the road, his advantage is neutralised. Leading service providers have come to see this zero sum game as a trap,

which leads them to build product capabilities in-house that they own and can use as differentiation from competitors.

The network development team, however, has to think about the technical means required to deliver that product. In

order to avoid vendor lock-in through this process, the service provider must consciously decide to not trip into one of

two pitfalls. First, the product managers and engineers must not choose special vendor bells and whistles as the key sell-

ing points for their service. Second, the service provider must not be lulled into purchasing multiple vertically integrated

solutions from a vendor to make it easier to deploy or manage. Instead, a principled architecture approach is required to

define modularity and interfaces for interoperability.

A better approach would be to have the business logic define the network technology, without any vendor-specific lan-

guage. This is possible with abstraction, where the network development team is able to define the service completely

independent of vendor technologies. The abstraction can be applied at the service or device level, or both. Service ab-

straction is IPVPN, E-Lines, E-Trees etc. modeled in a vendor agnostic way for both greenfield and brownfield networks..

Device abstraction is where a vendor specific model is abstracted to vendor agnostic model, such as open config. The

litmus test is whether the vendor used in the network could be swapped without any changes in the abstracted models.

In effect, the underlying technology is loosely coupled to the model enough such that the integration iteration only has

to be done once, and any future changes or additions are simple replicas of those translations.

Service abstraction isn’t a new concept; it has been around for a while. For example, this is what tail-f implemented by

superimposing a YANG model on top of CLI. However, previous attempts of creating models have had their limitations,

such as doing translation only for the southbound provisioning side.

A Better Approach: Service Abstraction



Lumina has developed a RESTful API that enables service providers to manage their entire network through one common

means. This API decouples the actual network elements and element management systems from any of the tools that

are currently interacting with them. This allows those tools to immediately have the opportunity to shed any sort of

proprietary interfaces and duplication of efforts.

OpenDaylight is perfectly suited for this exact purpose, and so ODL is the very the foundation for Lumina’s work. Lumina

has extended ODL’s core functions to any management protocol, over any transport, in any direction, no matter how

proprietary. Using the ODL framework, Lumina’s applications allow a service provider to translate literally any network

element interface or EMS – or whatever is needed – such that OpenDaylight can control or service any type of network

element no matter how legacy or proprietary.

Network operators need to move to an open source based abstraction

architecture in order to simplify management of the network

Lumina Networks’ Service Abstraction for Network Management



Lumina uses a true, non-forked upstream distribution of OpenDaylight that is thoroughly tested and quality-assured.

From there Lumina splits each of the separate functions into a microservice, such as one for translation, one for gover-

nance, and one for each specific network element or protocol. Examples include MQTT, gRPC, CLI, SNMP, and XML API,

but are not limited by any vendor, protocol, or proprietary interface.

Furthermore, the microservices allow both northbound to southbound transactions (i.e., provisioning), and also

southbound to northbound (i.e., pub-sub telemetry, streaming, and modeled alarming).

Atop this, Lumina has added the configuration management pieces that many service providers request, such as rollback

and config data store. So, ODL, coupled with the Lumina extensions and microservices, really does equal a single open

source abstraction layer for the whole network, whether that be network configuration, service assurance, or even ma-

chine learning. This is a problem that is perfectly solved with an industrywide collaborative open source solution, thereby

delivering lasting vendor flexibility. Open source also enables service providers to build their own functions on top of the

ODL platform for service differentiation or operational simplification.

Until now, there really hasn’t been anyone in the networking arena focused on both directions, to translate any protocol

to any network element or EMS, and vice versa. But this is exactly what Lumina Networks does.

One of Lumina’s customers had a need to deploy three services in three consecutive quarters—a practically impossible

feat with legacy networking technologies and practices. This SP wanted to deploy a combination of next generation

metro network services, enterprise VPN services and Internet gateway services.

A Customer Example of Lumina Service Abstraction in Action



WHY LUMINA IS THE RIGHT CHOICE

Each of the three deployments involved at least two different vendors, and the three projects overall involved a large va-

riety of vendors. The original plan was to bring everything into the lab and deploy the new services using their old tools,

doing one vendor at a time and integrating with every single toolset.

The plan became complicated in a hurry because it involved six vendors multiplied by a minimum of about ten different

toolsets upstream. For every one of those proprietary interfaces, the SP would have had to rewrite all their provisioning,

service assurance and network operations center tools.

Instead, Lumina enabled the company to write each one of those tools one time, and then do micro iterations for each

subsequent use. In this case, micro iterations are no more than a translation template written in a simple language—typi-

cally a few hours’ worth of work. Lumina started doing the templates, and in the process trained the SP’s engineers, who

then took over the work.

In the end, the SP was able to deploy into production three dissimilar services involving different vendors in three con-

secutive quarters—meeting the company’s business goals towards new revenue opportunities.

Common services provided by Lumina Networks’ network management abstraction and applications



First and foremost, the service abstraction approach eliminates much of the ongoing integration efforts that service pro-

viders must make with each change or addition, saving significant time and money. More importantly, the company has

a faster time-to-market and more differentiation potential with new services, thus gaining a competitive advantage and

accelerating revenue opportunities.

Lumina can abstract away proprietary protocols to harmonize and simplify the network management. For example, while

Cisco and Juniper do similar things, they have their own way of doing them. These proprietary methods aren’t a factor

anymore once a service provider has one API to manage the whole network. Moreover, this approach provides more

choice by enabling the opportunity to use vendors that don’t necessarily embrace a standard such as OpenFlow, NET-

CONF or OVSDB. Regardless of the protocols they use, Lumina can bring them into the fold through that single API and

transcend vendor limitations.

Because the underlying protocols no longer matter, service providers have the opportunity to use both legacy and mod-

ern technologies in their network. Now they can plan and execute their migration to new technologies at their own pace

and have a smooth path for getting to where they want to be without disruption of services.

Likewise, service providers have the opportunity to gain vendor independence, since the proprietary offerings of each

vendor are minimized through Lumina’s approach.

As for an SP’s workforce, the engineers can concentrate on simply being networking subject matter experts rather than

vendor-specific experts. This reduces the need for expensive and time-consuming vendor certifications. What’s more,

the service abstraction approach moves the network engineering team more toward a DevOps mentality for quick de-

ployment of services into production.

• ELIMINATE MUCH OF THE INTEGRATION EFFORT.

• SAVE TIME AND MONEY.

• SIGNIFICANTLY IMPROVE TIME-TO-MARKET.

• HARMONIZE AND SIMPLIFY NETWORK MANAGEMENT.

• BRIDGE LEGACY AND NEW TECHNOLOGIES.

• GAIN A “DEVOPS MENTALITY” FROM NETDEV.

The Benefits of Lumina’s Approach to Service Abstraction



The Lumina Networks platform and applications take advantage of an emerging approach to software development

commonly referred to as microservices. Developing applications using a microservices framework has a number of

advantages such as horizontal scalability, and improved ability to develop incremental new services and to expand the

application’s features. Furthermore, the microservices development approach makes applications more serviceable and

more robust.

A couple of key innovations that make microservices practical are containers and microservice busses. Containers are a

method of operating system virtualization that allow you to run an application and its dependencies in resource-isolated

processes. Containers can help ensure that applications deploy quickly, reliably, and consistently regardless of deployment

environment. Container orchestrtation tools, such as Kubernetes, help solve the dependency management and auto-

scaling problems.

In a microservices architecture, the communications bus is a key component. In the Lumina architecture, ZeroMQ is

utilized. The bus uses a protocol which is granular and lightweight. ZeroMQ (also spelled ØMQ, 0MQ or ZMQ) is a

high-performance asynchronous messaging library, aimed at use in distributed or concurrent applications. It provides a

message queue, but unlike message-oriented middleware, a ZeroMQ system can run without a dedicated message broker.

A Word About Microservices

Lumina Networks’ approach to network management abstraction takes

advantage of a microservices architecture that brings benefits in terms of

development efficiency, performance and scalability



Time-to-market is already a critical element of success in a highly competitive market. Service abstraction is the means

to deploying complex services quickly, making it the future of carrier networking. Lumina makes it available now with

proven technologies and methodologies “taken out of the lab and into the live network.”

Lumina Networks offers a variety of product and service options that can help you start to reduce the complexity of

network management. The following is a summary of some of the products and services offered by Lumina

Call now: +1 (669) 231-3838 +1 (800) 930-5144

Visit Us Online: www.luminanetworks.com

Email us: [email protected]

Take Action

Do you have a challenging networking project that could benefit from a transition to an open, software-based network? Contact Lumina Networks today to discuss your needs with a network engineer and to learn how open source platforms and agile deployment services deliver what matters to you.



Lumina Networks believes the future is open software networks that give providers control over how

they implement their ideas and priorities for change. Lumina is the catalyst to bring open software

networking out of the lab and into live networks—to ensure that providers can use open source in

critical use cases, not just experimental ones.

Yet, delivering technology by itself is not enough. Lumina’s customers are learning and doing the work

with Lumina NetDev engineers so that they acquire the skills, tools and practices needed to develop

and manage the unique platforms that are jointly deployed. Lumina becomes a partner, mentor, and

custom developer to help service providers move their technology to the open source world.

Lumina Networks has a clear strategy to disrupt the networking industry status quo with open

source and agile deployment. By developing open source platforms and enabling innovation and

transformation through NetDev Services, Lumina is the catalyst to open software networks.

ABOUT LUMINA NETWORKS

Lumina Networks, Inc.2077 Gateway Place, Suite# 500San Jose CA 95110

+ 1 (669) 231-3838+ 1 (800) 930-5144

[email protected]

network management white paper · the time and costs are spent in the network integration aspects...

Documents