OSS discovers a network

Following yesterday’s post about OSS Inventory, I received another great follow-up question from another avid reader of the PAOSS blog:

Interesting thoughts Ryan! In addition to ‘faults up’, perhaps there is a case also (obvious?) for ‘discovery up’ to capture ongoing non-planned changes? Wondering have you come across any sort of reconciliation / adaptive inventory patterns like this? Workflow based? Autonomous? (Going to far into chaos theory territory ?

Yes, we did exactly that with the same tool discussed yesterday that I used back in 2000. In fact, a very clever dev and I got that company’s first-ever auto-discovery tool working on site (using a product supplied by head-office). Discovering the nodals (ie equipment, cards, ports) was fairly easy. Discovering the connectivity within a domain (we started with SDH) was tricky, but achievable. Auto-discovering cross-domain connectivity (ie DSL circuits through physical, SDH transit, ATM and logical connectivity onto the IP cloud) was much trickier as we needed to find/make linking keys across different data sources.

It was definitely workflow based with a routine-driven back-end. We didn’t just want anything that was discovered to be automatically stuffed into (or removed from) the database (think flapping ports or equipment going down temporarily). It could’ve been automous, but we introduced a manual step to approve any of the discoveries made by each automated discovery iteration.

As you know, modern networks / EMS / VIM (resource managers) are much more discoverable. They need to be for modern orchestration and resilience techniques. I don’t think it would be quite so tricky to stitch circuits together as we’re no longer so circuit-oriented as back in 2000.

However, I’d be fascinated to hear from other readers how much of a problem they have trying to marry up different data sources for discovery purposes. I’d also love to hear whether they’re using fully autonomous discovery or using the manual intervention step for the same reason we were. I imagine most are automating, because orchestration plans just need to make use of whatever resources are being presented by the underlying resource managers in near-real-time.

PS. For those wondering what “discovery” is, it’s shown in the lower grey arrow in this diagram from “Orders down, Faults up

Discovery is the process that allows data to be passed from NMS/EMS/NEs (ie the network or resource managers) directly into the inventory management database. It should be a more reliable and expedient way of sychronising the inventory with the live network. 

The reason for the upper grey arrow is because not all networks have APIs that can be “discovered.” Passive equipment like cable joints and patch-panels don’t have programmatic interfaces. Therefore we need to find other ways to get that data into the Inventory Manager.

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

2 Responses

  1. Hi Ryan,
    Thanks a lot for the detailed answer, that’s impressive to read of a real world example re connectivity discovery across SDH, ATM & IP networks as it’s both the connection oriented side of it (SDH & ATM) and across into the connectionless domain (IP) also. I’ve never been allowed near the SDH world, have only drooled over the diagrams from a distance 😉 I’ve looked into the TMForum modelling side of it though – quite interesting in terms of supporting different needs of connection oriented vs. connectionless out of a common model. I wonder if we’re heading towards vaguely similar territory over in the multi/hybrid cloud world (as compared to telco) in terms of the movement past MPLS (which is kind of connection oriented also) towards SD-WAN, and the ability of B/OSS tools to handle all of that (given the variety of SD-WAN approaches that are emerging). The world certainly keeps turning!

  2. Hi Evan,

    Yes, I’m really intrigued about how much “stitching” of different discovery data streams/sources we’ll have too in the modern cloud, NaaS, SD-WAN world. We know that resources from individual data streams will be served by APIs (as per the Resource Facing Services that NaaS will aggregate). The question is whether the orchestrators will just stitch all the feeds from individual services/APIs together to create a customer service or whether we’ll need stitch data sets together beforehand. For example, connecting cable data from a PNI to a physical port on a DSLAM (sourced from its EMS) before being able to actually connect a customer with a DSL service over that line. What similar sets of data will we need to stitch before service setup in a multi-cloud environment I wonder??

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.