Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
NETWORK MANAGEMENTWHITE PAPER
Lumina Networks, Inc.2077 Gateway Place, Suite# 500San Jose CA 95110
+ 1 (669) 231-3838+ 1 (800) 930-5144
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
Network Management White Paper
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
www.luminanetworks.com4
Network Management White Paper
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
www.luminanetworks.com 5
Network Management White Paper
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
www.luminanetworks.com6
Network Management White Paper
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
www.luminanetworks.com 7
Network Management White Paper
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
www.luminanetworks.com8
Network Management White Paper
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
www.luminanetworks.com 9
Network Management White Paper
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
www.luminanetworks.com10
Network Management White Paper
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.
www.luminanetworks.com 11
Network Management White Paper
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