How virtualisation has changed the rules for network inventory

Back in the days when I first started working on OSS/BSS projects (the year 2000), I fell in love first with network inventory solutions. I loved being able to pick through all the data coming from various different inventory data sources (mostly element management systems, direct from devices and east-west systems such as service order management and address / number management tools)

Those were the days when PDH, SDH and ATM still dominated carrier networks. Those were also the days when everything was nailed up. Because of that it was possible to manually correlate data sets together, even ones that crossed domains. It still wasn’t easy and often took careful manipulation of linking keys between data sources, but it was fun to perform the detective work and piece all of the clues together. Then, to take the patterns and codify them into multi-domain data discovery and stitching engines. Very cool stuff!

This has become distinctly more challenging in modern times though, in part because the linkages between data sets are changing far more frequently now. We’ve been through the following three (very loosely defined) eras of networks under management since then:

This has corresponded to three totally different ways that network inventory solutions needed to operate.

In era number one, it was reasonable for inventory solutions to record the current state of the network because it was largely nailed up, with not much flux occurring in data sets other than typical client-driven moves / adds / changes / deletes (MACD). Traffic was carried from source to destination via pre-defined routes (albeit often with protection paths in case the primary path failed).

To be honest the definition of eras is probably a bit sketchy because we were already seeing significant packet switching (eg Ethernet / IP) in carrier networks even by 2000. Packets could be routed in many different paths and inventory solutions (and the data infrastructure that underpinned them) simply weren’t fast enough to permanently track pathways through the network. We simply had to model the packet-switched parts of the network as clouds and define a logical pathway from ingress-to-egress points on the packet-switched part of the network. But at least the network nodes were physical (PNFs – or physical network functions), so they didn’t undergo many changes.

The next iteration of network, software defined or virtualised networks, added an extra layer of complexity and dynamism. Now it wasn’t just the connections that were changing dynamically, but the nodes were too. It introduced the concept of virtual network functions (VNFs). These could be instantiated on demand, or turned down again just as quickly. Not only were network nodes now transient, but they still needed to be tied to physical infrastructure (if hosted on managed devices) and/or cloud infrastructure (if hosted on physical infrastructure owned by others and offered as a hosted service).

We’re arguably starting to fork from SDN (Software-defined networks) into the next era of networks under management that causes even greater challenges for traditional network inventory solutions. That is, networks such as 5G that allow for network slicing, where operators can carve out resources to form separate private network layers with different characteristics running over common infrastructure. Each slice can either support a cohort of customers or even individual customers. This presents some unique challenges for network inventory solutions to overcome, which will become an important differentiator if the network slicing trend continues to take hold in coming years.

It will be fascinating to watch how network inventory vendors step up to handle these next layers of abstraction and complexity.