The components of SDN, NFV, MANO & OSS

When you curate a website / blog called PassionateAboutOSS, it’s pretty obvious that you would see the world through OSS-tinted glasses. The tech-world at least.

And so it has been for me when evaluating new comms network / service concepts like SDN / NFV. It’s been a case of, “that all sounds really exciting and great for network engineers, but how will it help the OSS revolution?” Similarly, how can the great work invested into the OSS industry help network virtualisation technologies to operationalize?

To help get my head around the models put forward by ETSI (NFV) and ONF (SDN), I prepared the following triptych to show a component model that would support their theories. I was especially interested in understanding and showing where it impacts network and service management (ie OSS). I hope it also helps you to put the jigsaw together.

.

The three panels of the triptych are as follows:

1. SDN / NFV Shared Model (Left) – This is basically the shared model developed by ETSI and ONF to describe how the elements of their respective standards work together.
2. NFV MANO Model (Right) – This is a slightly re-worked version of ETSI’s MANO (Management and Orchestration) topology
3. The component Model (Middle) – This is my attempt at trying to visualise the physical and virtual components that deliver upon the two other topologies / visions from ONF and ETSI

You may also wish to compare / contrast the NVF MANO panel with the ECOMP (now known as ONAP) architecture suggested by AT&T (below).

From the OSS/BSS perspective, it would appear that not much changes within the triptych… in the early days at least. The clever orchestration and abstraction capabilities that are widely spruiked during SDN / NFV discussions can occur in domains that are virtualised. However, for the next few years at least, CSPs are likely to retain many network devices / domains that aren’t managed by SDN’s control layer or on NFVI (Network Function Virtualisation Infrastructure). For consistent operational management, the legacy domains and the new SDN / NFV managed domains will need to be brought under a single management umbrella, which of course is the OSS/BSS suite.

Having looked through dozens of vendor solutions, it seems that most are building / offering the equivalents of EMS / NMS for the virtualised domains, but are not yet expanding into functionality to support legacy domain or cross domain features. Service catalogue systems are probably the closest to having cross-domain flexibility, but still have a way to go yet to truly managing a CSPs ecosystem.

Whilst this cross-domain gap exists, there remains a place for traditional OSS. Over time though, legacy domains are likely to be replaced with virtual equivalents and vendor management platforms will surely evolve to provide functionality that includes cross-domain orchestration.

A big question for me is whether dedicated OSS modules such as alarm, performance or inventory management tools will have hooks into virtualised networks (just as they do into EMS/NMS today), or whether virtual network management absorbs those functions.

For example, are vendors of alarm management tools worried about disruption by virtualisation, or are they confident that alarm management workflows will remain relatively unchanged and their products will hence continue to retain relevance as stand-alone solutions?

If you want more information about the implications of network virtualisation on OSS (and vice versa), you may be interested in reading PAOSS’s market research report, “The changing landscape of OSS.” It provides a deep-dive analysis of the nascent technologies that are impacting, and impacted by, OSS. The report also provides research into the organisations that are investing in each of these technologies from an OSS perspective