Case study: Transforming Network Management with MarlinDT LNI

For MarlinDT LNI, we want to discover the network documentation from the most accurate source possible: the network itself. A typical network is multi-layered and multi-vendor, as was also the case for this operator:

• Nokia: NFM-T (WS-NOC): WDM network via NBI through SOAP/XML
• Nokia: NFM-P: MPLS network – core network via NBI through SOAP/XML
• Ciena: Ethernet Access Network – no NMS present
• ConnectMaster by VertiGIS: SQL
• Salesforce: Salesforce API
• Ceragon: Microwave Radio Network –
• NetMaster NMS
• Juniper: core MPLS network
• CA Spectrum: Alarm Monitoring – REST/API 

The goal was clear: create the full LNI and PNI network inventory, so the operator could have 1 single-source-of-truth on the network connectivity. From there, MarlinDT can generate more insights into capacity, support the NOC, incident simulation, root cause analysis and … unlock the automation project.

In the preparation phase, we aligned on the project plan, together with the customer. Understanding the existing documentation, the tooling, the processes and … discussing the quality of these sources. We decided to work with several project phases.

First, the “easy part” with our existing Nokia probes. Then, the integration to ConnectMaster from VertiGIS (competition for MarlinDT PNI). Then the CIENA ethernet access network for which no NMS was in place. Followed by the integration with ConnectMaster from VertiGIS (competing solution for MarlinDT PNI).

We start with the first version of the Solution Design document, that supports both the internal alignment at the customer and improves the understanding of the network by the MarlinDT team. Over the course of the project, this Solution Design document will be improved iteratively, to highlight the details that are needed in all following phases.

Phase 1.1: Probing
First, we discover asap the NOKIA equipment by deploying the MarlinDT LNI Nokia probes. As these probes are operational at several operators, we were able to fetch the data through the NMS (WS-NOC) northbound interface (NBI) for the WDM network and NFM-P NBI for the MPLS network. Now MarlinDT has access to all the information like network elements, optical links and channels, service configurations, port usage, capacity, including details such as installed software, serial numbers, part numbers, etc …

Phase 1.2: Stitching
While we have access to all information, these datasets remain unconnected “data islands”: we are not yet sure on the relation between all devices. For example: a device from the IP/MPLS network sends traffic over the WDM network to another device in the IP/MPLS network – but we need to find out how. This is where the Stitching process comes into play. MarlinDT starts with 0% stitching. Here, the MarlinDT team needs the input of the operator (the telecom engineers who deploy and connect this equipment) to make fast progress. Typically the key to unlock the stitching, lies into understanding the naming conventions. However, finding alignment on naming-conventions between a team of telecom experts is more challenging that it looks.

The stitching is a very fast but iterative process. After the first discussion, we create a Solution Design document (to not only align the MarlinDT team, but also to align the customer’s experts). After the first round, MarlinDT stitches a lot of data (increasing % of stitching) and finds tons of data quality challenges – perfectly normal. We showcase these Data Quality issues a dashboard and start monitoring progress. This really gamifies the experience for all involved telecom experts: we need to lower the amount of DQ issues and we need to improve the stitching progress! From this dashboard and list, the iterative process continues.

Phase 1.3: Showtime
From this moment in time: the operator has already access to a wealth of information that can unlock several use-cases in the NOC, improve planned maintenance, improve capacity challenges and more. On top, visualising this network on a map really unlocks tremendous insights.

It’s important to note that MarlinDT doesn’t need perfect data. If that would be the case, you would never need us, right? We’ll help your teams to get better data, fast. We don’t need to fix all DQ issues, but knowing and showing DQ challenges is the progress – by linking it to “discovered” information.

After the core NOKIA network has been probed and stitched, we started looking at the access CIENA network to get an end-to-end view of services. However, there was no NMS present for the Ciena network.

Luckily, MarlinDT has a few options. We started with NETCONF, but as there were still old devices in the network that were not ready for NETCONF, we had to fallback to SNMP. MarlinDT comes with a configurable SNMP probe.

We could start with IP range scanning, or work with a list of network elements. However, as CA-SPECTRUM was the existing alarm collection agent and there was an internal process to always register new network devices in CA-SPECTRUM, we could create the Ciena IP address list as a targeted approach to probe the network. From that list, we probed each device to read the physical configuration and the logical configuration (VLAN setup, Virtual Switches, LAGs, traffic profiles …) through SNMP.

To discover the links between the Ciena devices, we enabled LLDP on the I-NNI ports. The client layers (LAG, VLANs) are then automatically created thanks to the MarlinDT multi-layer tracing engine, based on the configurations in the individual devices. 

At the end of this phase, we have a complete view of the logical network:

• Access Network
• Core Network
• End-to-end view on Services 

ConnectMaster by VertiGIS is the fiber network documentation tool was more than a decade in use at the operator. It contains a wealth of information, our team was able to unlock this data using a direct access to the underlying database with SQL, and stitch it to the LNI information.

In the end, every LNI equipment has a location, sends traffic over fibers in cables in ducts in trenches that have a location.

Now that the PNI information is connected, we can also identify the Single-point-of-failures (SPOF) from the active layers down to the physical layers. Afterall: a circuit could be logically diverse, but it might use 2 fibers from a different cable but in the same trench. So bridging the gap to PNI is really needed to unlock true SPOF improvements.

What’s the difference in using MarlinDT PNI over ConnectMaster? The main benefit of MarlinDT PNI + LNI is the two way integration: give access from the PNI towards the LNI and vica-versa. Ofcourse, MarlinDT PNI brings a wealth of extra use-cases like the Design Sessions, the Workflows, the Web & Mobile access. But in the end, to unlock SPOF over the physical layer – we don’t need MarlinDT PNI per se.

As we reached this pivotal moment, we unlocked the potential to integrate even more dynamic data into the Digital Twin of MarlinDT, including Juniper, Ceragon, Salesforce, and the CA Spectrum Alarms.