Investing in Open Source Business Models

Investing in Open Source Business Models

Interest in evaluating and investing in open source startups is on the rise again after a dip in the past couple of years. There is a huge shift toward using open source platforms, particularly in the networking space. New open source initiatives such as ONAP (Open Network Automation Platform), OSM (Open Source MANO) and OpenConfig are being driven by the service provider community and large enterprises. As a young growing company focused on open source for networking with a unique approach (that tier-1 service providers appreciate), we are invited to many network transformation discussions with industry giants. Because of this role in the ecosystem, we can see relevant market trends before most. Based on what we’re hearing from across the aisle, we believe now is the time that investors should look closely at opportunities to drive and benefit from the emerging wave in this space.

It would be easy to conclude that this trend is just the industry’s way to get cheaper software and shift profits from the large vendors (like Cisco and Juniper) to the network buyers. But that would be an oversimplification of the opportunity. Lowering CAPEX and OPEX costs are surely in play. However, equally important are:

  • The need for better network optimization and automation tools
  • The requirement to move faster than the traditional hardware-based networking vendors can move and
  • The desire to co-innovate and take more control of the tools

These factors are driving the open source trend just as much, if not more than the cost factors. Wise investors should look at these drivers as opportunities. Companies that can deliver these benefits using open source software stand to gain significantly.

All of this raises questions about the business model of open source. Conventional wisdom goes something like: “RedHat is the only company that has been successful at monetizing open source”. Nothing could be further from the truth. Many companies have been successful using open source as the centerpiece of their product strategies. Elastic, GitHub, Cloudera and Mulesoft are recent examples of open source-based businesses. In the past several years, MySQL, Zensource, Springsource, Zimbra, JBoss and Suse have all had very successful exits while building a business on open source platforms.

There are many different types of open source products and services have proven to be valuable to customers and revenue-generating for vendors.  Vendors that provide these types of services on an unchanged open source base are referred to as “pure-play” vendors. The intention of pure-play vendors is to ensure that the customers reap the full benefit of utilizing open source software, including no vendor lock-in. Let’s take a look at these types of these pure-play offerings:

  1. Product support for the open source code base – Examples of this include defect resolution, testing, continuous integration, extended support, upgrade and migration support and open source community advocacy.  All of these are valuable services not typically provided by open source communities.
  2. Applications running on an open source platform – These applications perform specific use cases or user-facing functions. Typical applications perform zero-touch configuration, overlay/underlay network control, traffic engineering, planning, configuration management, inventory, analytics, service assurance, fault remediation or policy control. Narrowly-focused, these applications can be of great value to service providers and of even greater benefit when combined with other open source platforms.
  3. Device or systems integration – There’s a lot of value and ongoing benefit to assuring that the open source platform interfaces to various devices continue to operate across revisions as well as support for new network devices. It’s also no secret that deploying open source platforms is complicated. Working with experts in the space, and your named platform cannot only accelerate integration and deployment times but can be part of a knowledge transfer initiative as well.
  4. Custom software development –  All network operators have functions or services that they want to be specific to their environment or service. Vendors are in a very good position to provide custom software development because of their deep understanding of the open source platform.

Are there questions about the business open source business model for the networking space? Yes, absolutely there are yet-to-be-answered questions. But by the time we have all the answers, the best investment opportunities will have gone. So, now is the time to look at investing in open source networking – call us if you want to understand more about this space.

Want to learn more?

  • Hear what some of the industry’s thought leaders are saying on this topic – this Telecom TV video with VMware, Amdocs and Lumina Networks highlights the power and relevance of open source in a transformational network.
  • Learn more about relevant open source projects with Linux Foundation.
Neglected Factors in 5G: SDN-R & Wireless Transport SDN

Neglected Factors in 5G: SDN-R & Wireless Transport SDN

Software Defined Networking (SDN) concepts are alive and well in the indomitable march to 5G. Control plane to data plane separation, network programmability and closed-loop automation techniques are being defined, developed and tested in numerous PoCs and early trials. The specification bodies and open source organizations are cooperating to define the architectures and protocols required for next-generation wireless. One of the more prominent open source projects in the 5G space is ONAP (the Linux Foundation’s Open network Automation Project) which is developing the SDN-C and APP-C controllers, based on OpenDaylight. More recently, ONAP is working to develop the OpenDaylight-based SDN-R controller, which is the focus for this article.

The SDN-R project is aimed specifically at wireless transport SDN. “Transport SDN” is the concept of multiplexing and carrying multiple services or network slices across the backhaul network, usually over a geographic distance, a fundamental concept in 5G networking. The “R” stands for radio. SDN-R is concerned specifically with coordinating the functionality needed to support services traversing Optical or Microwave networks.  Although a new group in ONAP, SDN-R builds on several years of work and earlier trials within the ONF (Open Networking Foundation). This is welcomed cooperation between two different standardization groups, something we need to see more of in the orchestration space.

SDN-R-Diagram

The original proof of concept trial focused on the ONF’s OpenFlow interface as the controller protocol. However, more recent PoCs have also utilized NETCONF and have focused on the information models as well as YANG. The concept of a mediator has been introduced, recognizing the reality that there will be a wide variety of vendor equipment, both PNFs and VNFs, used with a variety of interfaces and APIs. Lumina’s SDN Controller architecture is ideally suited to create mediators and have them function as a model translator for OpenDaylight.

As the SDN-R project proposal explains very clearly, the objective is to port the models and controller of the ONF Wireless Transport project into the ONAP framework.  Since, starting in 2015, the Wireless Transport Project within the Open Transport group of the ONF has pursued the goals of defining a shared data model for wireless network elements and developing a Software Defined Network (SDN) controller to manage a network made up of equipment from several manufacturers.  The model is defined in the ONF Technical Reference TR-532, and the SDN controller is based on OpenDaylight. Because the controller is based on OpenDaylight, it is consistent with the ONAP architecture, and the majority of the software for the applications can be ported into ONAP with only minor modifications.

Lumina Networks looks forward to continuing our contributions to the SDN-R and to ONAP broadly. The development of 5G networking is complex, as it will involve a combination of new and old equipment, VNFs and PNFs, virtual machines and containers and vendor equipment based on new standards as well as equipment based on proprietary APIs. 5G services will need to be applied end-to-end consistently across all of these and with closed-loop automation to provide service assurance.

The SDN-R leverages Lumina’s development and deployment experience with NETCONF. NETCONF interfaces are the most commonly deployed for Lumina’s customers and we have experience dealing with voluminous YANG models in production, and as always, we have contributed our efforts back into the open source community. Specifically, for SDN-R, the NETCONF/YANG constructs give us the ability to manage the transport service end-to-end in addition to device-by-device.  And, as regards to devices, we have developed the tools and software to extend control to non-NETCONF devices as well, so that legacy equipment can be used for SDN transport.

As we have established in this blog series, the only way to achieve this type of architecture is with an open-source control plane, most often based on OpenDaylight. Therein lies the neglected factors in 5G – that is, while much of the 5G network will be new, the only way to achieve cost-effective deployment in a reasonable timeframe will be by using existing protocols and already-installed systems wherever possible. Building on what we already have and bringing to its open-source-based control and orchestration software will be the formula that makes 5G possible for most service providers.

Learn more about the neglected 5G factors:

  1. Neglected Factors in 5G: Network Slicing
  2. Neglected 5G Factors: How SDN will Enable Brownfield Deployments

Deploy-5G-in-a-brownfield-environment

Neglected Factors in 5G:  Network Slicing

Neglected Factors in 5G: Network Slicing

It may seem odd to long-time networkers that “slicing” is discussed extensively in relation to 5G deployment. After all haven’t we been using VLAN, VPNs, VRFs and a whole host of ways to slice and dice networks for many years? Keep in mind that for established 4G networks, there has been no easy way to create logical segments or divide the network into granular slices, even in cases where the equipment may be capable of it. While legacy services hosted MBB, voice, SMS and even MVNOs on the same infrastructure, it was built in a way that was either physically discrete, channelized or rigid – not the way a packet network, and thus 5G, would do things. This approach is monolithic and will need to be updated for successful 5G deployments.

With packet networking, software-defined networking and network function virtualization coming into the network buildouts for 5G, network slicing is becoming an important part of service agility. The power of 5G is not just in higher-data rates, higher subscriber capacity and lower latencies – it is in the fact that services and logical networks can be orchestrated together. This is critical for deployment of connected car, IOT (Internet of Things), big data and sensor networks, emergency broadcast networks and all the amazing things that 5G will be able to support.

But there’s an often-overlooked element of the 5G rollout, slicing deployment over existing equipment, is something that Lumina Networks is uniquely equipped to enable.

Most presentations that you will see on 5G (especially from the vendors) just assume that the provider will be buying all-new hardware and software for the 5G buildout. In reality, a lot of existing equipment will need to be used, especially components that are physically distributed and expensive or impossible to access. How will the new network slices traverse these legacy devices?

Network slicing will traverse from the mobile edge, continue through the mobile transport, including fronthaul (FH) and backhaul (BH) segments, and the slices will terminate within the packet core, probably within a data center.  Naturally, this will involve transport and packet networking equipment in both the backhaul and fronthaul network. The packet core will also likely involve existing equipment. These systems will rely on the BGP protocol at the L3 transport networking layer, even when they are newer platforms.

The 3GPP organization’s definition of a slice is “a composition of adequately configured network functions, network applications, and the underlying cloud infrastructure (physical, virtual or even emulated resources, RAN resources etc.), that are bundled together to meet the requirements of a specific use case, e.g., bandwidth, latency, processing, and resiliency, coupled with a business purpose”

Given the number of elements involved in a slice, sophisticated cloud-based orchestration tools will be required. It’s noteworthy that many of the optical transport vendors have acquired orchestration tools companies to build these functions for their platforms. However, since the start of the Open Network Automation Project (ONAP) at the Linux Foundation, it is clear that the service providers will demand open-source based platforms for their orchestration tools. Rightfully so, an open solution to this problem reinforces operators’ desire to end vendor lock-in and enable more flexible, service-creation enabled networks.

The creation of a “slice” in a 5G network will often involve the instantiation of relevant and dedicated virtual network functions (VNFs) for the slices and this is a key aspect of the work going on in the ONAP project. VNFs, in addition to participating as connectivity elements within the slice, will provide important functions such as security, policies, analytics and many other capabilities.

5G-Network-Slicing

The good news here is that established open source projects such as OpenDaylight have the control protocols that will be used for legacy equipment, such as NETCONF, CLI-CONF, BGP-LS and PCEP, as well as the newer protocols that will be used for virtual L3 slicing such as COE and OVSDB.

Some of the network slicing capabilities that these protocols enable are:

  • Supporting end-to-end QoS, including latency and throughput guarantees
  • Isolation from both the data plane and orchestration/management plane
  • Policies to assure service intent
  • Failure detection and remediation
  • Autonomic slice management and operation

ONAP utilizes the OpenDaylight controller as it’s “SDN-C”. And, more recently ONAP has a new project to develop an OpenDaylight SDN-R to configure radio transport services.

This blog series, “Neglected 5G Factors” will address  SDN-R more our next blog. For now, be sure you’ve read the first of the series “How SDN will Enable Brownfield Deployments.”

Deploy-5G-in-a-brownfield-environment

Neglected 5G Factors: How SDN will Enable Brownfield Deployments

Neglected 5G Factors: How SDN will Enable Brownfield Deployments

There’s a lot to consider in 5G service roll-out, but there are a few key areas that are often overlooked. Lumina Networks feels a responsibility to the community to illuminate the truth behind 5G transformation, to highlight these overlooked “secrets” which can make-or-break your 5G strategy. The factors you’ll read about in this blog series have a drastic impact on a service providers digital transformation – they are the software-defined networking components that play a critical role in making 5G services possible and accelerating deployments.

5G DeploymentAs an industry, we’ve all agreed long ago the agility needed to run 5G services will come from a more software-based network. While virtualized components and functions are powerful tools in enable flexibility, we need to deploy 5G in brownfields, not green.

It’s with this in mind that the first factor which requires more consideration is the role legacy, purpose-built infrastructure needs to play in performing the functions necessary for 5G services. We call this use case SDN Adaption. Adaption 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. You can understand why this area is often overlooked in the market conversation as large vendors with a lot at stake, and substantial marketing budgets, prefer to keep it that way.

By necessity, 5G networks will be “intent-based” networks where the end-to-end service will be defined in a high-level language such as TOSCA (Topology and Orchestration Specification for Cloud Applications). The instantiation or configuration of the network functions beneath that, whether virtual or physical, will be automated. Closed-loop operational monitoring will help assure that the service meets the pre-defined SLA.

The common control plane needed to configure and monitor the network elements works in two different ways.

Container orchestration for virtualized applications

 

The services behind 5G will be “cloud-ready”, that is they will be container-based and leverage microservices.  They will also need to be orchestrated (see our blog on what it means to be cloud ready). OpenDaylight’s Container Orchestration Engine (COE) project is a vital tool in orchestrating the network components for container-based applications. The COE project, led by Lumina’s own Prem Sankar Gopannan is designed to provide L2 and L3 networking between containers or between containers and virtual machines for Kubernetes-managed environments. COE includes interfaces to KVM and Containers and OpenStack (via Kuryr). A northbound CNI is available for bare-metal based containers.  This is important for micro-datacenters where compute resources are scarce. As such, COE can support a variety of use cases where cloud-based networking is required such as in 5G services networks.

Tying Existing Routers to 5G Services

While COE takes care of the future, what about the past?  That is, what about equipment that is already installed or VNFs that are based on legacy network OS’s? There’s good news on this front as OpenDaylight and now COE specifically will support the NETCONF control interface that is common on today’s hardware and software routers. NETCONF is a stateful control interface that was designed to allow an external controller to manage the configuration of routers. NETCONF is optimized for routers that publish YANG information models and is a commonly supported interface for Cisco, Juniper and other types of switches common in 5G front haul and backhaul networks.

Putting the above two capabilities together, it is 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.

Realizing this type of virtualized network architecture is the future, our major tier-1 CSP partners are already aligning to the new network architecture. In fact, AT&T has already been working on this for several years.  

In my next blog, we will delve into a common 5G use case that depends upon this type of converged network architecture.

Deploy-5G-in-a-brownfield-environment

 

Pin It on Pinterest