Conference PaperPDF Available

Intent-based Networks: An Industrial Perspective

  • Hitachi Energy

Abstract and Figures

Intent-based Networks (IBNs) present a paradigm shift in conventional networking by allowing users to express what is required from a network, while internally resolving the detailed steps necessary to achieve that goal. Consequently, not only human effort, but chances of errors are also reduced. Moreover, once an intended state is achieved, IBN ensures that it is maintained unless a user requests otherwise. In this paper, we present an industrial perspective of IBN. In particular, we identify several use cases in the context of industrial networks that can potentially benefit from IBN. Subsequently, we propose an architecture of IBN, and elaborate how the different use cases can be realized using it. In addition, we present a case study on the use of intents with a widely used framework. Although, there still are a few challenges along the IBN way, when addressed, IBN can bring down an organization's expenses while improving its efficiency and reliability at the same time.
Content may be subject to copyright.
Accepted Version (For Personal Use Only)
Intent-based Networks: An Industrial Perspective
Barun Kumar Saha
ABB Corporate Research Center
Bangalore, India
Deepaknath Tandur
ABB Corporate Research Center
Bangalore, India
Luca Haab
ABB Power Grids
Bern, Switzerland
Łukasz Podleski
ABB Power Grids
Bern, Switzerland
Intent-based Networks (IBNs) present a paradigm shift in conven-
tional networking by allowing users to express what is required
from a network, while internally resolving the detailed steps neces-
sary to achieve that goal. Consequently, not only human eort, but
chances of errors are also reduced. Moreover, once an intended state
is achieved, IBN ensures that it is maintained unless a user requests
otherwise. In this paper, we present an industrial perspective of
IBN. In particular, we identify several use cases in the context of
industrial networks that can potentially benet from IBN. Subse-
quently, we propose an architecture of IBN and elaborate how the
dierent use cases can be realized using it. In addition, we present
a case study on the use of intents with a widely used framework.
Although, there still are a few challenges along the IBN way, when
addressed, IBN can bring down an organization’s expenses while
improving its eciency and reliability at the same time.
Networks Network architectures
Bridges and switches
Network manageability; Network experimentation;
Applied com-
puting Industry and manufacturing;
Intent-based Networks, Software Dened Networks, Industrial Net-
works, Network Architecture, Intent, Network Management
Although today’s communication networks are growing massively
in scale, their operation and management largely involves a manual
and intricate process. In contrast, IBN promises a paradigm shift
where network users and operators would manage their operations
by stating at a high-level “what to do,” rather than specifying the
low-level details of “how to do.” To present a real-life analogy,
consider the scenario where a person wishes to travel from Baden to
Bangalore. He/she has to book the ight, reserve a hotel room, make
travel arrangements to and from the airport, and also take time
Permission to make digital or hard copies of part or all of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for prot or commercial advantage and that copies bear this notice and the full citation
on the rst page. Copyrights for third-party components of this work must be honored.
For all other uses, contact the owner/author(s).
FICN’18, November 2018, New Delhi, India
©2018 Copyright held by the owner/author(s).
zone and local trac considerations into account. Contemporary
networks look more like this scenario. In contrast, had this been
IBN, the person would have simply asked an agent to arrange a
travel on a given date with time and airlines preferences; relevant
details would have been worked out by the agent behind the scene.
Such an approach can potentially reduce the burden (and chances of
errors) of concerned people. It is, therefore, unsurprising that IBN is
gaining a lot of attention both in industry and academia. In future,
the concept of IBN may as well be extended beyond networks to
encompass intent-based systems (IBX), in general.
Be it industrial networks [
] or enterprises, everyone can
reap benets from IBN. On one hand, data center management can
be simplied. On the other hand, IBN can ensure that the critical
constraints of latency and reliability are met in industrial networks.
As we shall see later, IBN technology can help in reducing both
capital and operational expenses involved in the network.
Motivated by these aspects, in this paper, we take a look at the
contemporary picture of IBN. The primary objectives of this work
are to identify important use cases related to industrial networks
and to investigate how they can benet from IBN.
The specic contributions of this work are as follows.
Discussing potential industrial use cases of IBN.
Proposing an architecture of IBN upon which future imple-
mentations can be based.
Identifying enabling points and future directions for IBN.
The remainder of this paper is organized as follows. Section 2
presents a review of related work on IBN. We discuss an architecture
of IBN in Section 3. Some of the potential use cases in the context of
industrial networks are identied in Section 4. A short case study
on intents is presented in Section 5. Section 6 discusses some of the
challenges associated with IBN and how they can be coped with.
Finally, Section 7 concludes this work.
Networks have witnessed automation for a long time in one form or
other – be it simple shell scripts or advanced services such as, Pup-
], on the other hand, has brought forward a huge wave
of innovation by simplifying the management of heterogeneous
devices. Around the same time, advances in articial intelligence
(AI) and machine learning (ML) techniques has allowed to further
simplify and automate network operations in the form of IBN.
Accepted Version (For Personal Use Only)
FICN’18, November 2018, New Delhi, India B.K. Saha et al.
Kiran et al. [
] developed the Intelligent Network Deployment In-
tent Renderer Application (iNDIRA) system to enable intent-based
networking. iNDIRA is designed to sit above SDN’s control plane
and interact via north-bound interfaces (NBIs). iNDIRA uses natu-
ral language processing (NLP) to allow users express their intents,
which are converted into Resource Description Framework (RDF)
graphs before getting translated into low-level commands. Primar-
ily aimed for science and research networks, users can request iN-
DIRA for a service (for example, le transfer between two end-points)
with desired constraints (say, 10 Mbps bandwidth); the system ei-
ther accepts it or informs back to the user why a request could
not be placed. Marsico et al. [
], on the other hand, considered the
process of application-aware resource negotiation between users
and the network. In case of resource unavailability, possible migra-
tion of non-critical services to alternative paths were considered in
order to accommodate new application requirements.
Arezoumand et al. [
] addressed the problem of applying intents
to multi-domain networks, where scalability is a big challenge. To
overcome it, the authors took a hierarchical approach. The multi-
domain network was represented as a multi-graph; an input intent
graph (consisting of all the intents) at rst underwent domain-wise
decomposition so that all intents were localized within the respec-
tive domains and there were no inter-domain edges. In particular,
transit domains with shadow end-points were added for non-peers.
Subsequently, the decomposed graph was further processed to gen-
erate local intent graphs. The authors considered a few dierent
types of intents, for example, virtual L2 WAN and service function
chaining. Results indicated that the proposed hierarchical approach
can oer about 30 times performance improvement as compared to
when the network was considered as at.
Tsuzaki and Okabe [
] proposed extensions to Network Model-
(NEMO), a domain specic language bearing similarity with
the Structured Query Language. While NEMO inherently provides
pro-active modeling capability, the authors proposed to augment it
with event-condition-action rules to make it reactive. The authors
further discussed dierent use cases, for example, adapting rout-
ing path based on bandwidth limits, where intents expressed with
reactive aspects can help in automate the network management.
Subramanya et al. [
] discussed the use of IBN as backhaul for
5G networks. In particular, the problem of duplicate packet removal
network function was addressed, which becomes important when a
given user is associated with multiple access points in a region, for
example, a stadium. The authors, in an IBN environment, moved
the said function to the backhaul, which also allowed for passing
the trac thorough other virtual network function (VNFs) such as
deep packet inspection. The intents (such as, dynamic chaining)
were represented with one or more virtual links. Results indicated
that without IBN, network throughput fell down frequently and
Zhang et al. [
] discussed the development of an intent solver
that can be used together with SDN controllers. The authors mod-
eled dierent types of intents – application-related and network
management-related – as optimization problems and used the in-
tent solver to solve them. Compared to greedy mechanisms, such
an approach allowed for resolving potentially conicting intents,
Figure 1: Architecture of IBN showing its dierent components. In
contrast to the common interpretation of IBN, “IBX” refers to the
complete suite of intelligent applications, services, and operations
that are supported by the network.
and consequently, it led to better utilization. Abhashkumar et al.
] discussed the development of Janus, a system to address a simi-
lar problem. In particular, Abhashkumar et al. extended the policy
graph abstraction [
] model in order to represent diverse Quality-
of-Service (QoS) policies (intents) that are relevant to a network.
Such QoS policies are not necessarily static, but can vary with
time giving rise to the dynamic nature of the graphs. Once a group
of such policies were available, an optimization problem was for-
mulated with the aim of maximizing the number of policies that
can be installed in the network taking into account policy and re-
source constraints; simultaneously, the extent of corresponding
path changes was aimed to be minimized.
Before looking at how one can benet from IBN, we present a
general architecture of it, as shown in Fig. 1. It is loosely inspired by
the Open Platform for Network Function Virtualization
project. Its dierent components are discussed below.
Intent Processor (IP)
: The IP is the core component of IBN/IBX,
and it interacts with most of the others. In particular, the IP is re-
sponsible for accepting high-level intents expressed by users (ap-
plications) using a semantic language or through other appropriate
user interfaces. Once an intent is available, the
module translates that into a mid-level representation that can be
understood by other modules. For example, IP can receive input in
plain English or as a mathematical model; in turn, it can translate
3 It is an ETSI backed project.
Accepted Version (For Personal Use Only)
Intent-based Networks FICN’18, November 2018, New Delhi, India
that into say, Algebraic Modeling Language, which can be easily
understood by a mathematical solver software. When an intent is
found to be feasible, IP communicates the corresponding instruc-
tions southward toward the devices. IP is also informed of any
potential threat to the intended state so that it can take actions, if
any, to protect the state.
Optimization & Decision Maker (ODM)
: ODM is responsible
for all decision making in IBN. ODM receives as input a mid-level
representation of an intent in the form of, for example, an optimiza-
tion [
] or decision making [
] problem. After solving, it returns
a feasible solution, if any, in the former case and the (relatively)
best decision in the latter case. Any such solution or decision is
conveyed back to IP. ODM essentially consists of one or more com-
mercial or open source solver(s). The latter may not be physically
located inside the network, but residing in an external cloud.
AI Engine (AIE)
sub-module of ODM applies AI- and ML-
based techniques upon past intents (both installed and rejected),
states and statistics to determine whether such actions were ap-
propriate. In the process, IBX gains knowledge of what is correct
in a given context and gradually learns to make better decisions
in terms of feasibility and intent installation. Optionally, IP incen-
tivizes or penalizes ODM depending upon whether or not a given
decision generated by the latter was appropriate. Like ODM, AIE
can also be cloud-based. However, in such cases, network latency
involved in decision making should be critically tested.
Data Store (DS)
: The DS acts as a repository of all relevant data
generated in and collected from the network. Appropriate access
mechanisms are provided to the other components of IBX so that
they can store/use data in/from the DS. In particular, the DS is
composed of the following two modules.
Database (DB)
: All concerned data are physically stored in
the DB, which can be centralized or distributed. Various kind
of data can be stored in the DB including, but not limited to:
Intents that are installed across the network together with
representation of the corresponding intended states
Periodically collected structured data, for example, link
and ow statistics, health monitoring data, and so on
Event-triggered unstructured data, for example, topology
change information
Network inventory data – either entered by operator or
discovered automatically
Graph Builder (GB)
: The GB module is aimed to provide
a graph-view of the underlying network to others. Such a
graph model can be used for optimization/decision making,
generating analytics, and network visualization. For exam-
ple, one may use the graph to solve the Traveling Salesman
Problem with the aim of sending a message to each switch
exactly once. In the absence of GB, the other IBN modules
would need to repeatedly construct a graph view of the net-
work by themselves based on data available in the DB. GB
also acts as a proxy for a typical topology manager; it contin-
uously updates the underlying graph in response to dierent
events such as link up/down and bandwidth changes.
State Observer (SO)
: After an intent is decoded and found to
be feasible, the IP installs it in the network. Additionally, the SO is
informed about the installed intent, which is subsequently stored
in the DS. The job of SO is to continuously monitor the network,
collect data and store them in DS, and inform IP in case it identies
any potential threat against an already installed intent. Such threats
can arise in dierent contexts, for example:
Topology change: Consider a user has installed an intent
to establish shortest path communication with another end-
point. However, if one or more links along the path go down,
the applied intent fails. In general, any change in the existing
network topology can potentially threaten one or more in-
tents applied in the network. Based on graph model available
from GB, the SO continuously evaluates whether any active
intent is violated by topology change(s).
Link characteristics change: Given an active link, its band-
width share for an application can decrease due to sudden
surge in trac. This can, too, threaten an intended state, for
example, minimum bandwidth requirement for a video call.
Other changes: A host can be overloaded with service re-
quests leading to failure in serving a critical service. Alter-
natively, the host can completely fail. Such scenarios may
threaten intents related to service provisioning.
: Primarily, this module has two purposes – 1) to
provide a visual outlook of the network, its status, and performance
at any point of time using a graphical user interface (GUI) and 2)
to allow users to express (some or all) intents via the GUI.
Analytics Engine (AE)
: AE is responsible to give answers to
simple as well as complex queries related to network performance.
It can take into consideration raw monitoring data, detailed graph
model, and advanced algorithms to generate results, which can be
displayed by the Visualizer. Optionally, the AE can provide REST
API to allow network monitoring by third-party applications.
It may be noted that the Visualizer and AE modules are non-
critical, whereas the others constitute as core components of IBN.
: In IBX, the apps are transparent to the underlying system
and only interact via suitable Application Programming Interfaces
(APIs). The system, in turn, provides the apps with relevant feedback
depending upon the context. For example, the IP may inform an
app that installation of a particular intent is infeasible at the given
moment. Human user(s) in the loop can consider such information
and take further decision appropriately.
Network, Storage, and Computation Controllers (NC, SC,
and CC)
: The three controllers are responsible for actually cong-
uring the devices (such as switches, disks, and servers) according to
a specied intent. The NC can be a network management system in
a traditional network or a controller in the SDN context. Commu-
nication between the IP and each of these controllers allows users
and operators of an IBN/IBX to eciently allocate and virtualize
resources as well as provision dierent services.
Infrastructure Manager (IM)
: The IM
acts as an interface
between the IP and the dierent controllers. It is also responsible for
translating feasible intents into more “domain-specic” instructions
related to the networking, storage, and computation. Consequently,
the IP module can be transparent to any underlying controller. For
example, IP can process an intent and request IM to allocate 50 GB
The line between network/computation/storage controllers and IM, however, can be
blurred. For example, OpenStack is an IM, but at the same time, it is also a storage and
computation controller.
Accepted Version (For Personal Use Only)
FICN’18, November 2018, New Delhi, India B.K. Saha et al.
Figure 2: Illustration of a typical “oral” topology used in utilities
networks. The Regional Control Center (RCC) may consist up to
nodes, whereas the network as a whole may have
The National Control Center (NCC) is responsible for controlling
the RCCs, which control their respective ring networks.
storage, 5 CPU cores, and a P2P line between A and the place where
the storage is. IM can process this in two steps – 1) at rst, it talks to
the storage and computation controllers, respectively, to reserve 50
GB space and 5 CPU cores and 2) it asks the network controller to
establish a path. Moreover, IM is responsible for collecting various
statistics from the controllers.
Communication networks are used in various industrial sectors
such as utility, oil and gas, mining, and power distribution. In some
scenarios, like mining, wireless networks are used, while in many
others wired networks is the technology of choice. Fig. 2, for ex-
ample, shows a typical ring network used in utilities sector. Such
networks usually have protection path(s) (could be multi-hop) that
are used when the link(s) of the ring fail(s). The concerned net-
work manager is responsible for enforcing various kinds of policies
including QoS guarantees and dynamic route adaptation.
Here, we discuss some use cases where IBN can be potentially
useful. They span dierent phases of a network life from bidding
to commissioning and operations. We also discuss how these use
cases can be realized with respect to the proposed architecture of
Bidding and Commissioning
: Much before a network is actu-
ally deployed, one has to enter the bidding process and provide a
meaningful cost estimate. To make things more challenging, project
requirements are often specied briey and vaguely. For example,
a customer may say the he/she requires a network of
services out of which
are critical, and so on. IBN can
be used here to provide a relatively more accurate price quote in a
very short time as compared to a manual process. This is realized
by having all the involved Apps submitting their constraints to the
IP, which then converts them into an optimization problem. Subse-
quently, the ODM browses through the inventory of devices (not
necessarily only those available in the current network) and their
Figure 3: Workow to verify whether a given set of intents can be
applied to IBN.
specication in the DS and chooses an optimal set of devices. It may
even suggest devices that are not in the database if no sensible solu-
tion is found. Based on the cost of optimization, the bidding amount
is computed and conveyed back to the App. Similarly, during com-
missioning, IBN can be used to generate optimum congurations
for the devices in a quick and ecient manner, unlike a manual
approach. IBN, therefore, can help in bringing down cost and time
in both the scenarios.
Planning/Accommodating Changes
: In an operational net-
work, users and operators may want to introduce various changes.
For example, changing the resource allocation in disaster recovery
situation, while regularly adding new sensors or simply adding
cables. In reality, such requests may often create potential conicts;
IBN can be used to decide whether or not those new ows can
be accommodated. In particular, a new ow can be accepted if 1)
enough bandwidth is available, 2) is of high priority (say, voice traf-
c and teleprotection), and 3) other trac constraints are aected
by tolerable measures. Alternatively, it can be accommodated by
throttling/dropping low priority ows. IBN can make these optimal
decisions without requiring an operator to do complex calculations.
A closely related use case is that of planning, where a user merely
want to “simulate” the eects of introducing a set of changes. In
such a case, the computations have no eect upon the real network
. Figure 3 illustrates this process.
Protecting N:1 Systems
: IBN can play a signicant role in the
operations phase of a network. For example, in certain applica-
tions often networks have a single (pre-computed) protecting path
working paths. When one of these working paths
fails, trac is switched over to the protecting path. However, since
there are still potential chances of failure, IBN, taking into account
the changes in topology, can compute a new protecting path as
backup. It may be noted that the new protecting would be there on
a temporary basis. Although, such dynamicity is atypical for highly
critical applications, it is useful for less critical systems that can
benet from high availability.
Dierent software environments have been used to evaluate IBN-
related ideas discussed in Section 2. Emulation-based approaches
Accepted Version (For Personal Use Only)
Intent-based Networks FICN’18, November 2018, New Delhi, India
use Mininet
to generate the network with multiple switches and
hosts. SDN controllers, for example, OpenDaylight
(ODL), Open
Network Operating System
(ONOS), POX, and NOX, are typically
used to implement the intent framework. NOX is the original SDN
controller; POX is a Python-based implementation of it. However,
both NOX and POX seem to be dated in terms of supporting the
latest OpenFlow versions. ODL consists of the Network Intent
project, where intents are used to express network
policies that are communicated to the SDN.
ONOS provides several built-in intents to enable host-to-host
contact, point-to-point communication, virtual network creation,
and so on. In the following, we present a case study on ONOS’
host-to-host intent and look at how it reacts to topology changes.
For this purpose, a network of 10 Open vSwitches and two hosts
were created using Mininet, as shown in Fig. 4 (a). Next, we en-
abled communication between the two hosts (identied with their
respective MAC addresses) using the following command in ONOS:
add-host-intent 52:2F:37:08:44:9E/None
Fig. 4 (b) shows the trac path (highlighted) between these two
hosts under this scenario. Note that the hosts can reach one another
via a 4-hop path. Next, we removed the links between switch 1 & 7,
3 & 6, and 7 & 9; Fig. 4 (c) shows the updated path. Finally, we let the
link between switch 1 & 7 become active once again, as shown in Fig.
4 (d). Although, a new shorter 4-hop path between the hosts became
available, ONOS was found to retain the old longer path. This could
possibly be a conscious decision of not disturbing the path (and
therefore, the intended state) as long as it is working because of
switching overhead. However, when shortest path communication
is intended, the concerned intent in ONOS would not be a good
choice, particularly when the hop count between the shortest and
the next shortest paths dier by a large extent. Nevertheless, this
study reveals how powerful intents are, which work even in the
absence of any intelligence at the routing and switching layers.
Until now, we looked at the potential of IBN and how it can ben-
et us under dierent scenarios. However, are we ready to imple-
ment/roll out IBN immediately? Gartner
predicted that IBN is
unlikely to become mainstream until 2020. In this Section, we look
at dierent challenges that are associated with IBN’s large-scale
adoption and discuss how some of them can possibly be addressed.
Language barriers
: One of the key challenges in IBN is the
apparent lack of a standard but expressive language for specifying
intents. IBNs are always expected to have humans in the loop, and
therefore, having a high-level intent to express intents is desirable.
Although NEMO and iNDIRA throw light along that direction, their
capabilities may not yet be compared to that of naturally spoken
languages, for example, English. Moreover, the development of
NEMO does not seem to be active in the recent past.
In addition to the above, there is need for having multiple (three)
languages. As noted in the architecture, users represent intents at a
9 networking-faq/
(a) Initial topology
(b) Host-to-host intent installed
(c) Links between switch 1 & 7, 3 & 6, and 7 & 9 removed
(d) Link between switch 1 & 7 restored
Figure 4: Illustration of host-to-host intent in ONOS. Path between
the hosts is updated in response to topology changes.
high-level, ODM processes a mid-level expression, whereas devices
understand low-level instructions. Therefore, until a set of suitable
Accepted Version (For Personal Use Only)
FICN’18, November 2018, New Delhi, India B.K. Saha et al.
languages are chosen, eorts on having them translated could not
be initiated, which would aect in realizing a fully functional IP.
Independently, we also note that it might be a good idea to begin
with in a small-scale. For example, initially one may have a simple
GUI where users visually input their intents; serializing (say, using
JSON) of such data is simple and can be easily converted into a
structure understood by the ODM. Later, each of these layers could
be progressively replaced with advanced components.
Closed-loop verication
: It may be noted that the goal of IBN
is not just expressing intents and having them installed. Unlike
contemporary networks, IBN also aims to maintain the states en-
forced in the network by the respective intents. Such a process
requires a closed-loop feedback, which has been illustrated in Fig.
1. However, what is meant by a “threat” in this context is yet to be
addressed. Moreover, when a threat is perceived, what should be
the appropriate response? For example, does the system attempt to
x it by allocating new resources, or does it block new intents and
undo some existing ones to remove the threat. Perhaps a simple
answer to this may not be possible; the response would depend
on the kind of specic situation. In this context, one may classify
the threats into potential categories say, mild, medium, and severe,
together with prioritizing the intents. Such an approach may give
better ideas on how to handle the threats in IBN.
AI and ML
: It is expected that IBN would greatly benet from
advances in the domains of AI and ML. In particular, a set of service
requests can often lead to constrained optimization problems, which
can make use of AI-based heuristics to obtain a solution. On the
other hand, as an IBN operates over time, it gradually starts to learn
by itself. For example, when the network learns that a video call
placed by a user was not satisfactory, it may attempt to reserve a
stable and higher-capacity path in the future or inform the use that
a good quality could not be achieved at that moment. However,
there are a few issues involved here. First, a critical requirement for
any ML algorithm is data. IBN, therefore, has to operate for some
time to have such data available. However, any data collected from
the pre-IBN deployment could perhaps be used until that time.
Second, AI can be a double-edged sword. On one hand it can
imbibe eciency; AI can be used for network analysis and intent
implementation. On the other hand, it might be dicult to explain
why an automated algorithm did something the way it did. This
is particularly important for industrial networks, where, in the
aftermath of an accident, the company has to provide explanations.
Moreover, it is required that AI algorithms do not change/adapt
the currently deployed and working networking connections in
order to maintain the state of the network. So, in case of a failure,
currently working connections should not be impacted while AI
tries to x the failure. Nevertheless, IBN will still retain human in
the loop, which will help in verifying an action before it is actually
taken. Additionally, it may be interesting to either have an AI-
assisted procedure for humans or use some other technologies to
track decisions.
Legacy networks
: Industries – and enterprises, to some extent
– often have legacy network equipment and systems. The aspects
of bringing them under the IBN umbrella also need to be consid-
ered. In fact, one needs to look at integrating other networks as
well, for example, SDN, MPLS, and MPLS-TP. The exact nature of
communication would depend on the specic controller/network
management system in use.
IBN is expected to change the way how networks are operated and
managed. On one hand, the use of high-level intents would simplify
its handling. On the other hand, integration of AI and ML algorithms
would make it more ecient and robust. In this work, we proposed
an architecture that encompasses these dierent elements. We also
discussed several use cases of IBN and illustrated a workow based
on the proposed architecture. Finally, we also shed light on IBN’s
readiness for adoption and challenges that may be faced toward
that goal.
In future, the scope proposed architecture can be further ex-
tended. In particular, as in ONOS, one would need to formulate the
state machine of intents by capturing all transitions. Additionally,
more use cases should be identied for wide acceptability. Finally,
it needs to be evaluated how well the proposed architecture can
perform in reality.
A Abhashkumar, J.-M Kang, S Banerjee, A Akella, Y Zhang, and W Wu. 2017.
Supporting Diverse Dynamic Intent-based Policies Using Janus. In Proceedings
of the 13th International Conference on Emerging Networking EXperiments and
Technologies (CoNEXT). ACM, New York, NY, USA, 296–309.
S Arezoumand, K Dzeparoska, H Bannazadeh, and A Leon-Garcia. 2017. MD-IDN:
Multi-domain intent-driven networking in software-dened infrastructures. In
13th International Conference on Network and Service Management (CNSM). 1–7.
N Feamster, J Rexford, and E Zegura. 2014. The Road to SDN: An Intellectual
History of Programmable Networks. SIGCOMM Comput. Commun. Rev. 44, 2
(April 2014), 87–98.
M Kiran, E Pouyoul, A Mercian, B Tierney, C Guok, and I Monga. 2018. Enabling
intent to congure scientic networks for high performance demands. Future
Generation Computer Systems 79 (2018), 205–214.
R Kumar, D Tandur, and M Kande. 2013. Performance evaluation of Field De-
vice Integration (FDI) framework. In 2013 International Conference on Control,
Automation and Information Sciences (ICCAIS). 178–183.
A Marsico, M Santuari, M Savi, D Siracusa, A Ghafoor, S Junique, and P Skold-
strom. 2017. An interactive intent-based negotiation scheme for application-
centric networks. In 2017 IEEE Conference on Network Softwarization (NetSoft).
C Prakash, J Lee, Y Turner, J.-M Kang, A Akella, S Banerjee, C Clark, Y Ma, P
Sharma, and Y Zhang. 2015. PGA: Using Graphs to Express and Automatically
Reconcile Network Policies. In Proceedings of the 2015 ACM Conference on Special
Interest Group on Data Communication (SIGCOMM ’15). ACM, New York, NY,
USA, 29–42.
B. K Saha and S Misra. 2016. Named Content Searching in Opportunistic Mobile
Networks. IEEE Communications Letters 20, 10 (Oct 2016), 2067–2070.
B. K Saha, S Misra, and S Pal. 2016. Utility-Based Exploration for Performance
Enhancement in Opportunistic Mobile Networks. IEEE Trans. Comput. 65, 4
(April 2016), 1310–1322.
B. K Saha, S Misra, and S Pal. 2017. SeeR: Simulated Annealing-Based Routing in
Opportunistic Mobile Networks. IEEE Transactions on Mobile Computing 16, 10
(Oct 2017), 2876–2888.
T Subramanya, R Riggio, and T Rasheed. 2016. Intent-based mobile backhauling
for 5G networks. In 2016 12th International Conference on Network and Service
Management (CNSM). 348–352.
Y Tsuzaki and Y Okabe. 2017. Reactive conguration updating for Intent-Based
Networking. In 2017 International Conference on Information Networking (ICOIN).
A Varghese and D Tandur. 2014. Wireless requirements and challenges in Industry
4.0. In 2014 International Conference on Contemporary Computing and Informatics
(IC3I). 634–638.
H Zhang, Y Wang, X Qi, W Xu, T Peng, and S Liu. 2017. Demo abstract: An
intent solver for enabling intent-based SDN. In 2017 IEEE Conference on Computer
Communications Workshops (INFOCOM WKSHPS). 968–969.
... In the recent years intent-based networking (IBN) has been the emerging networking paradigm, levering the integration of AI/ML techniques with network orchestration to improve upon the network automation, complexity and control functionalities. Compared to traditional network management solutions it has shown great potential in numerous aspects, reducing the time for network configuration deployment while improving on its scalability [1], increasing both the efficiency and reliability, as well as reducing costs in particularly complex industrial networks [2] and integrating security through its intent functions [3]. The key behind IBN's increasing abilities to solving complex network tasks lies is in their highlevel policies specification capabilities that allow network administrator to define goals and demands on how the network should behave. ...
... 3) Manager/Parser: In the [2], authors have recognized a core component of IBNs, which interacts with most of the other components, naming it an Intent Processor. This core component is responsible for accepting high level intents expressed by users (applications) using a semantic language or through other appropriate user interfaces. ...
... Firstly, the question of leveraging the potential of natural language processing (NLP) [28] in improving humanmachine interactions in SCM should be addressed. Secondly, as supply chains are particularly important from industrial networks perspective, in case of an incident it is a requirement to obtain the explanation behind it, which can be difficult in case it is a consequence of an IBN automated algorithm reaction [2]. ...
... network policy, network service, network configuration, a new application, etc.) [7]. Furthermore, communication networks are not only used in IT related industries but in every single business domain [8]. This has as a consequence that an intent that is comprehensible by one IBNS may be inscrutable by another. ...
... Policies are usually handled by Policy Based Management (PBM) Systems, where policies can be defined, consumed and translated [17]. Even though policies are more well defined 8 than intents, they can still be high-level declarations and a rendering mechanism is needed to translate them into lowlevel configurations that need to be pushed into the network equipment (policy enforcement). For example, a policy can state "Connect point A with point B through shortest path as long as the packet drop rate is below 0.1%. ...
Current and future network services and applications are expected to revolutionize our society and lifestyle. At the same time, the abundant possibilities that new network technologies offer to end users, network operators and administrators have created a cumbersome network configuration process to accommodate all different stakeholders and applications. Thus, lately, there is a need to simplify the management and configuration of the network, through possibly an autonomic and automatic way. Intent Based Networking (IBN) is such a paradigm that envisions flexible, agile, and simplified network configuration with minimal external intervention. This paper provides a detailed survey of how the IBN concept works and what are the main components to guarantee a fully autonomous IBN system (IBNS). Particular emphasis is given on the intent expression, intent translation, intent resolution, intent activation and intent assurance components, which form the closed loop automation system of an IBNS. The survey concludes with identifying open challenges and future directions of the problem at hand.
... The problem is discussed in Section III. Section IV Fig. 1: A scaled-down version of IBNs, based on the architecture proposed by Saha et al. [5]. ...
Conference Paper
Full-text available
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.
Conference Paper
Full-text available
Industry 4.0 has witnessed a widespread use of Artificial Intelligence (AI), which, however, often focuses on the operational aspects. In contrast, the life-cycle of any industrial project begins much earlier. Motivated by this, we present an intent-based approach toward bid engineering. In particular, we consider the use of AI to automatically extract the intended specifications—technical and non-technical—of customers from Requests for Proposals (RFPs) by defining relevant data models. Subsequently, we annotate texts from real-life RFPs to train an AI model. In addition, we also design RfpAnno, an end-to-end solution to annotate documents, train models, and extract specifications as structured data. Experimental results indicate that the AI model has about 85% precision and recall, on average, using the test data set. Overall, RfpAnno can potentially reduce the time and effort required by bid engineers to manually copy requirements from RFPs.
Machine learning has been widely studied and practiced in data center networks, and a large number of achievements have been made. In this chapter, we will review, compare, and discuss the existing work in the following research areas: flow prediction, flow classification, load balancing, resource management, energy management, routing optimization, congestion control, fault management, network security, and new intelligent networking concepts.
The possibility of applying the new intention-based networking (IBN) paradigm to the efficient functioning of information processes in cyber-physical systems (CPS) leads to the need to consider new security threats. This article discusses the purpose and main characteristics of IBN. IBN provides a transition from a device-centric network model to a business-centric model operating at a higher level of abstraction. The main differences between IBN and the traditional approach to the construction of network architectures are highlighted, the main advantages of the use of IBN are stated. They consist in providing a more flexible operation of network technologies and optimization of their performance, as well as ensuring compatibility of network technologies through algorithmic management of the configuration of the network. The actual researches in the field of security of such networks are analyzed, the main security problems, arising during the transition to the construction of network infrastructures on IBN paradigm are marked.
Full-text available
Quite often, developers face low performance, hanging, and other problems when they’re developing sites. To solve such problems, we need to trace site requests. Existing tracing methods do not allow tracing the progress of requests from a client’s web browser to a server or group of servers. In this paper, we propose distributed tracing mechanism that allows tracking requests starting from the browser. For generating complete client-to-server tracing, the client application must be able to initiate the appropriate request. For the execution of these actions, we need to use a unique library. In the paper, we consider the algorithm of such a library. A popular tracer (OpenTracing) is used on the serverside. Based on the proposed methodology, a library was developed. The library's work was tested. Testing has shown that using the library, and we can track the complete chain of requests from a browser to the server. Trace result is presented in graphical view. This allows analyzing received data and finding bottlenecks when queries are passing. The novelty of the proposed solution is that the request is traced from the client application and to the client application. That is, the full path of the request is shown. The result is presented in a graphical form that is convenient for analysis. The library is designed primarily for the development of client-server applications and for support services.
Commonly, the network configuration leans upon the operators’ experience to operate network, including command-line configuration, middle-ware scripts, and troubleshooting. However, with the rise of neoteric B5G services, the manual way lacks flexibility and timeliness, resulting in an unsatisfactory level of configuration. It is necessary to consider a manual free configuration way for transport network. To cope with this problem, we present an intent-driven network architecture with self-adapting slicing policy and slices reconfiguration in an intent-orient manner. Aiming at intent request, intent analysis based on latent dirichlet allocation is introduced to establish the semantic graph to comprehend and enact the required slicing configuration language, namely intent translation. Then, in line with intent translation, we propose a self-adapted slicing policy generation and optimization base on deep reinforcement learning (SPG-RL) to find combined strategies that meet the intent requirements by dynamically integrating fine-grained slicing policies. Finally, deep neural evolution network (DNEN)-assisted model (SPG-RL-DNEN) is introduced to locate the incompatible slices at the millisecond level for slicing reconfiguration. When the network entropy reaches the threshold, SPG-RL-DNEN would reconfigure the incompatible slices for intent guarantee. The efficiency of our proposal are verified on enhanced SDN testbed.
Conference Paper
Full-text available
The demonstration presents the first implementation of a resource negotiation scheme between users and a network for the provisioning of application-aware connectivity services. This active interaction enables the users, who request connectivity services with multiple application requirements, to select an alternative solution when the network does not have enough resources to satisfy the original requests.
Full-text available
Opportunistic Mobile Networks (OMNs) are characterized by intermittent connectivity among nodes. In many scenarios, the nodes attempt at local decision making based on greedy approaches, which can result in getting trapped at local optimum. Moreover, for efficient routing, the nodes often collect and exchange lot of information about others. To alleviate such issues, we present SeeR, a simulated annealing-based routing protocol for OMNs. In SeeR, each message is associated with a cost function, which is evaluated by considering its current hop-count and the average aggregated inter-contact time of the node. A node replicates a message to another node, when the latter offers a lower cost. Otherwise, the message is replicated with decreasing probability. Moreover, SeeR works based solely upon local observations. In particular, a node does not track information about other nodes, and, therefore, reduces the risk of privacy leaks unlike many other protocols. We evaluated the performance of SeeR by considering several real-life traces under plausible conditions. Experimental results show that, in the best case, SeeR can reduce the average message delivery latency by about 58%, when compared to other popular routing protocols.
Conference Paper
Full-text available
Intent–based networking is a major component that will transform the manner in which the SDN/NFV–enabled future network infrastructures are operated. In particular, Intent-based networking is expected to play a major role in the multi– technological and software–defined 5G systems development roadmap. In this paper, we present the design and prototype implementation of an Intent–based mobile backhauling interface for 5G networks. We also report on the empirical evaluation of of the proposed Intent–based interface over a small Enterprise WLAN. We also release the entire software stack under a permissive license for academic use.
Conference Paper
Existing network policy abstractions handle basic group based reachability and access control list based security policies. However, QoS policies as well as dynamic policies are also important and not representing them in the high level policy abstraction poses serious limitations. At the same time, efficiently configuring and composing group based QoS and dynamic policies present significant technical challenges, such as (a) maintaining group granularity during configuration, (b) dealing with network-bandwidth contention among policies from distinct writers and (c) dealing with multiple path changes corresponding to dynamically changing policies, group membership and end-point mobility. In this paper we propose Janus, a system which makes two major contributions. First, we extend the prior policy graph abstraction model to represent complex QoS and dynamic tateful/temporal policies. Second, we convert the policy configuration problem into an optimization problem with the goal of maximizing the number of satisfied and configured policies, and minimizing the number of path changes under dynamic environments. To solve this, Janus presents several novel heuristic algorithms. We evaluate our system using a diverse set of bandwidth policies and network topologies. Our experiments demonstrate that Janus can achieve near-optimal solutions in a reasonable amount of time.
Globally distributed scientific experiments involve movement of massive data volumes and many collaborators performing distributed data analysis. With complex workloads and heterogeneous resources, each user may desire certain behavior characteristics for their network paths. In this paper, we present the iNDIRA tool, which interacts with SDN north-bound interfaces to enable intent-based networking. It provides reliable, simple, and technology-agnostic communication between users and networks. Focusing particularly on science applications, iNDIRA uses natural language processing to construct semantic RDF graphs to understand, interact, and create the required network services. The technical challenges addressed by iNDIRA are: (1) development of a high-level descriptive language to query network-application requirements, (2) provides keyword identification and condition checking based on user profiles and topology details, (3) allows user negotiation based on the current network state, and (4) integrates network provisioning and service tools used by the application. iNDIRA is implemented on the ESnet network, where it interacts with OpenNSA (aka the NSI client) and Globus data transfer tools, to build complex cross-domain network paths for heterogeneous science applications, and perform secure data transfer. We argue that iNDIRA’s approach presents users with an alternative approach to interact and communicate their network demands, allowing seamless network service integration.
Conference Paper
Software Defined Networking (SDN) and cloud automation enable a large number of diverse parties (network operators, application admins, tenants/end-users) and control programs (SDN Apps, network services) to generate network policies independently and dynamically. Yet existing policy abstractions and frameworks do not support natural expression and automatic composition of high-level policies from diverse sources. We tackle the open problem of automatic, correct and fast composition of multiple independently specified network policies. We first develop a high-level Policy Graph Abstraction (PGA) that allows network policies to be expressed simply and independently, and leverage the graph structure to detect and resolve policy conflicts efficiently. Besides supporting ACL policies, PGA also models and composes service chaining policies, i.e., the sequence of middleboxes to be traversed, by merging multiple service chain requirements into conflict-free composed chains. Our system validation using a large enterprise network policy dataset demonstrates practical composition times even for very large inputs, with only sub-millisecond runtime latencies.
Software Defined Networking (SDN) and cloud automation enable a large number of diverse parties (network operators, application admins, tenants/end-users) and control programs (SDN Apps, network services) to generate network policies independently and dynamically. Yet existing policy abstractions and frameworks do not support natural expression and automatic composition of high-level policies from diverse sources. We tackle the open problem of automatic, correct and fast composition of multiple independently specified network policies. We first develop a high-level Policy Graph Abstraction (PGA) that allows network policies to be expressed simply and independently, and leverage the graph structure to detect and resolve policy conflicts efficiently. Besides supporting ACL policies, PGA also models and composes service chaining policies, i.e., the sequence of middleboxes to be traversed, by merging multiple service chain requirements into conflict-free composed chains. Our system validation using a large enterprise network policy dataset demonstrates practical composition times even for very large inputs, with only sub-millisecond runtime latencies.