Blogs

How to prepare for Intent-based networking with Anuta ATOM

How to prepare for Intent-based networking with Anuta ATOM

Get Closer to Intent-Based Networking with ATOM and Realize its Most Extreme and Extraordinary Possibilities

In a recent blog, we defined Intent-Based Networking or IBN, fathomed the different components of IBN, and, then, took a sneak peek into how IBN gets realized by using the components involved therein.

In this blog, let us expand our understanding and acumen on how IBN shines when applied in smart synergy with Anuta Networks platform ATOM.

ATOM, as you would already be familiar with, is a multi-dimensional product that is designed for and is strongly capable of integrating different aspects of network management, including Configuration Management, Compliance Management, Analytics & Telemetry, and Automated Service Assurance.

Within ATOM, IBN gets realized in multiple ways. Let us look at how different scenarios and outcomes flourish within ATOM. Let us see how we can realize the business intent and, still, continuously align the end-to-end network with that intent. Yes, now it is finally possible to bridge that proverbial gap between business and IT.

Intent-based networking is all about approaching it step-by-step and paving the path with rigor, vision, and structure.

IBN in ATOM
Intent-based networking with ATOM

Network Intent with ATOM

Let us begin with the first foot forward. The abstract language available from the business intent translates into network language at this layer. This layer primarily focuses on network feedback. In ATOM, this layer belongs to the higher-level edifices of Configuration Management, Compliance Management, Analytics & Telemetry, and Automated Service Assurance. ATOM takes the business level intent, maps it to an appropriate element, and spurs the intent realization further down the layers.

In ATOM, a large portion of raw data gets ingested from disparate sources such as Streaming telemetry, SNMP, SNMP traps & Syslog. This raw data is processed, normalized, and compared against thresholds that have been defined to deliver the insights expected in the business intent. The data from the network stored in ATOM’s time-series database, allows ATOM to deliver real-time & historical data. This data can, then, be represented on a dashboard or fed back into other modules of ATOM for further action.

For example, a business-intent of ‘expecting uninterrupted service levels for an HD video call’ is translated into a network-intent in ATOM to monitor the network to ensure three key areas: device availability, the interface utilization across the path and the right QoS for the application. It could also translate into the task of checking any misconfigurations or drift from expected golden configurations on the devices to nimbly trigger remediation action using ATOM.

Network Policy with ATOM

Organizations are required to follow a set of regulatory guidelines based on their industry vertical. These are defined by policies such as HIPAA, SOX, PCI, and other apt regulatory frameworks. While business intent is important for an organization, business policies control the extent of the intent so that the overall business is not affected. Within ATOM, a sound network policy defines these limits for the business intent. The network policy layer is powered by ATOM’s compliance management, which functions as a higher-level force in this layer.  For example, in the business intent above, the requirement is to provide HD quality video calling. But there could be other critical applications using the network. The business policy needs to ensure that the network resources are optimally available to all the applications. The network policy layer in ATOM takes this business policy ahead and ensures resource availability using compliance management.

Intent Realization with ATOM

Having traversed the previous layers as described so far, we can now evolve into the ultimate levels. Deemed as the most important part of IBN, Intent realization is where all the action happens. The “how” part of Intent-based networking is navigated in multiple ways within ATOM. The below-mentioned aspects are some of the established ways of handling this complexity using ATOM.

Service Models – Powered by YANG and OpenConfig, some use-cases that need lifecycle management of services are realized splendidly through ATOM’s service modeling capability. ATOM offers many out-of-box service models for immediate consumption. We know business intent can trigger the existing models. But the complexity lurks in the challenges that multi-vendor infrastructure poses. Here is where ATOM’s Service models deliver the much-needed abstraction with ease. ATOM triggers the device models underneath to ensure hassle-free provisioning of devices irrespective of the access type that any device supports. It could be over CLI, API, or NETCONF. As to our example cited above – of ensuring HD quality video – service models in ATOM can provision devices in the network path to ensure the required QoS & DSCP markings for the video application and retire them once the application usage is over- thus ensuring bandwidth availability for other applications.

Workflow automation – Driven by BPMN 2.0, ATOM’s workflow automation is an essential part of IBN. While the visual element is a huge benefit that it brings to the table, what makes ATOM special is its innate flexibility and adaptability for multiple scenarios. Its ability to tie different aspects of the provisioning, compliance, and monitoring together – that is what makes it an interesting part of Intent-Based Networking Solution (IBNS). From a provisioning standpoint, it can trigger ATOM’s service models by adding pre-checks and post-checks to the mix, device models, and network devices directly through raw CLIs or APIs.

    The network intent, once realized, can start a good domino-dance to the corresponding workflow to execute the intent. ATOM offers several radical workflows to address real-world  scenarios in today’s networks. ATOM also supports programming languages such as Python, JavaScript & Groovy to aid in the customization of workflows. For example, when the  business intent is to have HD quality video calls and network intent is to ensure the right QoS for the application, the corresponding workflow in ATOM is triggered smartly. The workflow will first confirm if the requirements are met using the pre-checks, else will provision the necessary QoS and DSCP markings, and run through a set of post-checks across the  network path to ensure resource-availability.

    Monitoring, Alerting & Notification – Intent-based networking can never materialize to the core without effective feedback from the network. While not directly part of the provisioning exercise, ATOM’s notification engine plays an important role in the ‘how’ part of IBN. This function of ATOM helps to strongly, and seamlessly, uphold the intent.

    ATOM’s round-the-clock monitoring system takes the network intent and dissects all those tones of feedback collected in the form of raw data from the network from multiple datasets such as SNMP, Streaming Telemetry, SNMP traps, Syslog, and IPSLA data. The collected data is normalized and made available in Apache Kafka, and time-series databases for any   external IBNS or related post-processing tools. This processed data feeds into ATOM’s Closed Loop Automation framework, which forms the basis of alert definitions. ATOM’s Monitoring, Alerting & Notification engines thus become part of a layer called as Intent-based Analytics (IBA). It helps in an unprecedented way to make network decisions well-pronounced.  
     
    In our example of having an HD video call, where the network intent was to ensure QoS and high availability, the Intent-based analytics can collect real-time information from the network and if the path fails to ensure the required QoS, the required information can be made available to systems through ATOM’s analytics capabilities to take remediation actions. The intent is, thus, always and meticulously maintained

    Closed-Loop Automation – When the intent is to achieve a business goal, the scenario calls for a system that is capable of ensuring the maintenance of intent at all times. Here is where ATOM’s Closed-Loop Automation comes into play. In the Monitoring, Alerting & Notification parts, we saw how ATOM could ingest the feedback from the network. With Closed-Loop Automation in ATOM, a group of alerting-conditions can be articulated and compared against the processed information from the monitoring entity.

    The conditions will, primarily, be threshold-values set for achieving or maintaining intent. When the framework detects any breach in the threshold or intent, ATOM can trigger remediation-actions through auto-remediation or by triggering the workflows with in-built approval chains. In our example, where one of the paths fails to ensure the required availability, ATOM’s Closed-Loop Automation can trigger remediation-actions to reconfigure the network enabling it to maintain the network intent of providing high-availability and QoS for the application.

    Compliance Management – ATOM’s Compliance Management helps to realize the Network policy mentioned above. Compliance should be enforced at both service and device levels. For example, if the HD video call is to happen from 8 AM to 8 PM, the configuration compliance can be scheduled in such a manner that at 8 PM, all necessary configurations are pushed to the network to tone down the QoS for video calls to accommodate other business applications thus bolstering the entire chain for realizing the business policy