Intent-based Industrial Network Management Using Natural Language Instructions

Abstract

Intent-based Networks (IBNs) allow specifying network operations using natural languages, which can significantly reduce network management cost and effort, as well as improve efficiency. In this work, we discuss the design of a typical IBN. In particular, we define several intent classes corresponding to different network operations. Subsequently, we use machine learning classification to map a natural language intent into one of those classes. Relevant network entities, if any, are also identified. After an intent has been resolved, the corresponding networking task is triggered. We design an IBN prototype based on the proposed architecture by integrating natural language intent processing with a network and a network controller. Subsequently, we evaluate the IBN prototype with sample intents as inputs. The IBN prototype was found to successfully execute the networking tasks, based on input intents, and installed the desired effects, which were verified with network tests.

Full text

Intent-based Industrial Network Management Using
Natural Language Instructions
Barun Kumar Saha
Grid Automation R&D
Hitachi Energy
Bangalore, India
barun.kumarsaha@hitachienergy.com
Luca Haab
Grid Automation Products
Hitachi Energy
Bern, Switzerland
luca.haab@hitachienergy.com
Łukasz Podleski
Grid Automation Products
Hitachi Energy
Bern, Switzerland
lukasz.podleski@hitachienergy.com
Abstract—Intent-based Networks (IBNs) allow specifying net-
work operations using natural languages, which can significantly
reduce network management cost and effort, as well as improve
efficiency. In this work, we discuss the design of a typical IBN.
In particular, we define several intent classes corresponding
to different network operations. Subsequently, we use machine
learning classification to map a natural language intent into
one of those classes. Relevant network entities, if any, are also
identified. After an intent has been resolved, the corresponding
networking task is triggered. We design an IBN prototype based
on the proposed architecture by integrating natural language
intent processing with a network and a network controller.
Subsequently, we evaluate the IBN prototype with sample intents
as inputs. The IBN prototype was found to successfully execute
the networking tasks, based on input intents, and installed the
desired effects, which were verified with network tests.
Index Terms—Intent-based Networks, network management,
natural language understanding, network architecture, network
emulation
I. INTRODUCTION
As we prepare to transition from Industry 4.0 to Industry
5.0, the importance of efficient network operations only keeps
growing. However, network management continues to remain
a challenging task, as is evident from the volume of con-
temporary research works [1], [2]. This is particularly true
for industries, where heterogeneous operational technology
(OT) networks—such as, industrial IoT, teleprotection, and
SCADA—and information technology (IT) networks merge
together.
Contemporary studies [3] indicate that network operations
are still largely managed by using command line interfaces,
which often leads to human errors, network downtime, and
loss of revenue. In other words, contemporary network man-
agement solutions deal with how to attain any given network
goal by executing low-level commands. In contrast, it would be
useful to specify what is required of a network, so that the task
of interpreting and achieving the intended goal is delegated to
the network (or system, in general). Intent-based Networks
(IBNs) [4]–[6] are meant to address this challenge.
In this work, we investigate the design of IBNs by con-
sidering the problems of expressing network intents using
natural languages, interpreting them, and executing appropriate
actions. The choice of natural language is motivated by the fact
that it is intuitive and easily understood by diverse stakeholders
across different businesses. Since operations can be specified
in an intuitive manner, the cognitive load of the network engi-
neers would be potentially reduced. Moreover, the scope can
be extended to manage other heterogeneous systems as well,
for example, to route power flows between digital substations
and other distributed energy sources. Consequently, IBNs offer
a significant value addition to the customers.
We consider representative network actions that engineers
intend to perform. We use several English sentences to de-
scribe such intents, based on which, a Natural Language
Understanding (NLU) [7] model is trained. In addition, we
map these intent classes into respective actions. Subsequently,
when an intent is provided as input in our IBN prototype, the
corresponding action is identified and executed in the network.
Figure 1 presents a simplified view of IBNs. From an
architectural perspective, the intent processing layer is located
above the typical network management layer. The intent
translator maps an input intent into a pre-defined action class.
The action delegator delegates the appropriate action(s) to the
Network Management System (NMS). In case of Software-
defined Networks (SDNs), the NMS can contain suitable SDN
controller(s). We assume that the underlying network—legacy
or otherwise—provides appropriate interfaces, such as a set of
commands and northbound API, to realize the intents.
The novelty of this work is multi-fold. First, customers can
easily adapt/extend the IBNs model to capture new intents
by adding new data points (text examples) and training a
new NLU model accordingly. Second, the IBNs model can
itself generate composite intents based on simple data points
provided. Finally, the inherent decoupling between intents and
corresponding actions allows customers to not only manage
SDNs and legacy networks, but also heterogeneous systems.
The specific contributions of this work are as follows:
•Representing network intents using natural language texts
and training an NLU model to classify them into intent
classes.
•Automatically generating composite network intents by
combining on two or more simple intents.
•Designing an IBN prototype to trigger networking tasks
based on natural language specifications.
The paper is organized as follows: Section II reviews related
works. The problem is discussed in Section III. Section IV
Accepted version (for personal use only)

Fig. 1: A scaled-down version of IBNs, based on the archi-
tecture proposed by Saha et al. [5].
describes the mapping of intents and entities into actions.
Sections V and VI, respectively, discuss the experimental setup
and results. Finally, Section VII concludes this work.
II. RE LATE D WOR K
Several approaches have been proposed to represent the
intents in IBNs. Some works consider optimization problems
as inputs [8], which, however, are unsuitable for the end
users. Domain-specific languages have also been considered
for this purpose. For example, Xia et al. [9] proposed the
network modeling (NEMO) language, an SQL-like language
for specifying network operations. However, the language is
largely prescriptive, rather than descriptive.
Abhashkumar et al. [10] developed Janus, an intent-based
dynamic, group-centric policy framework. Janus formulates
and solves optimization problems to identify the network
parameters in order to accommodate as many configuration
changes as possible, while minimizing the path changes at the
same time. Janus, however, does not accept natural language
inputs, but high-level specifications in form of policy graphs.
Several authors have considered the use of natural language
for specifying intents. Kiran et al. [4] developed the Intelligent
Network Deployment Intent Renderer Application (iNDIRA),
which is located above a network’s control plane. iNDIRA
uses natural language processing techniques to express and
process intents. It parses keywords and synonyms to identify
network operations. However, it is unclear how to deal with
composite intents.
Jacobs et al. [11] investigated the problem of refining and
processing intents. The proposed system uses DialogFlow,
a chatbot, to extract network intents and entities, such as
network endpoints and middleboxes. It uses sequence-to-
sequence learning to translate the extracted entities into an
intermediate form (extended Backus-Naur form grammar),
based on which network commands can be triggered. However,
extending the scope of such a grammar requires high level
of expertise. In contrast, the current work takes a modular
approach. This is particularly relevant to customers, who can
incrementally grow the scope of a deployed IBN by adding
intents as per need without requiring external support from
the vendor. Second, composite intents proposed in this work
TABLE I: Summary of related works
Support for
Abhash-
kumar
et al.
[10]
Kiran
et al.
[4]
Jacobs
et al.
[11]
Alsudais
and
Keller
[12]
Proposed
IBNs
model
Natural
language No Limited Full Keywords-
based Full
Model ex-
pansion N/A Difficult Difficult Difficult Easy
Legacy net-
works No Yes No No Yes
Heteroge-
neous
systems
No No No No Yes
Intent com-
position No No No No Yes
can potentially encompass all possible network intents without
requiring to explicitly specify them. This, in turn, can help
in saving manual efforts. Finally, any specific intermediate
representation of intents bind them to a particular system. In
contrast, the IBNs model proposed in the current work can
be potentially used to manage heterogeneous systems, such as
communication networks and energy grids.
Alsudais and Keller [12] discussed the use of Natural Lan-
guage Processing for managing computer networks. Although
the current work share similar objectives with Alsudais and
Keller [12], the latter adopted a keywords-based approach to
interpret text, which can become difficult as the number of
intents increase.
Table I summarizes the key differences between the pro-
posed IBNs model and the state of the art. To synthesize,
a growing interest in enabling natural language-based inter-
actions with networks is observed. However, most of these
systems are designed strictly for SDNs, which make their
use for managing other types of networks and systems dif-
ficult. Moreover, efficient intent representation and translation
remains an open problem. Apart from user friendliness, the
aspects of scalability and support for heterogeneous systems
also need to be adequately addressed. For example, customers
should be able to expand their intents base so as to include
additional use cases with ease. Consequently, this calls for
detailed investigation into the problem.
III. PROB LE M DESCRIPTION
We consider an IBN, which takes an intended network
operation expressed in English text (“intent”) as input and trig-
gers appropriate network commands in response. The network
intent can involve a simple task, or can be a complex one
comprising of multiple tasks. In particular, a simple intent is
one that performs (or triggers) a single, well-defined network
task, such as creation of a flow. Typically, standard network
commands and/or programs are already available to implement
a simple intent. In contrast, a k-composite intent is made of k
distinct simple intents (k > 1). In other words, a k-composite
intent triggers two or more associated simple network tasks,
for example, creation a flow and blocking a certain port.
Table II lists a few typical simple and composite intents
together with the entities required by them. For example, to
Accepted version (for personal use only)

TABLE II: Meta-description of some typical intents
Intent Category Description Network Entities
create_flow Simple
Create a unicast network flow
between two endpoints with op-
tional QoS constraints, such as
bandwidth and latency.
Mandatory: (source, target)
Optional: (qos)
create_vnf Simple
Create a virtual network function
(if a functional one is currently
unavailable).
Mandatory: (vnf1)
Optional: (endpoint1, endpoint2, vnf2, vnf3)
apply_filter Simple
Modify characteristics of a flow,
for example, allow and block
ports.
Mandatory: (action)
Optional: (port, source, target)
create_flow+create_vnf 2-composite Mandatory: (source, target, vnf1)
Optional: (qos, endpoint1, endpoint2, vnf2, vnf3)
create_flow+apply_filter 2-composite Mandatory: (source, target, action)
Optional: (qos, port, source, target)
create_flow+create_vnf+apply_filter 3-composite
Mandatory: (source, target, vnf1, action)
Optional: (qos, endpoint1, endpoint2, vnf2, vnf3, port,
source, target)
create a unicast flow, the “source” and “target” endpoints
are mandatorily required by the simple intent create_flow.
However, the “qos” entity, denoting Quality of Service con-
straints, is optional; a default value may be used if bandwidth
requirement is unspecified. This proposed approach of repre-
senting network intents is scalable, since new intents—simple
or composite—can be easily added to train a new NLU model
and address new business use cases. As a convention, we label
ak-composite intent by joining the names of ksimple intents
using the + symbol.
Accordingly, the problem of network intent resolution in an
IBN can be divided into the following steps:
•Classify an input text into a pre-defined intent class
•Identify the entities embedded in the intent, if any
•Trigger action based on the identified intent and entities
We discuss the model training and the design of IBNs in
details in the remainder of this paper.
IV. NLU MO DE L FO R INT EN T RESOLUTION
We now discuss various aspects of intent resolution in IBNs.
A. Model Definition
Figure 2 illustrates the different steps involved in engineer-
ing an IBN. The process begins with identifying the commonly
performed network management operations by interviewing
one or more network engineers, for example. Subsequently,
these inputs are segregated into multiple, distinct categories or
classes. For example, a create_flow intent class can be created
to group together different sentences that express the creation
of a network flow between two endpoints. After the simple
intent classes are determined in this way, the composite intents
can be generated based on the available data points.
Since not all compositions are practically useful, for exam-
ple remove_flow+apply_filter, users can use a meta-description
file to mark one or more composite intent classes as not
required (alternatively, only the required compositions). Such
pruning can help in reducing the model training time as well
as prediction performance.
Fig. 2: Steps to define intents, train an NLU model, and map
to network actions.
B. Intent Resolution and Task Execution
At this stage, all the concerned simple and composite intent
classes are available. In addition, the set of network actions,
A, is also known. Based on these, a mapping from the set of
intents to the set of actions is defined (Figure 2). The NLU
model identifies associated entities, if any, and passes them
as parameters to the corresponding actions. For example, the
create_flow intent invokes a function with the source and target
of the flow as parameters. The function, in turn, identifies
the optimal path, generates the corresponding flow rules, and
invokes the appropriate API provided by the NMS to install
the forwarding rules in the switches along the identified path.
It may be noted that any infeasible intent, a requested flow
whose bandwidth demand cannot be met, is rejected.
The network intents, including those not covered in Table
II, can be used to realize different edge management scenarios.
For example, one can use them to create a communication flow
between a machine on a factory floor and its spatially nearest
edge device. Moreover, a cloud to edge devices multicast flow
can be created to deploy or offload edge learning models, for
example. Once again, we assume that the appropriate API is
Accepted version (for personal use only)

Algorithm 1: Mapping of entities to intents
Input:
•t: Plain-text intent
•L: List of top Kintent classes ranked by their classification
confidence for t
•E: Set of entities extracted as (name, value) pairs
Output: Y: Intent and related entities (provided or missing)
1Y←[] // Intitialize to empty list
2foreach intent class c∈Ldo
3Pc←Set of primary entities for c
4Sc←Set of secondary entities for c
5EP(c), ES(c),˜
EP(c),˜
ES(c)← ∅ // Intitialize all
to empty sets
6foreach entity name e∈Pcdo
7if e∈Ethen Add (e, e.value)to EP(c)
8else Add eto ˜
EP(c)
9foreach entity name e∈Scdo
10 if e∈Ethen Add (e, e.value)to ES(c)
11 else Add eto ˜
ES(c)
12 Append (c, EP(c), ES(c),˜
EP(c),˜
ES(c)) to Y
available, which generally is true for most public clouds.
In the operations stage, an intent and related entities are
extracted using a pre-trained NLU model. Subsequently, based
on the intents to actions mapping (Figure 2), the intended task,
such as allocation of a single traffic flow, is triggered. Each
networking task generates one or more commands, which are
then executed via the NMS. At this stage, the action intended
by a plain text intent is installed in the network.
C. Entity Mapping to the Intents
After the intent and entity classifications are performed on
an input intent text tby the NLU model, Algorithm 1 is
executed to map the extracted entities—those whose values
are available (line numbers 7and 10) as well those that are
missing (line numbers 8and 11)—to the corresponding intents.
The entities are mapped as per metadata available from Table
II. Algorithm 1 considers the top Kmatching intents, rather
than only the top one, so that a user can confirm in case of
any ambiguity. In addition, in case any entity value is missing
or incorrectly identified, a user can correct them as required.
Algorithm 1 iterates for K×max
c{|Pc|,|Sc|} times. Let d
be the highest order composite intent present in I. Moreover,
let z= max
c∈Id
{Pc+Sc}, i.e., the maximum number of entities
any d-composite intent has. Then, the iterations run Kz times
at most. Since Kis constant and zis typically small, the time
complexity of Algorithm 1 is O(1).
D. Data Annotations
We synthetically generated a dataset1of English sentences
to train an NLU model for IBNs. The sentences consisted of
different ways to specify a given action. For example, “create
flow between 10.0.0.1 and 10.0.0.2” and “add 10.0.0.1 to
10.0.0.2 flow” both convey the same intention. We labeled
these text with appropriate intents and entities classes. We
also combined the instances of simple intents from kdifferent
1The full dataset is available at https://github.com/barun-saha/IBNs
Fig. 3: Sample data used for training the NLU model.
classes to generate the k-composite intents. For example, the
two simple intents “create flow from 10.0.0.1 to 10.0.0.2” and
“block FTP” can be combined with conjunctive phrases to
generate the 2-composite intent “create flow from 10.0.0.1 to
10.0.0.2 as well as block FTP.”
Figure 3 shows sample annotated data used from the dataset.
The network entities are demarcated using square brackets; the
corresponding entity names are enclosed within the adjacent
parentheses. Here, we only consider bandwidth as a QoS pa-
rameter. However, additional QoS parameters, such as latency,
may also be considered.
V. EX PE RI ME NTAL SE TU P
We developed an IBN prototype as a Web application using
the Flask framework for Python, running in a physical Win-
dows 11 laptop with Intel(R) Core(TM) i5-10310U CPU and
16 GB RAM. The Web application centrally coordinated the
different activities including receiving text inputs from users,
identifying the intents and entities, getting users’ confirmation
after intent processing, executing appropriate algorithms, if
any, in response to the intent, generating forwarding rules,
and finally, communicating to an NMS or controller to deploy
the changes in the network.
We used Rasa2(version 2.8.14) to train an
NLU model by considering six intents: create_flow,
create_flow+apply_filter, remove_flow, apply_filter,
allocate_batch, allocate_batch+apply_filter. The NLU
pipeline of Rasa used Dual Intent and Entity Transformer
(DIET) [13] for intent classification and entity extraction.
100 training epochs were considered. We used Mininet3to
emulate a network of Open vSwitch (OVS) switches (Figure
4), running in a virtual machine. Ryu4, an OpenFlow network
controller, was used to manage the network by installing (or
removing) flow rules in switches.
We encapsulated each supported simple network task within
Python methods. For example, for the create_flow intent,
we defined a method to create a unicast flow between two
2https://rasa.com/
3http://mininet.org/
4https://ryu-sdn.org/
Accepted version (for personal use only)

Fig. 4: A hierarchical ring topology, often used with inter-
substation networks. All the links shown here are bidirectional
and have equal capacity. Five hosts and their IP addresses are
depicted.
endpoints. This method, in turn, used a shortest path algorithm
to determine a path. Finally, the method invoked the REST API
of Ryu to have the flow rules installed at the switches indicated
by the shortest path. Wherever appropriate, these entities were
supplied as parameters while invoking the REST API of Ryu.
The IBN maintained and updated a graph representation of
the underlying network for various computations. For example,
after allocating a new flow, the bandwidths of the links along
the flow’s path are appropriately reduced. We used the Shortest
Path-based Allocation with Threshold (SPA-T) [14] algorithm
for optimal allocation of a set of flows. Other algorithms, for
example, SAFAR [15], can also be used when appropriate.
Although the IBN prototype considers an SDN environment,
the concept is equally relevant to legacy networks as well.
We used 400 data points for each intent to train the NLU
model, except for the allocate_batch intent, for which only
270 data points were created due to lack of further variations.
80% of the examples were used for training and the rest 20%
for testing. We evaluated the IBN prototype using sample
intents and functionally verified whether or not the intended
network state was installed. In addition, we also considered the
following performance evaluation metrics: (1) training time,
precision, and recall: these characterize the performance of
the NLU model, (2) intent resolution time: the average
time difference between submission of an intent text and
receiving the intent and entities classification result back, (3)
intent execution time: the average time difference between
triggering of an intended action and completion of the action,
and (4) turnaround time: the total time taken to resolve a
text intent, execute it, and update the user interface.
VI. RE SU LTS
Figure 5 captures some of the performance metrics related
to the NLU model training and testing. The figure shows that
the time taken to train an NLU model increased with the
number of data points used. When tested with the test dataset,
the trained NLU model was found to have more than 99%
precision and accuracy, as shown in the figure. The results
indicate that, in general, an intent-based system can be realized
even with a few operational intents.
0
0.2
0.4
0.6
0.8
1
474 944 1384 1768 5
10
15
20
25
30
35
40
45
50
Value [%]
Time [min]
Training data points
Precision
Accuracy Training time
Fig. 5: Training performance of the NLU model.
Figure 6 captures the IBNs prototype in action. As shown
in Figure 6 (a), the text “create a flow from 10.0.0.1 to
10.0.0.2” was submitted as an input intent via the NLI. Based
on it, the IBN determined that the flow creation task is
most relevant to the user’s intent and displayed it at the top
with a highlighted background, as shown in Figure 6 (b).The
IBN also identified the endpoints, which are denoted by
their respective IP addresses. The IBN consolidated all these
information and presented to the user. However, in case the
IBN cannot resolve an intent by default, a user can also view
a list of other available intents and select the appropriate one.
When the “Confirm” button is pressed, the IBN triggers the
selected task. Alternatively, users can specify to automatically
execute the intended action without human intervention when
the intent classification confidence is high say, at least 95%,
and all primary entities are identified.
To verify the action of this intent, we sent ICMP ping
messages between the two hosts in the Mininet environment.
Only these two hosts were found to be able to reach each
other. The outcome verified the successful execution of the
intended network action.
In another experiment, we submitted the intent “create flow
from 10.0.0.1 to 10.0.0.2 and block web traffic.” After it was
executed, we initialized a Web server running at port 80 in
the first host and tried to access the Web server from the other
host. The two hosts were able to ping each other, but could not
access the Web server via port 80. This verified the successful
translation and execution of the composite intent. In a separate
experiment, we verified the correctness of the allocate_batch
intent as well. We skip the discussion in the interest of space.
Figure 7 shows the average time taken by the IBN prototype
to resolve intents and execute the corresponding actions,
together with 95% confidence intervals. Figure 7 also shows
that the intent execution time depends upon the particular in-
tent. It took longer to execute allocate_batch than create_flow
because an optimization algorithm had to be executed and
the forwarding rules for several flows needed to installed in
different switches. On the other hand, it took longer to execute
the create_flow+apply_filter intent because the corresponding
simple intents were executed sequentially. In particular, Ryu’s
REST API was invoked at first to install the flow rules in the
switches from the path. The REST API was then invoked again
to modify one or more of these installed rules. This indicates
Accepted version (for personal use only)

(a) The natural language interface (NLI) of the IBN (b) Intent resolution by the IBN
Fig. 6: Prototype demonstrating the functionality of IBNs.
0
0.2
0.4
0.6
0.8
1
create_flow
remove_flow
create_flow+
apply_filter
allocate_batch
0
1
2
3
4
5
6
7
8
Resolution time [s]
Execution time [s]
Intents
Resolution time
Execution time
Fig. 7: Intent resolution & ex-
ecution times.
0
0.2
0.4
0.6
0.8
1
1.2
h1-h2 h1-h3 h1-h4 h1-h5
Time [s]
Flow
Fig. 8: Turnaround times.
that it would be beneficial to have a customized (combining
multiple modifiers for a single flow together) implementation
of some frequently used composite intent tasks.
Figure 8 shows the average turnaround time for the cre-
ate_flow intent. The first two flows (x-axis) had 2-hop paths,
while the others used 4-hop paths. It can be observed that even
for a particular intent, the execution time varies depending
upon how many switches need to be modified.
VII. CONCLUSION
IBNs are expected to change the way how networks are
managed in the future. The use of natural language would
not only make network management easier, but the associated
cognitive load of engineers would also reduce. To this end, we
investigated how network operations can be identified—and
triggered—based on intents specified using natural language
texts. We discussed a mechanism for representing simple
and composite intents, used machine learning classification
to resolve them, and trigger the actions subsequently. We
also designed an IBN prototype to tangibly demonstrate these
features. The proposed approach is also scalable, since new
intents can be easily added to train a new model.
In the future, support for languages other than English may
also be considered. Moreover, the availability of an intent
manager to identify potential disruptions by any incumbent
intent would be useful. Nevertheless, any small step toward
realizing IBNs may already result in value addition.
REFERENCES
[1] S. T. Arzo, R. Bassoli, F. Granelli, and F. H. P. Fitzek, “Multi-
Agent Based Autonomic Network Management Architecture,” IEEE
Transactions on Network and Service Management, vol. 18, no. 3, pp.
3595–3618, 2021.
[2] P. Thorat and N. K. Dubey, “Pre-provisioning Protection for Faster
Failure Recovery in Service Function Chaining,” in 2020 IEEE In-
ternational Conference on Electronics, Computing and Communication
Technologies (CONECCT), 2020, pp. 1–6.
[3] (2014, May) Network Downtime Results in Job, Rev-
enue Loss. [Accessed: Feb. 14, 2022]. [Online]. Avail-
able: https://investors.avaya.com/investor-news/news-release-details/
2014/Network-Downtime-Results- in-Job- Revenue-Loss/default.aspx
[4] M. Kiran, E. Pouyoul, A. Mercian, B. Tierney, C. Guok, and I. Monga,
“Enabling intent to configure scientific networks for high performance
demands,” Future Generation Computer Systems, vol. 79, pp. 205 – 214,
2018.
[5] B. K. Saha, D. Tandur, L. Haab, and L. Podleski, “Intent-based Net-
works: An Industrial Perspective,” in Proceedings of the 1st International
Workshop on Future Industrial Communication Networks (FICN ’18).
New York, NY, USA: ACM, 2018, pp. 35–40.
[6] L. Pang, C. Yang, D. Chen, Y. Song, and M. Guizani, “A Survey on
Intent-Driven Networks,” IEEE Access, vol. 8, pp. 22 862–22 873, 2020.
[7] Y. Zheng, G. Chen, and M. Huang, “Out-of-Domain Detection for
Natural Language Understanding in Dialog Systems,” IEEE/ACM Trans-
actions on Audio, Speech, and Language Processing, vol. 28, pp. 1198–
1209, 2020.
[8] H. Zhang, Y. Wang, X. Qi, W. Xu, T. Peng, and S. Liu, “Demo
abstract: An intent solver for enabling intent-based SDN,” in 2017
IEEE Conference on Computer Communications Workshops (INFOCOM
WKSHPS), May 2017, pp. 968–969.
[9] Y. Xia, S. Jiang, T. Zhou, S. Hares, and Y. Zhang, “NEMO (NEtwork
MOdeling) Language,” 2016, [Accessed: Feb. 14, 2022]. [Online].
Available: https://tools.ietf.org/html/draft-xia-sdnrg-nemo-language- 04
[10] A. Abhashkumar, J.-M. Kang, S. Banerjee, A. Akella, Y. Zhang, and
W. Wu, “Supporting diverse dynamic intent-based policies using Janus,”
in Proceedings of the 13th International Conference on Emerging
Networking EXperiments and Technologies (CoNEXT). New York, NY,
USA: ACM, 2017, pp. 296–309.
[11] A. S. Jacobs, R. J. Pfitscher, R. A. Ferreira, and L. Z. Granville,
“Refining Network Intents for Self-Driving Networks,” in Proceedings
of the Afternoon Workshop on Self-Driving Networks. New York, NY,
USA: Association for Computing Machinery, 2018, pp. 15–21.
[12] A. Alsudais and E. Keller, “Hey network, can you understand me?”
in 2017 IEEE Conference on Computer Communications Workshops
(INFOCOM WKSHPS), 2017, pp. 193–198.
[13] T. Bunk, D. Varshneya, V. Vlasov, and A. Nichol, “DIET:
Lightweight Language Understanding for Dialogue Systems,” CoRR,
vol. abs/2004.09936, 2020. [Online]. Available: https://arxiv.org/abs/
2004.09936
[14] B. K. Saha, L. Haab, and L. Podleski, “Flow Allocation in Industrial
Intent-based Networks,” in 2019 IEEE International Conference on
Advanced Networks and Telecommunications Systems (ANTS). IEEE,
2019, pp. 1–6.
[15] B. K. Saha, L. Haab, and L. Podleski, “SAFAR: Simulated Annealing-
based Flow Allocation Rules for Industrial Networks,” IEEE Transac-
tions on Network and Service Management, vol. 18, no. 3, pp. 3771–
3782, Sep. 2021.
Accepted version (for personal use only)