Intent-Based Networking for the Enterprise: A Modern Network Architecture

Over the past decade, many industries have undergone digital transformations, where digital technology is used to create fundamental changes. Well-known examples include Netflix for content delivery, Amazon for e-commerce and cloud computing, and Uber for mobility services. While many enterprises already critically depend on their networks to achieve their daily goals, networking has not yet gone through a similar digital transformation. Current technological advances, however, provide great promise for accelerating enterprise digital transformation to support emerging applications, such as augmented reality/virtual reality (AR/VR) or an ever-increasing list of Internet of Things (IoT) applications and devices.

Back to Top

In this article, we focus on enterprise networks. Enterprises that have networks include businesses, schools, hospitals, retail, airports, manufacturing, utilities, and defense. Enterprise networks differ from the Internet in a number of fundamental ways, including: there are enterprise management applications for the entire enterprise network; the enterprise knows its most important applications and wants to gather estimates of enterprise health in order to optimize performance and economics; security threats continuously increase as attackers try to extract value from the enterprise; many users connect via Wi-Fi, often via personal devices (mobile, laptop, or IoT), which should be considered part of the enterprise network for the purpose of optimizing user experience and security; and important trade-offs are often necessary to meet constraints and changing business requirements, which requires human judgment but prevents full automation. While research efforts to improve the Internet have spanned decades, including Feamster and Rexford,⁸ the research community has also realized there is a gap, and greater focus on enterprise networks is needed.

For today’s enterprise networks (see sidebar: What Is an Enterprise Network?), several challenges exist that limit an enterprise’s capabilities, including:

• Changing a network quickly to meet new application or service requirements. The ability to automate frequent changes to a network has significantly improved with software-defined networking (SDN). However, SDN has been focused on the feedforward part of the network operation, which needs to be extended to include better feedback capabilities to also address the next challenge.
• Identifying network problems and associated solutions and ensuring that the network operates as needed. Traditional solutions to networking problems—such as collecting data from network devices and relying on operator expertise and multiple tools to determine root causes and appropriate actions—do not scale to today’s large and complex networks. New approaches are needed to provide the desired speed of root-cause analysis and problem resolution.
• Minimizing security vulnerabilities and quickly detecting, identifying, and remediating security threats when they occur. Enterprise networks are getting more complex as a greater number and diversity of devices are connected to the network, leading to potential security vulnerabilities.

To address these challenges, and to make the network an enabler for the enterprise’s desired digital transformation, the networking community is developing a new architectural approach referred to as intent-based networking (IBN).¹⁸ IBN builds on the concepts of SDN but introduces new advances to better align an enterprise’s intent with network operation. Examples of an enterprise operator’s intent, such as “video conferencing is business critical” or “traffic from IoT devices should be virtually separated from engineering databases,” are abstracted in an IBN to enhance alignment to the enterprise’s business goals. Abstracted expressions of intent are translated into associated network and security policies authored by network and security experts,²⁹ devoid of any details of specific network elements. Rather, network automation—analogous to SDN—determines if a desired policy can be instantiated onto the network and derives the preferred instantiation. Intelligent automation in IBN promises dramatic speed and agility improvements to add new services or change operations. The addition of a near real-time feedback loop enables continuous monitoring, optimization, and assurance that the network is indeed operating as intended by enabling automated checks and identifying recommended fixes. Achieving the aforementioned intelligent behavior involves applying a diverse set of algorithmic approaches, such as machine learning (ML) for anomaly detection and prediction, machine reasoning (MR) for root-cause analysis, and context-dependent natural language processing (NLP) to convert human-expressed goals to machine-understandable goals.

Significant information on IBN is available in networking trade publications, networking vendor literature, and growing efforts in IEEE and IETF standards bodies.^11,26 The goal of this article is to define what enterprise networks are and the challenges they need to overcome, motivating the need for IBN and presenting a conceptual overview of the IBN architecture that can be understood by a broad technical audience. We also highlight various research opportunities for future improvements. IBN is a north star goal, and the networking community is in its early years; the first phase of IBN networks is being deployed and important knowledge is being gathered.

Back to Top

Running an Enterprise Network Today Is Challenging

For many enterprises, designing and running a modern network poses significant challenges:

Architectural complexities. Enterprise networks are very diverse in nature—for example, different vendor equipment; software versions; or network designs in branches, campuses, or DCs. Scalability is an increasing challenge for operators as the number of branches, devices, and applications rises. Devices connecting to the network are becoming more diverse with varying network (for example, TCP/IP) capabilities, providing the flexibility and performance required for applications to be hosted in the enterprise DC or the cloud.

Rigid network element-centric operations. Changing a network to align with changing business intent is challenging, especially in traditional cases of device-by-device management. Network engineers must derive an appropriate configuration for each network element on the path to the application, taking the network architecture, software versions, and hardware specifics into account. Many times, this requires extensive operations-team experience about specific device capabilities, command-line syntax, and software functionality. Many operations teams lack sophisticated controller-based automation capabilities; they instead rely on home-grown configurations and scripts that are complex to maintain and are common sources of errors.

Difficult to troubleshoot. Detecting and correcting problems in today’s networks is challenging and time consuming. Network engineers need to gather data, possibly from many places in the network, which often comes in disparate formats or may not cover the time window in which the error occurred. With sufficient expertise, the data can be analyzed and correlated to provide some understanding into the network’s current state. Fixing errors may also cause network disruptions that need to be limited.

Changing security perimeters. Traditional enterprise networks formed a well-defined security perimeter by allowing only wired access to the network, hosting applications in a protected enterprise DC, and limiting Internet access to a few locations. In a modern enterprise network, attacks may originate from anywhere, including from increasingly diverse devices (mobiles, wearables, IoT), branches directly connected to the Internet over an SD-WAN, or applications consumed from the cloud. Security teams are challenged to keep up with growing and adapting attack profiles, understand the network’s security exposure, and maintain protection policies to quickly detect, identify, and remediate attacks.

These challenges contribute to current enterprise network architectures being complex and error prone, slow to change or to deliver new connectivity services, vulnerable to attacks, and costly to run—in short, not fit to effectively support modern business operations.²⁷

Back to Top

Requirements for an Enterprise IBN

Today’s enterprise network architectures and their operational procedures need to evolve. A network architecture supporting modern business operations should be:

• Flexible, to allow for fast changes as business objectives evolve.
• Easy to configure, operate, and maintain using programming and automation.
• Scalable, to support increasing numbers of endpoints and locations.
• Able to provide global visibility across the network, with relevant insights into its state and operations (including metrics on how business objectives are being met).
• Compliant with corporate and regulatory standards.
• Secure, by identifying and remediating threats before they cause harm.

Back to Top

Intent-Based Network Architecture

An intent-based network¹¹ architecture differs from a traditional enterprise network architecture by providing several mechanisms and functions that align the network with the goals—the intent—of the enterprise. Conceptually, an IBN architecture adds three functions to a network architecture (Figure 2¹¹).

Figure 2. Overview of the four conceptual components of an intent-based network.

First, translation enables an intent expressed in abstract, human-understandable terms to be translated into network and security policies. This allows better alignment of network operations with enterprise business intent and allows operators to focus on outcomes expected from the network (the ‘what’). Second, activation^a helps to quickly achieve the expressed intent by offering sophisticated automation capabilities to programmatically configure the network. Third, assurance incorporates telemetry data collection and closed-loop feedback to continuously provide visibility and insights into network operations and to verify that the expressed intent is indeed met.

Combining programmatic network configurations with continuously collected analytics data has already been proposed by academia in the context of self-driving networks.⁸ An IBN adapts the notion of self-driving networks expressed in Feamster and Rexford⁸ to an enterprise networking context and expands it with the additional focus on the translation function. IBNs improve on SDN^8,14 with both the translation and assurance functions.

Intent translation. The intent translation function offers capabilities to characterize intent in abstract form, allowing for simple formulations that describe expected network communication services from an operational perspective.^12,17 For example, an intent “Application X is business critical” expresses how the network should treat Application X, and implicitly, the endpoints it communicates with. The expressed intent describes what the desired outcome should be, not how it should be achieved by the network or how network elements should be programmed. Note that the intent drives both the activation and assurance functions; the arrows in Figure 2 show the order of operations and emphasize the closed-loop feedback.

---

While many enterprises already critically depend on their networks to achieve their daily goals, networking has not yet gone through a similar digital transformation.

---

A more specific example of abstracted intent expression is “Printers and scanners can only communicate with email servers.” This can be translated into the following network and security policies:

1. Group printers and scanners into group ‘PrinterGroup’ and assign email servers to group ‘EmailServerGroup’.
2. Create a policy to allow ‘Printer-Group’ to communicate with ‘EmailServerGroup’.
3. Create a policy to deny ‘Printer-Group’ to communicate with any other endpoint groups.
4. Monitor traffic to and from the ‘PrinterGroup’ to ensure that the policy is adhered to by the network.
5. Flag any policy violations to the operator.

This translated intent can be further decomposed into more granular network and security policies.

The expressed intent is a function of who authors it. IT operations teams define the intent of devices, end users, and applications and their relationships. Network operations teams may express intent for the network infrastructure itself, such as, “All network elements must run certified software images.” The latter expression again defines a desired outcome in abstracted, simple terms, without reference to hardware device specifics or software versions.¹⁰

The intent is typically transformed into a model-based policy in an IBN system.^4,15,24,28 Such a conversion allows the translation function to homogenize different expressions of intent and to verify that the expressed intent can indeed be realized by the system. Policy targets (for example, groups of endpoints, applications) can be identified, and so can desired outcomes that are standardized to what the IBN system understands—for example, ‘critical application’. Homogenized, model-based policies that have been expressed at different times or by different operators can also be validated for consistency,²⁰ for example by employing graph theory.²³

Intent activation. The model-based intent is then refined by the activation function to derive network element configurations and to program them into the network elements.² This operation is analogous to converting a customer-facing service model into a resource-facing service model.³²

Conceptually, the activation function is tightly coupled with a network controller in a SDN. A key characteristic of a network controller is that it has a view of all network elements under its governance as well as how they are connected to form topology from a layer 1 (physical), layer 2 (medium access control or MAC), or layer 3 (Internet protocol or IP) perspective. A network controller is fully aware of device specifics, such as hardware and software versions, device capabilities, and existing device configurations. An IBN controller can thus take the abstracted policy model and derive device-specific configurations. It also takes the derived configurations and programs the relevant network elements—for example, using Netconf/Yang.

Note that at this point, the network elements execute forwarding, filtering, and security functions based on specific configurations—the same way as before. The key difference in an IBN is that these configurations are derived from (and thus align with) an expressed intent using a well-defined sequence of automated transformations, and these configurations are applied to the network as a whole.

Intent assurance. Assurance is a powerful and relatively new capability for networks. The assurance function continuously collects and monitors operational information from network elements and connected devices and applies intelligent algorithms to assess whether the desired intent is achieved.

The data collected may provide other benefits. For example, the daily average bandwidth usage of an interface may be helpful for long-term capacity or architecture-evolution planning. Data collected by a network element may be stored in the device and possibly pre-processed or compressed for efficient extraction. Many benefits of an IBN require participating devices to have sufficient storage and compute to collect and process the data.

Deriving a meaningful understanding of the network state requires extracting data from network elements; end devices; and related functions, including authentication servers, URL resolution functions such as the domain name system (DNS), or IP address allocation functions such as the dynamic host configuration protocol (DHCP). Some network elements may already support automatic, event-based extraction to an assurance function (streaming telemetry) while others may still require an assurance function to periodically issue a poll request for data. Extracted data is gathered from multiple sources into a collector that may co-reside with the network controller.

Data collected from different network elements or devices may be potentially huge in scale and diversity, requiring application of modern data analytics techniques and systems. Data from different sources is normalized so that it can be compared and analyzed across the network. Metadata is also associated with the collected information—for example, the time window and specific CPU core for which a utilization statistic is calculated.

An IBN system also offers remedial insights and recommended actions in case discrepancies arise between actual and desired states.³² For example, if the intent of a business-critical application is violated at a certain network element by other network traffic, assurance algorithms may suggest rerouting traffic around the bottleneck or reclassifying less-important traffic to free up bandwidth. The IBN assurance function could be automated so that specific classes of intent violations can be automatically remediated with pre-approved fixes.

The algorithms applied by intent assurance vary based on the type of intent that is being assured. Time-series analysis of single variables may be applied to determine longer-term trends of device- or bandwidth-utilization levels. Correlations between network data variables may provide the operator with deeper knowledge. Various forms of data analytics, ML, MR, or AI algorithms may be applied as part of intent assurance to gain insights into previously unknown trends or to make complex predictions. Key goals in applying these techniques are to gather operational insights, detect problems, and perform root-cause analysis and identify recommended fixes.

The accompanying table compares traditional enterprise network architectures and operations with the opportunities provided by an intent-based network architecture. Note that a migration to an IBN architecture from a traditional one is typically phased; incremental upgrades start with the portions of the network where IBN’s benefits would be most valuable. In the first phase, operators can introduce IBN-ready controllers into the network to achieve a consistent programmatic configuration for a set of network elements while retaining the traditional CLI-based configuration. In a second phase, such networks could then evolve to replace CLI-based operations with intent-based operations, where network element configurations are derived and assured by the IBN. Furthermore, because enterprises typically upgrade their infrastructure in phases, a portion of a network will often be IBN-capable while the remainder may not be—for example, due to older equipment or lack of support for the needed APIs or other capabilities. In this case, the non-IBN-capable portion of the network will support limited visibility, automation, and assurance. In some cases, this may partly be overcome by performing these functions on the boundary of this non-IBN part of the network. For example, treat the non-IBN-capable subset of the network roughly as a black box, where only inputs/outputs at the boundary provide more fine-grained visibility and other capabilities.

Table. Comparing a traditional network with an intent-based network. An IBN architecture provides the potential for significant improvements.

Back to Top

Applying Intelligence to Improve IBN

A key aspect of IBN architectures is the application of algorithmic and data-driven intelligence to improve performance, reliability, and security. AI/ML approaches have already been applied to traditional and SDN networks.^1,35 In an IBN, such AI algorithms (see the sidebar “AI for Networking”) are applied in each IBN function and are especially valuable for the translation from intent to network policy, optimization for automation, and assurance to enhance the closed-loop feedback.

In the translation function, they are responsible for:

• Domain-specific speech recognition and NLP
• Translating human-expressed intent into network and security policies by leveraging knowledge bases and other contextual information

In the activation function, they:

• Relate policies to real-time and historical data about network behavior to assess if a policy falls in the baselined ‘normal’ network behavior and flag exceptions to the operator otherwise
• Predict and optimize network performance (for example, available bandwidth, latency, and packet loss) across each of the multiple available paths and select the best one to use for each application flow

In the assurance function, the application of ML/MR allows the system to:

• Sift through massive amounts of data from across the network to gain insights, identify performance improvements, and detect problems
• Create behavioral network baselines to improve anomaly-prediction accuracy, a historically challenging problem since false positives erode user trust
• Learn patterns of problems and solutions from historical data to predict causes and fixes
• Leverage expert knowledge bases to determine root causes and associated fixes for identified problems

Massive advances in algorithms and compute, as well as a fundamental network infrastructure redesign, enable the application of these ML/MR algorithms. The IBN network can provide vast amounts of highly diverse data due to purpose-built support in network-element application-specific integrated circuits (ASICs), operating systems, controllers, network data platforms, and design of network-customized AI algorithms. Preventing or remediating network problems requires the efficient and timely aggregation and processing of the data. Figure 3 illustrates the effectiveness of applying assurance algorithms (internal study of 11 customers over a three-month period) to prioritize the huge number of incoming alerts into a much smaller number of prioritized alerts to be examined by the operator.³³ A variety of techniques are used to achieve this goal. For example, the normal operation (baseline) of each network is identified, where this is a dynamic baseline that varies over time based on the context—load, number of devices, specific types of mobile devices, and so on. Using customized and dynamic baselines can dramatically improve the accuracy of distinguishing between abnormal and normal (given the context) behavior (see Figure 3). Furthermore, since the detected abnormal events will impact productivity differently, they are then prioritized based on their significance. For example, every onboarding issue is important because it prevents a user from using the network. However, of the issues impacting throughput, some will greatly impact productivity while others may have a minor or even imperceptible impact. This prioritization is highly beneficial for focusing the operator’s attention on the events that are most important to address.

Figure 3. Application of various forms of ML/MR can dramatically reduce the number of alerts. In this case, for wireless (Wi-Fi) networks, 8,000 alerts from traditional statistical models are reduced to 92 prioritized alerts.

To help quickly and accurately detect and solve a problem, we also gather additional data or points of view where possible. For example, if a mobile device has problems connecting to a Wi-Fi network, a conventional network controller would gather the data from the access point (AP) to help identify the problem. Through our work with device manufacturers, (for example, Samsung) we also receive wireless assurance data from Samsung mobile devices, which provide complimentary data and views. Specifically, gathering both the AP’s and the device’s view of a problem can greatly assist in correctly identifying not only the root cause of a problem but also a solution. For example, the AP may not know why a mobile device is frequently disconnecting, but the mobile device knows.

As an example, Figure 4 shows how to resolve wireless onboarding issues in a European retail chain with more than 5,000 stores and over 90,000 employees.⁷ In this case, the wireless endpoints, APs, wireless LAN controller, and all other network components are continuously monitored. Wireless client onboarding times are tracked and fed into an ML algorithm to predict the range of expected onboarding success probabilities, as a function of time and context. Actual onboarding times are then compared against the predicted range and flagged if they fall outside the predicted range. The analytics engine correlates other events—for example, EAP timeouts and AAA failures—to the same timeframe. The example illustrates that at timestamp 13:30 on January 14, 2020, 18.03% of clients failed to onboard, when the expected experience is between 0.13% and 10.58% of clients. During the same timeframe, no AAA issues were detected, but eight counts of EAP timeouts were registered, thus pointing to the cause of the failed onboarding events. Note that onboarding failures that fall within the range predicted by the AI algorithm due to normal stochastic client behavior may not be flagged for further investigation by the operator. Therefore, ML/MR help to establish customized, behavioral baselines for normal network operations and extract and correlate relevant events from thousands of data points that are continuously monitored to identify relevant and prioritized problems that the operator should examine.

Figure 4. Dynamic baselining predicts expected network behavior (top, green curve). Comparing against actual behavior (blue line) identifies unexpected behavior (red time interval). Correlating across attributes (second and third graphs) points to the problem (second graph).⁷

AI thus amplifies the capabilities of IBN: It accelerates the path from user intent into translation and activation and examines network and behavioral data in the assurance step to ensure everything is working correctly. Activation uses insights from the feedback loop to drive more intelligent actions for improved performance, reliability, and security, creating a virtuous cycle of network optimization. Prior architectures, such as SDN, primarily only had the feedforward path of automation. The feedback loop in IBN is foundational for providing many of the benefits.

Back to Top

Example of IBN Application Prioritization

Consider the case of a video-conferencing application. The IT operator classifies the application ‘Video conferencing’ as ‘business critical’ using a GUI. Intent translation takes this expression and transforms it into an internal policy model. The policy model is checked for conflicts against currently deployed policies—for example, Prakash et al.²³, as illustrated in Figure 5. Any identified inconsistencies are raised to the operator for further action.

Figure 5. A new policy is checked for potential conflicts with existing policies before applying to the network.

The IBN controller subsequently transforms the policy model into device-specific configurations. The new application policy may affect other traffic. For example, to accommodate the video-conferencing application, bandwidth to the ‘videoconferencing’ class may be increased while bandwidth for the ‘low-latency’ class is decreased. The controller could warn the operator of potential experience degradations for other applications.

---

Current enterprise network architectures are complex and error prone, slow to change, vulnerable to attacks, and costly to run.

---

The controller then programs the derived configurations into the relevant network elements and reports the outcome back to the operator. In case of a failure, the controller can perform a rollback and abort updates in all other network elements, reverting the network back to its state before the policy update.

Successfully instantiated policies are continuously monitored. The intent assurance function gathers QoE statistics from the video endpoints (via APIs to generate an expression of application health), traces the travel of packets end-to-end, or even runs packet probes against the video-conferencing application to measure the network’s perception of application QoE. The network operator could be alerted about issues, including providing observed data describing the issue, the hypothesized root cause, and recommended fix, and could offer the option to intervene or even allow the IBN system to self-correct the issue.

Back to Top

Future Opportunities

The vision of IBNs described above is currently an area of significant research and investment by the networking community. A number of challenges must be resolved before IBN can reach its full potential.

First, end-to-end, user-to-application policies may be hard to achieve if enterprise network operations are in traditionally separate domain silos (for example, campus wired/wireless, WAN, data center, cloud) that use different processes, controllers, or tool stacks. While each domain can still benefit from IBN within its scope, realizing end-to-end, user-to-application intent may be best achieved with a holistic view across the network. This motivates “cross-domain” visibility, automation, and assurance functions to coordinate expressed intent across a multi-domain (or multi-operator) environment. A related use case involves orchestrating an end-to-end intent across an enterprise network and one or more service provider networks. For example, an important aspect of the 3GPP 5G core network architecture that service providers are embracing is to provide API-driven programmable network capabilities, which can enable an enterprise to manage its own network as well as its service provider’s network (which it pays to use) to deliver on its enterprise use cases.

Furthermore, achieving the aforementioned end-to-end policies also requires accommodating opaque network regions—parts of the network that do not support IBN functions, such as providing analytics data or supporting controller-based automation. Mechanisms such as black-box probing could be applied to infer input-output characteristics and analytics data. And the surrounding IBN-controlled regions can compensate for the behavior of the opaque (uncontrolled) region.

Second, offering user-friendly intent-authoring environments and more general intent translation is an ongoing research area. Currently, graphic user interfaces (GUIs) providing a predetermined list of intents represent the predominate usage model. Capturing intent expressed in free-form spoken words or text requires domain-specific speech recognition and NLP. One challenge is that a policy’s structure is not unique; a policy does not have a single template, as it depends on the context—for example, deployment scenario. One option is to use a library of customer-generated policies to understand the range of potential structures for each policy type and create an associated knowledge base. Then, given an identified policy request and the associated range of structures for that policy, a chatbot can have a conversational dialog with the operator to identify and fill in any missing or ambiguous attributes. A related opportunity is the development of an intent-language syntax with well-defined keywords to describe policy scope, actions, and targets. Another approach is inferring intent from network and user meta-data.²¹ These are promising areas of research.

Third, the competency of conflict-resolution engines is key for an IBN. While the expressions of intent in abstract terms may simplify network operations and alignment with business goals, they could also introduce ambiguity and result in conflicting policies. Expressing policies using models can help by applying mathematical logic for conflict resolution.

Fourth, delivering on a fully closed-loop automation solution, where an IBN auto-corrects to always meet the intent, requires further research. The required algorithms must be explainable and have predictable actions and outcomes.^6,22,34 Imagine a closed-loop algorithm making compromises to achieve a high-priority intent at the expense of many lower-priority intents. Are such automated trade-offs acceptable to the operator(s)? How do we ensure that closed-loop correction algorithms comply with regulations? Even with proper logging and tracing functionality of such algorithms, operators may wish to retain control of the correction logic—for example, by being prompted before a change is applied in the network.

Fifth, given the massive improvements in visibility and data-gathering across the network, there are huge opportunities to apply ML, MR, operations research, signal processing, and other algorithmic disciplines to make valuable improvements.¹³

While this article has highlighted the opportunities for IBN, the future offers opportunities to integrate compute, storage, and networking into holistic, large-scale, intent-based systems. In summary, IBN can lead to significant benefits not only for the enterprises that use them but also for society in general through improved productivity, reliability, security, and agility.

Back to Top

Back to Top

Back to Top

Back to Top

Back to Top