Getting Closer to the Network (Explained)

The biggest impact on automation and digital transformation? Maintaining network inventory. For service providers, keeping an eye on what’s in the network can quickly become overwhelming and tedious. It becomes even more cumbersome when the layer of requirements for service layer inventory and logical configuration attribution are factored in.

If relied upon, traditional Operations Support System (OSS) inventory platforms using manual, static, and inaccurate approaches are sure to sink. For those network operators today that aspire to automate service delivery and assurance, accomplish cross-domain topology and correlation, have an accurate understanding of actual capacity, and make these network automations available to the customer through self-serve enablement – your inventory better be “spot on.” Beyond the impact to automation as described, the idea of running an operation where the underlying assets used to drive revenue are unknown or wrong should be unthinkable.

The foundation to bring network and system integration together in a way that enables all of the Network-as-a-Service (NaaS) automation use cases is that of real-time network discovery of both resource and service inventories. This is no trivial task as the commitment to this level of automation has to account for the depth and breadth of a service provider’s network that reflects multi-vendor, multi-generation, and multi-technology. Across these disparate environments, the command-and-control protocols are vast and the nature of the communications over these protocols are never the same by network element and related software releases.

How is this accomplished? Discovery engines are required to “marry-up” to all of these disparate network elements, technologies, variations of protocol/communication, and OS-versioning. This centrally deployed discovery function is not only required for the first network element connection but also able to catch any change that occurs thereafter for both physical and logical changes to the network and associated services. All of this collected data must reside in a datastore that can be accessed via an open/extensible interface (API/Services) to allow other consuming applications to receive bulk requests as custom-defined and any related changes that occur.

Once accomplished, real-time (discovered) inventory becomes the foundation for “the truth” of what actually exists in the network, what is the actual service path and topology, the “bridge” between the network and consuming applications, and the enabler for automation that will change the operator and end-customer experience.

Authored by →

Travis Ewert