Credit: Dmitriy Rybin
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.
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,8 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:
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).18 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,29 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.
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.27
Today's enterprise network architectures and their operational procedures need to evolve. A network architecture supporting modern business operations should be:
An intent-based network11 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 211).
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, activationa 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.8 An IBN adapts the notion of self-driving networks expressed in Feamster and Rexford8 to an enterprise networking context and expands it with the additional focus on the translation function. IBNs improve on SDN8,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:
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.10
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,20 for example by employing graph theory.23
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.2 This operation is analogous to converting a customer-facing service model into a resource-facing service model.32
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.32 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.
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:
In the activation function, they:
In the assurance function, the application of ML/MR allows the system to:
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.33 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.7 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).7
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.
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.23, 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.
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.21 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.13
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.
1. Amaral, P. et al. Machine learning in software defined networks: Data collection and traffic classification. 2016 IEEE 24th International Conference on Network Protocols, 1–5.
2. Borril, P., Burgess, M., Craw, T., and Dvorkin, M. A promise theory perspective on data networks. Computing Research Repository (September 2014); abs/1405.2627.
3. Bottou, L. From machine learning to machine reasoning. Machine Learning 94 (2014), 133–149; 10.1007/s10994-013-5335-x.
4. Boutaba, R. and Aib, I. Policy-based management: A historical perspective. J. of Network and Systems Management 15, 4 (2007), 447–480.
5. Clemm, A., Ciavaglia, L., Granville, L., and Tantsura, J. Intent-based networking—Concepts and definitions. Internet Engineering Task Force, Network Working Group (December 24, 2019); https://datatracker.ietf.org/doc/draft-irtf-nmrg-ibn-concepts-definitions.
6. Derbel, H., Agoulmine, N., and Salaün, M. ANEMA: Autonomic network management architecture to support self-configuration and self-optimization in IP networks. Computer Networks 53, 3 (February 27, 2009), 418–430; 10.1016/j.comnet.2008.10.022.
7. Elgar, B. and Vasters, H. It's not a network problem, I can prove it with Cisco DNA Assurance. Cisco Live (January 2020); https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2020/pdf/PSOCRS-1102.pdf.
8. Feamster, N. and Rexford, J. Workshop on self-driving networks—Workshop report. NSF Self-Running Networks Workshop, Princeton University, (January 2018); https://www.cs.princeton.edu/~jrex/papers/self-driving-networks18.pdf.
9. Foster, N. et al. Languages for software-defined networks. IEEE Communications Magazine 51, 2 (2013), 128–134, 2013.
10. Han, Y. et al. An intent-based network virtualization platform for SDN. 2016 12th Intern. Conf. on Network and Service Management, 353–358.
11. Intent-based networking: Building the bridge between the network and IT. Cisco; https://securenetworkers.com/wp-content/uploads/2018/08/Cisco-nb-09-intent-networking-wp-cte-en.pdf.
12. Intent NBI—Definition and principles. Open Networking Foundation. (October 2016); https://opennetworking.org/wp-content/uploads/2014/10/TR-523_Intent_Definition_Principles.pdf
13. Kim, C. et al. In-band network telemetry via programmable dataplanes. (2015).
14. Kim, H. and Feamster, N. Improving network management with software defined networking. IEEE Comm. Magazine 51, 2 (February 2013), 114–119.
15. Kosiur, D. Understanding Policy-Based Networking. Wiley Computer Publishing (2001); https://epdf.pub/understanding-policy-based-networking.html.
16. Kreutz, D. et al. Software-defined networking: A comprehensive survey. In Proceedings of the IEEE 103, 1 (January 2015), 14–76.
17. Lenrow, D. Intent as the common interface to network resources. Intent-Based Network Summit (February 2015).
18. Li, C. et al. Intent classification. Internet Engineering Task Force, Network Working Group (November 18, 2019); https://www.ietf.org/id/draft-li-nmrg-intent-classification-02.txt.
19. Mao, H., Alizadeh, M., Menache, I., and Kandula, S. Resource management with deep reinforcement learning. HotNets '16: Proceedings of the 15th ACM Workshop on Hot Topics in Networks (November 2016), 50–56; https://doi.org/10.1145/3005745.3005750.
20. Mestres, A. et al. Knowledge defined networking. ACM SIGCOMM Computer Communication Review 47, 3 (July 2017), 2–10; https://doi.org/10.1145/3138808.3138810.
21. Mercian, A. et al. Mind the semantic gap: Policy intent inference from network metadata. IEEE 7th Inter. Conf. on Network Softwarization (2021), 312–320.
22. NeMo: An application's interface to intent-based networks. NeMo Project.
23. Prakash, C. et al. PGA: Using graphs to express and automatically reconcile network policies. ACM SIGCOMM Computer Communication Review 45, 4 (2015), 29–42.
24. Raouf, B. and Aib, I. Policy-based management: A historical perspective. J. of Network and Systems Management 15, 4 (2007).
25. Russell, S. and Norvig, P. Artificial Intelligence: A Modern Approach 3rd edition, Pearson Education (2010).
26. Sivakumar, K. and Chandramouli, M. Concepts of network intent. IETF draft. Internet Engineering Task Force (2017).
27. Skorupa, J., Lerner, A., and Ganguli, S. Innovation insight: Intent-based networking systems. Gartner (February 7, 2017); https://www.gartner.com/en/documents/3599617/innovation-insight-intent-based-networking-systems.
28. Sloman, M. Policy driven management for distributed systems. J. of Network and Systems Management 2, 4 (December 1994), Springer.
29. Strassner, J. Policy-Based Network Management, Elsevier (2003).
30. Strassner, J. et al. The design of a novel context-aware policy model to support machine-based learning and reasoning. Cluster Computing 12 (March 2009), 17–43.
31. Tsuzaki, Y. and Okabe, Y. Reactive configuration updating for intent-based networking. 2017 Intern. Conf. on Information Networking, 97–102.
32. Unravelling the enigma of resource-facing service. Inform TM Forum.
33. Vasseur, J.P. A cloud-based machine learning/analytics architecture for Cisco DNA (wireless/wired) assurance. Cisco Live (2018); https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKEWN-2033.pdf.
34. Voellmy, A., Kim, H., and Feamster, N. Procera: A language for high-level reactive network control. HotSDN '12: Proceedings of the 1st Workshop on Hot Topics in Software Defined Networks (August 2012), 43–48; https://doi.org/10.1145/2342441.2342451 2012.
35. Xie, J. et al. A survey of machine learning techniques applied to software defined networking (SDN): Research issues and challenges. IEEE Communications Surveys & Tutorials 21, 1 (2019), 393–430.
a. We use the term "activation" instead of "automation" since all three functions are automated.
An enterprise network (See Figure 1), is typically composed of:
Figure 1. An enterprise network.
Devices such as laptops, tablets, sensors, and cameras connect to wireless access points on campuses and branches. In some cases, these devices use a wired connection to directly connect to access switches. The wireless access points connect to access switches, which typically also provide admission control policies (who can get into the network). In large campuses, many access switches are required to connect the many devices, so distribution switches are deployed to connect access switches to each other and to the WAN. In very large campuses, an additional layer of core switches is also deployed.
WAN routers in campuses or branches connect the local network of switches and access points to the rest of the enterprise. The WAN transport is typically acquired as a service from a service provider (MPLS VPN, leased lines). In some campuses or DCs where Internet (untrusted) connectivity is provided, security devices such as firewalls or intrusion-detection/intrusion-prevention systems are deployed. VPN gateways in such locations allow remote mobile users (4G, 5G) to connect to the enterprise network infrastructure using IPSec VPNs. Software-defined WAN allows enterprises to leverage typically cheaper Internet connections to interconnect campuses and branches. In this case, the WAN routers are connected to the Internet, and IPSec-based tunnels are established between the WAN routers to secure the communication.
Applications in modern enterprises are hosted in multiple places: on servers connected to the enterprise DC network; in virtual private clouds (VPCs) such as Amazon AWS, Google GPC, and Microsoft Azure; or consumed as a service directly from the application provider—for instance, Microsoft Office 365.
Enterprise networks can be immense, highly complex, and very diverse in structure. Furthermore, the rapid rate of change of new services, applications, devices, and IoT deployments means that there is a constant need for changes or improvements to the network. This complexity, scale, and desired speed of change is often beyond what network experts can achieve with current tools.
Copyright held by author(s)/owner(s). Publication rights licensed to ACM.
Request permission to publish from [email protected]
The Digital Library is published by the Association for Computing Machinery. Copyright © 2022 ACM, Inc.
No entries found
