MANO-a-MANO OSS DNA

“The king is dead, long live the king!”

Management and Orchestration (MANO) is one of the key components of ETSI’s NFV specifications. Some believe it and other cloud management approaches will spell the death of OSS as we know it (although NFV topology diagrams show the NFV Orchestrator connecting to higher-order B/OSS).

After all, it will likely revolutionise the management and orchestration of “cloud” resources of such as compute, networking, storage and security as well as the virtual machines (VMs) upon which they reside.

But I can’t help but thinking that a lot of OSS DNA will still propagate into the management frameworks of the future. For example, if we go back to FCAPS – we’ll still need to monitor and manage faults, performance, inventory, security, etc and in each case we may wish to aggregate that management from multiple different platforms, especially if we still have legacy networks / tools in our estate.

Then looking further northbound, we may have service catalogues implemented for virtualised environments, but they’ll still need processes / workflows that are adapted for each customer’s way of doing business (eg approvals, hand-offs, decision points, business unit responsibilities, equipment life-cycle management, etc).

And each service change will hopefully have a higher level of automation than current management systems, but to fulfil a service there will still be some work orders / activities that can’t be automated. These include activities such as building customer lead-in cables, network / capacity upgrades, gaining permits to work, cross domain interconnect, cross jurisdiction interconnect and more.

The pundits may be right and we may no longer refer to OSS in the future, but a lot of its DNA will propagate forth into generations to come.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

No telco wants to buy an OSS/BSS

When you’re a senior exec in a telco and you’ve been made responsible for allocating resources, it’s unlikely that you ever think, “gee, we really

4 Responses

  1. Hi Ryan,
    I think you’ve hit the nail on the head re comments in your fourth paragraph – you’ve already covered quite a lot of ground there, but what if we throw in the Billing domain for good measure also?! Do you happen to know yet whether MANO supports any form of (hopefully standardised) external inventory / billing APIs? (Sorry I need to catch up a bit!)

  2. Hi Evan,
    This article from the IETF 89 (March 2014) is the best diagram I’ve seen to date regarding NFV’s MANO. See slide 8 from the following link:
    http://www.ietf.org/proceedings/89/slides/slides-89-opsawg-7.pdf
    As it indicates, this is still a work in progress.

    CloudNFV is a multi-vendor PoC to test the SDN / NFV frameworks on existing products. I think figure 6 on page 7 of the following shows the best example I’ve seen yet for describing the interfaces between NFV / MANO and OSS/BSS:
    http://www.cloudnfv.com/WhitePaper.pdf

  3. Hi Ryan,
    Thanks that’s much appreciated – it looks like the IETF are planning a rich set of interfaces, it will be very interesting to follow their progress on the detailed data model around their service/graph/link/physical network record items. The CloudNFV effort was a new one for me – quite interesting they seem to be looking up through most OSS layers including some detail on RFS/CFS implementation (they’re taking activation seriously!)

  4. Hi Evan,

    Yes, it’s always interested to view the practical efforts like CloudNFV for their ability to crash through (or not) any hurdles represented by the standards. 🙂

    Rgds
    Ryan

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.