This item was downloaded from IRIS Università di Bologna (https://cris.unibo.it/)
When citing, please refer to the published version.
This is the final peer-reviewed accepted manuscript of:
F. Esposito, J. Wang, C. Contoli, G. Davoli, W. Cerroni and F. Callegati, "A Behavior-
Driven Approach to Intent Specification for Software-Defined Infrastructure
Management," 2018 IEEE Conference on Network Function Virtualization and
Software Defined Networks (NFV-SDN), Verona, Italy, 2018, pp. 1-6.
The final published version is available online at DOI:
https://doi.org/10.1109/NFV-SDN.2018.8725754
Rights / License:
The terms and conditions for the reuse of this version of the manuscript are specified in the
publishing policy. For all terms of use and more information see the publisher's website.
A Behavior-Driven Approach to Intent Specification
for Software-Defined Infrastructure Management
Flavio Esposito
∗
, Jiayi Wang
∗
, Chiara Contoli
†
, Gianluca Davoli
†
, Walter Cerroni
†
, Franco Callegati
†
∗
Saint Louis University, USA
†
University of Bologna, Italy
{flavio.esposito,holly.wang}@slu.edu {chiara.contoli,gianluca.davoli,walter.cerroni,franco.callegati}@unibo.it
Abstract—One of the goals of Software-Defined Networking
(SDN) is to allow users to specify high-level policies into lower
level network rules. Managing a network and decide what policy
set is appropriate requires, however, expertise and low level
know-how. An emerging SDN paradigm is to allow higher-
level network level decisions wishes in the form of “intents”.
Despite its importance in simplifying network management,
intent specification is not yet standardized. In this work, we
propose a northbound interface (NBI) for intent declaration,
based on Behavior-Driven Development. In our approach, intents
are specified in plain English and translated by our system into
pre-compiled network policies, that are in turn, converted into
low-level rules by the software-defined infrastructure e.g. an SDN
controller. We demonstrated our behavior-driven approach with
two practical use cases: service function chaining deployed on
OpenStack, supported by both ONOS and Ryu controllers, and
dynamic firewall programming. We also measured the overhead
and response time of our NBI. We believe that our approach is
far more general and paves the way for a more expressive and
simplified northbound interface for intent-driven networking.
I. INTRODUCTION
The Network Function Virtualization (NFV) paradigm advo-
cates moving middlebox functionality — Network Functions
(NFs) — from dedicated hardware devices to software ap-
plications that run in virtual environments on top of shared
hardware [1]. One of the key paradigms to effectively sup-
port the deployment of NFV is Software-Defined Networking
(SDN), which enables network programmability by taking
advantage of (mostly) vendor-agnostic open application pro-
gramming interfaces (APIs) [2]. Sharing similar goals with
researchers in programming languages, the focus of network
programmability has typically been on (i) making (network)
programming easier and more accessible, or (ii) to enable
safer (network) programming, e.g., via formal methods and
verification techniques. Several successful attempts were made
to make network programming safer [3]–[5], or easier to
debug and test [6]–[8]. Most of these approaches rely on
OpenFlow [9], which defines the open southbound API to-
wards network equipment. Despite the successful control-
plane decoupling between programming directives and vendor-
specific data forwarding mechanisms, OpenFlow — the de-
facto standard SDN control plane protocol — is still dependent
on low-level technical details for correct data forwarding, such
as switch IDs, port numbers, MAC addresses, etc.
With the aim of generalizing network programmability
operations, researchers today are seeking new ways to manage
Software-Defined Infrastructures (SDIs) — including SDN and
NFV environments, cloud computing platforms, and any other
form of communication infrastructure controlled by software.
The main goal is to define a simple and usable northbound
interface (NBI) that provides a high level of abstraction
for programming SDI controllers and easily deploying new
services. Such NBI could be in many cases helpful to make
network programming easier to application developers and
network administrators running DevOps, but also to allow
personnel with less technical skills, e.g. business managers or
technical group leaders, to specify a desired set of operations
or services by merely knowing some (but not many) low-level
aspects.
To inspire the design of such NBI, the Open Networking
Foundation has loosely defined the notion of intent as a
form of network service abstraction at a higher level than
typical policy instantiation or composition in SDIs [10]. In
literature the words “policies” and “intents” have often been
used interchangeably, see for instance [11]. Differently, in this
paper by intent we mean a high-level predicate or keyword
that can be used to program a mechanism directly, or via
instantiation of a policy set. The idea of having an intent-
based network interface is then to declaratively allow “what
should be achieved,” either loosely or tightly, with a high-level
description rather than with a detailed specification of “how it
should be achieved.”
A key challenge that has yet to be addressed, which we plan
to tackle in this paper, is how to provide an intuitive intent pro-
gramming northbound abstraction for SDIs that, even though
not being rigorous as a programming language, is simple and
expressive enough to deploy service policies and mechanisms
on top of any SDI, without requiring neither network operator
expertise nor heavy programming experience.
Recent work attempted at defining domain-specific lan-
guages for network programmability, raising the level of
abstraction [11]–[16]. Although those solutions focus on high-
level policies expression, they still require knowledge of differ-
ent low-level details, e.g., the declarative or functional syntax
of the specification language. Such languages or abstractions
for northbound interfaces: (i) are not simple to use, (ii)
focus on policy specification, not intent, and (iii) still require
underlying mechanisms expertise, merely shifting the entry
barrier for network programmability without lowering it.
Two more recent solutions share at the high level our same
design goals [17], [18]. They both attempt to use human
semantics of a text in English to abstract out the low-level
details of a network; these solutions require to either use
a Natural Language Processing [17] or to solve a complex
optimization problem to interpret a set of intents (despite not
calling them intents) [18].
Our Contributions. In this paper, we design and implement
a NBI abstraction layer for SDI management where intents can
be specified in plain English (or even Mandarin Chinese).
1
Our design principle is based on Behavior-Driven Develop-
ment (BDD) [19], an agile software development technique,
corollary of the Test-Driven Development paradigm [20]. A
Behavior-Driven Development framework provides the ability
of expressing (network level) wishes in a simple way, i.e.,
using natural language. The expressed wishes, in our case
intents, are then translated into (SDI) policies and implemented
through relevant network mechanisms by means of appropriate
interpreter functionalities. Our focus in this paper is to demon-
strate how it is feasible to allow network programmability
without having to be familiar with the lower level details of
any policy of the underlying SDI.
To this end, we prototyped our approach by applying the
behavior-driven, intent-based SDI management to two practi-
cal use cases: (i) service function chaining on a NFV environ-
ment, deployed on the OpenStack cloud platform,
2
integrating
our BDD layer with an interpreter that manages two different
SDN controllers — ONOS
3
and Ryu;
4
(ii) dynamic firewall
programming with iptables, the native Linux Kernel packet
filtering software tool. While the former use case refers to the
management of a relatively complex SDI, facilitated by the
use of off-the-shelf cloud and SDN controllers, we decided to
include the latter use case to demonstrate that our approach
is not limited to an OpenFlow-based SDN environment to
translate high level intents into policies [21].
How are we different? We are different from the afore-
mentioned relevant work [17], [18] for two main reasons. The
first is that we not only focus on defining an intent-based
NBI taking advantage of natural language features, but we also
consider the support of previously compiled underlying net-
work behaviors. To interpret (or compile) any general English
(or Mandarin) sentence and translate it into an action would
be infeasible [22]. Instead, by restricting the scope of our
framework to pre-defined feasible behaviors, we enable SDI
management to expressed and verified in the form of intents
following the Behavior-Driven Development philosophy. The
second main difference with existing approaches is that we
prove our concept on several application scenarios based on
off-the-shelf SDI software tools demonstrating the flexibility
of our solution.
The rest of the paper is organized as follows: In Section II
we describe our behavior-driven intent NBI design. Then in
Section III we describe the workflow of an intent specification,
while in Section IV we discuss some implementation details of
1
Our approach can easily support different languages.
2
http://openstack.org
3
https://onosproject.org
4
https://osrg.github.io/ryu
Gherkin Parser
Intent Specification (Gherkin Language)
Step Function Step Function
SDI Management Tool
OpenStack Ryu ONOS
iptables
Cloud Infrastructure Firewall
BDD
SDI
Intent-Policy
Interpreter
Intent
Processor
Policy
Actuator
Fig. 1. Behavior-driven intent specification architecture for SDI management.
Intents specified in English using the Gherkin language are interpreted by the
Gherkin parser and translated by step functions into policies in the form of
instructions for the underlying SDI management tools. The picture shows
the specialized architecture for the case of a SDI based on NFV and SDN
components, as well as the case of a firewall programmed with iptables.
the considered use cases. In Section V we detail the evaluation
of our approach, and we conclude in Section VI.
II. BEHAVIOR-DRIVEN INTENT SPECIFICATION DESIGN
In this section we highlight the main components of our
behavior-driven approach and its design principles. Our intent
specification layer is composed by (i) a language definition
framework based on Gherkin, (ii) an intent-policy interpreter,
the core of our northbound interface, and (iii) a set of plugins
that act as a middleware between the intent declaration and
the underlying SDI management layer. The system architec-
ture, specialized for the use cases presented in this paper, is
represented in Figure 1.
Intent definition in plain English with Gherkin. Behavior-
driven development (or BDD) is an agile software devel-
opment technique that was designed to encourage collab-
oration between developers, Quality Assurance (QA) engi-
neers and non-technical or business participants in a software
project [19]. We extended the BDD notion to behavior-driven
SDI management, by focusing its general notion of declar-
ative requirement specification to network programmability
via intent specification. We define our network intents with
Gherkin,
5
a language used by non-computer scientists to define
requirements in plain English. The following listing shows an
example of Gherkin-generated intent that is possible to specify
with our framework:
F e a t u r e : l o a d b a l a n c i n g v i a NFV
S c e n a r i o : mo dify NF c h a i n a f t e r h i g h l o a d
d e t e c t i o n
Giv en t r a f f i c i s f l o w i n g on NF1
And t r a f f i c i s fl o w i n g on s w i t c h SW1
When r e s p o n s e t ime of NF1 i s t o o hig h
Then s t a r t a new n e tw o r k f u n c t i o n NF2
And r e d i r e c t h a l f o f t h e t r a f f i c t o NF2
Gherkin was designed so that business (not network) man-
agers would be allowed to express application or service
requirements with little but not null technical expertise. For
5
https://docs.cucumber.io/gherkin
example, a network manager may want to subsequently author
such feature with the aim of expressing another policy to
perform load balancing when the end-to-end delay becomes
higher than a given threshold. The keywords Given, When,
Then, And, are sufficient to compose complex intent predi-
cates, and the language interpreter can be easily extended.
Having shown a concrete example of how simple our
approach can be to specify network intents, we continue this
section describing its three design principles: (i) usability, (ii)
being verification-agnostic, and (iii) being controller-agnostic.
Usability. Users, managers, applications and network pro-
grammers have to have the ability to quickly start, stop or
modify basic or complex service behaviors on the SDI, with
minimal coding and network management expertise. It is
then responsibility of the interpreter to convert those English
sentences into a policy set that can be used to program the
underlying SDI via northbound API. Note how existing SDN
controllers, such as ONOS, already have an intent specification
NBI, but programming intents requires low-level expertise.
Verification-agnostic. When we program in a dynamically-
typed language such as Python or JavaScript, we do not have
any proof that the program will be safe. It is (arguably) clear
that writing Python code is easier for newbies. Developers do
however, write unit or integration tests to verify correctness
of their code. Similarly, our intent management layer does
not use any formal verification techniques, but can be used to
verify software-defined network behaviors. For example, we
could specify intents that ensure that a given packet header is
generated after another one is received by a given NF.
Controller-agnostic. Existing intent specification frameworks
are controller-specific. Successful abstractions are by defini-
tion agnostic from the underlying software-defined infrastruc-
ture. In the rest of the paper we show how our approach
can adapt to different controllers and to networks that do not
support a centralized controller.
III. INTENT INTERPRETATION WORKFLOW
In this section, we describe the general workflow of an intent
specification when applied to the use case of a service function
chain deployment. To apply an intent, the workflow first has
to input the specification of the intent in plain (English) text,
and then our intent-policy interpreter binds the policy to the
underlying SDI management tool, e.g., the Ryu and/or ONOS
controllers.
A. General Workflow
Our intents are specified using the Gherkin language, which
enables the description of the desired (virtual) network chain
or other service behavior. Business and network managers
may leverage Gherkin to describe the feature they desire.
Features can represent higher level goals, as well as lower
level protocol policies (i.e., NFV constraints on the software-
defined infrastructure). A feature file may or may not start
with a title, used as tag to group set of intents, and it is
followed by a few lines that provide context and describe the
benefits or the feature itself. A Gherkin specification envisages
a scenario and (possibly) multiple steps; the details of the
intent specifications start with a Gherkin keyword that has the
purpose of providing some context or preconditions, and define
what managers should expect as outcome. Outcomes can be
tests, protocol messages, logs, network service deployment or
termination.
With our approach, not only we are able to express higher-
level intents using Gherkin keywords, but also terms that are
relevant to specific use cases scenarios. Examples of such
terms are those that describe service flows crossing function
chain components, or firewall-ing states, e.g., incoming/outgo-
ing/malicious/dangerous traffic, or blacklist. All those terms
are seen as keywords for each relevant scenario. Such terms
or keywords constitute the information set adopted to achieve
infrastructure-independence in the intent specification, as well
as to implement mappings among layer-specific terms. Once
the intent specification is complete, it is interpreted by our
engine, capable of matching previously defined regular expres-
sions, just as in a standard programming language compiler.
When there is a matching, our interpreter translates the
intents into policies by calling the appropriate callback func-
tion that in turn may call an underlying mechanism. Our
approach may be supported by any SDN controller exposing a
programmable NBI — although our current implementation
6
is limited to ONOS and Ryu only — as well as by any other
form of network programmability.
B. Chain Intent Interpretation Workflow
Let us assume that a user, e.g., a startup CTO, a technical
leader or a network manager, wishes to enforce an intent
defined by the deployment of a service function chain on
their infrastructure. The ordered set of network functions
will be implemented on an SDI by means of an OpenFlow-
based controller. The controller, responsible for translating the
service function chain policy into lower-level infrastructure
rules, will then deploy the required service.
With our system, the user, through a user interface such as
a keyboard (or a script), expresses such intent with Gherkin
syntax, defining a feature file. Together with this file, to
support the intent specification, a set of rules called step
functions need to be implemented by the system interpreter.
These steps functions are interpreter functionalities and act as
callbacks; their signature has a regular expression that needs
to be matched against the text subsequent to a defined Gherkin
keyword in the feature (intent) file. For instance, in our use
case the system interpreter generates from the intent/feature
file a JSON policy configuration file that is then sent to
the SDI management tool through a REST API call [23].
The management tool runs an application that exposes the
service function chaining service as a REST API endpoint.
Once such call is received, it is responsibility of the SDI
management tool to translate this policy into lower level rules
that will be applied to the underlying infrastructure through
the ONOS/Ryu controller NBIs. We implemented and tested
this example, as presented in the following sections.
6
https://github.com/flavioesposito/BeA
br-ex
Network/Controller/Compute1
br-tun
br-int
Compute2
br-tun
br-int
OVS0
Compute3
br-tun
br-int
Data network
TAP Interface
Ryu
Ryu
Ryu
Ryu
ONOS
Linux bridge
Veth pair MV side
Veth pair br side
Open vSwitch
Physical interface
Network namespace
Hypervisor domain
Fig. 2. OpenStack cluster used as a SDI to demonstrate our behavior-
driven intent specification for service function chaining. The figure shows
the internals of the compute nodes, with virtual bridges natively controlled
by Ryu instances, as well as the physical data network interconnection through
an OpenFlow-enabled switch controlled by ONOS.
IV. PROTOTYPE IMPLEMENTATION AND TESTBED
We prototyped our intent specification approach leveraging
the BDD framework
7
and implementing our own interpreter.
We tested our interpreter over an SDI management tool,
controlling an OpenStack cloud platform used to execute
virtual network functions (VNFs) and two OpenFlow-
based SDN controllers to properly steer traffic flows.
Moreover, to demonstrate the flexibility of our approach,
we also implemented support for intent translation within
an infrastructure without controllers. In particular, we
demonstrated a use case in which intents are translated
to iptables (firewall and forwarding) rules. Both the
OpenFlow and the non-OpenFlow use cases are integrated
with the framework and interact with the underlying SDI via
the interpreter
8
.
Deploying Service Function Chains on OpenStack. As part
of our evaluation, we developed the SDI management tool
as a standalone Python plugin that interacts with the cloud
operating system (OS). We choose OpenStack, but our code
can be ported on any other cloud OS. Our plugin gathers
information to monitor the deployed VNFs used to build a
service chain. We use multiple SDN controllers to install
customized forwarding paths between the VNFs, as dictated
by an intent-based service chain specification. The plugin uses
the REST interface that the cloud OS and the SDN controllers
provide and expose, and the intent-based northbound interface
(also REST) to communicate with any logically higher-level
component, or to users themselves.
A typical OpenStack cluster includes, among other el-
ements, multiple compute nodes, each of which can host
7
https://github.com/behave/behave
8
Our code is available at https://github.com/flavioesposito/BeA
virtual machine or container instances. The OpenStack test
bed we used in our experiments is shown in Figure 2 and
is composed by a network node co-located with a controller
and a compute node, plus two additional compute nodes.
Each node includes several virtual elements that form the
internal network infrastructure. A set of Open vSwitch (OvS)
virtual bridges provide a programmable, distributed virtual
networking environment. In recent releases of OpenStack, each
compute node also runs an instance of the Ryu SDN controller,
used for controlling the internal virtual network components.
With a minor intervention on the OpenStack configuration
files, it is possible to expose the Ryu REST interface, allowing
direct interaction with the controller and facilitating intra-node
network programmability in a native way. In our test bed,
the connectivity between OpenStack nodes is provided by a
flat data network interconnected via an OvS bridge running
on a dedicated server and controlled by an ONOS instance.
Therefore, in our deployment the interaction with both Ryu
and ONOS controllers allows management of intra-node and
inter-node traffic steering, respectively.
V. EVALUATION RESULTS
In this section, we present some experimental results with
the aim of demonstrating the feasibility of our Behavior-
driven approach. First, we provide some basic performance
analysis of our framework, to demonstrate the NBI overhead:
to support from 100 to 1000 intents the processing time
increases from less than 1 second to about 7 seconds,
respectively (Figure 3). We obtained this result by measuring
the intent processor compile time independently from the
underlying SDI.
Intent-based firewall programming with iptables. To
demonstrate that our approach can be used even in absence
of an SDN management platform, we injected firewall intents
via our NBI that are interpreted by iptables and enforced
by the netfilter framework.
9
In particular, our intents have a
goal of adding and/or removing IP addresses from built-in
whitelist and blacklist to update a firewall dynamically. We
use the iperf utility to generate and send traffic to all hosts.
Figure 4 shows the effect of dynamic firewall programming.
As soon as an intent updates any of these lists, packets will
start to be delivered (or stopped to be delivered in case of a
new blacklisted IP) to the target host. For each of the three
scenarios (whitelisted, blacklisted and blacklisted/whitelisted),
our test lasted 10 seconds, while each intent-policy translation
change occur around time equal to 5 seconds.
OpenStack-based Service Function Chaining. To evaluate
this use case, we launched a set of intents that define an
ordered list of VNFs composing a given service chain. We
first show how the service traffic is successfully steered across
the specified VNF chain. Then we measure the response time
of the different layers involved in the intent specification and
9
https://www.netfilter.org
