scispace - formally typeset

Proceedings ArticleDOI

A Behavior-Driven Approach to Intent Specification for Software-Defined Infrastructure Management

01 Nov 2018-pp 1-6

TL;DR: This work proposes a northbound interface (NBI) for intent declaration, based on Behavior-Driven Development, and believes that this approach is far more general and paves the way for a more expressive and simplified northbound interfaces for intent-driven networking.

AbstractOne 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.

Summary (2 min read)

Introduction

  • The Network Function Virtualization (NFV) paradigm advocates moving middlebox functionality — Network Functions (NFs) — from dedicated hardware devices to software applications that run in virtual environments on top of shared hardware [1].
  • One of the key paradigms to effectively support the deployment of NFV is Software-Defined Networking (SDN), which enables network programmability by taking advantage of vendor-agnostic open application programming interfaces (APIs) [2].
  • 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].
  • The authors are different from the aforementioned relevant work [17], [18] for two main reasons.
  • Instead, by restricting the scope of their framework to pre-defined feasible behaviors, the authors enable SDI management to expressed and verified in the form of intents following the Behavior-Driven Development philosophy.

II. BEHAVIOR-DRIVEN INTENT SPECIFICATION DESIGN

  • In this section the authors highlight the main components of their behavior-driven approach and its design principles.
  • //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, also known as For 5https.
  • The keywords Given, When, Then, And, are sufficient to compose complex intent predicates, and the language interpreter can be easily extended.
  • Having shown a concrete example of how simple their approach can be to specify network intents, the authors continue this section describing its three design principles: (i) usability, (ii) being verification-agnostic, and (iii) being controller-agnostic.
  • It is clear that writing Python code is easier for newbies.

A. General Workflow

  • The authors intents are specified using the Gherkin language, which enables the description of the desired network chain or other service behavior.
  • A Gherkin specification envisages a scenario and 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.
  • 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 their engine, capable of matching previously defined regular expressions, just as in a standard programming language compiler.

B. Chain Intent Interpretation Workflow

  • The controller, responsible for translating the service function chain policy into lower-level infrastructure rules, will then deploy the required service.
  • With their system, the user, through a user interface such as a keyboard (or a script), expresses such intent with Gherkin syntax, defining a feature file.
  • 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 file.
  • In their 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 authors implemented and tested this example, as presented in the following sections.

IV. PROTOTYPE IMPLEMENTATION AND TESTBED

  • The authors prototyped their intent specification approach leveraging the BDD framework7 and implementing their own interpreter.
  • The authors tested their interpreter over an SDI management tool, controlling an OpenStack cloud platform used to execute virtual network functions (VNFs) and two OpenFlowbased SDN controllers to properly steer traffic flows.
  • Moreover, to demonstrate the flexibility of their approach, the authors also implemented support for intent translation within an infrastructure without controllers.
  • The OpenStack test bed the authors used in their 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.
  • 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.

V. EVALUATION RESULTS

  • The authors present some experimental results with the aim of demonstrating the feasibility of their Behaviordriven approach.
  • The authors first show how the service traffic is successfully steered across the specified VNF chain.
  • Then the authors measure the response time of the different layers involved in the intent specification and 9https://www.netfilter.org interpretation, as well as in the resulting policy enforcement in the underlying SDI.
  • Then the authors send the Adaptive Service Function Chaining intent specification listed above to the parser.

VI. CONCLUSION

  • In this paper the authors presented a northbound interface solution for network intent specification based on Behavior-Driven Development.
  • The authors approach allows intent expressiveness in English, Mandarin, or any other natural language, by leveraging the Gherkin programming language.
  • The authors prototype includes an intent processor, an intent-policy interpreter, and several Software-defined infrastructure specific policy actuators.
  • To demonstrate the feasibility, practicality and portability of their approach, the authors prototyped it over two practical use cases: service function chaining deployed on OpenStack, supported by both ONOS and Ryu controllers, and dynamic firewall programming.
  • The authors also found that the overhead and response time of their NBI scales reasonably well with up to 1000 intents.

Did you find this useful? Give us your feedback

...read more

Content maybe subject to copyright    Report

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

Figures (7)
Citations
More filters

Book
01 Nov 2002
TL;DR: Drive development with automated tests, a style of development called “Test-Driven Development” (TDD for short), which aims to dramatically reduce the defect density of code and make the subject of work crystal clear to all involved.
Abstract: From the Book: “Clean code that works” is Ron Jeffries’ pithy phrase. The goal is clean code that works, and for a whole bunch of reasons: Clean code that works is a predictable way to develop. You know when you are finished, without having to worry about a long bug trail.Clean code that works gives you a chance to learn all the lessons that the code has to teach you. If you only ever slap together the first thing you think of, you never have time to think of a second, better, thing. Clean code that works improves the lives of users of our software.Clean code that works lets your teammates count on you, and you on them.Writing clean code that works feels good.But how do you get to clean code that works? Many forces drive you away from clean code, and even code that works. Without taking too much counsel of our fears, here’s what we do—drive development with automated tests, a style of development called “Test-Driven Development” (TDD for short). In Test-Driven Development, you: Write new code only if you first have a failing automated test.Eliminate duplication. Two simple rules, but they generate complex individual and group behavior. Some of the technical implications are:You must design organically, with running code providing feedback between decisionsYou must write your own tests, since you can’t wait twenty times a day for someone else to write a testYour development environment must provide rapid response to small changesYour designs must consist of many highly cohesive, loosely coupled components, just to make testing easy The two rules imply an order to the tasks ofprogramming: 1. Red—write a little test that doesn’t work, perhaps doesn’t even compile at first 2. Green—make the test work quickly, committing whatever sins necessary in the process 3. Refactor—eliminate all the duplication created in just getting the test to work Red/green/refactor. The TDD’s mantra. Assuming for the moment that such a style is possible, it might be possible to dramatically reduce the defect density of code and make the subject of work crystal clear to all involved. If so, writing only code demanded by failing tests also has social implications: If the defect density can be reduced enough, QA can shift from reactive to pro-active workIf the number of nasty surprises can be reduced enough, project managers can estimate accurately enough to involve real customers in daily developmentIf the topics of technical conversations can be made clear enough, programmers can work in minute-by-minute collaboration instead of daily or weekly collaborationAgain, if the defect density can be reduced enough, we can have shippable software with new functionality every day, leading to new business relationships with customers So, the concept is simple, but what’s my motivation? Why would a programmer take on the additional work of writing automated tests? Why would a programmer work in tiny little steps when their mind is capable of great soaring swoops of design? Courage. Courage Test-driven development is a way of managing fear during programming. I don’t mean fear in a bad way, pow widdle prwogwammew needs a pacifiew, but fear in the legitimate, this-is-a-hard-problem-and-I-can’t-see-the-end-from-the-beginning sense. If pain is nature’s way of saying “Stop!”, fear is nature’s way of saying “Be careful.” Being careful is good, but fear has a host of other effects: Makes you tentativeMakes you want to communicate lessMakes you shy from feedbackMakes you grumpy None of these effects are helpful when programming, especially when programming something hard. So, how can you face a difficult situation and: Instead of being tentative, begin learning concretely as quickly as possible.Instead of clamming up, communicate more clearly.Instead of avoiding feedback, search out helpful, concrete feedback.(You’ll have to work on grumpiness on your own.) Imagine programming as turning a crank to pull a bucket of water from a well. When the bucket is small, a free-spinning crank is fine. When the bucket is big and full of water, you’re going to get tired before the bucket is all the way up. You need a ratchet mechanism to enable you to rest between bouts of cranking. The heavier the bucket, the closer the teeth need to be on the ratchet. The tests in test-driven development are the teeth of the ratchet. Once you get one test working, you know it is working, now and forever. You are one step closer to having everything working than you were when the test was broken. Now get the next one working, and the next, and the next. By analogy, the tougher the programming problem, the less ground should be covered by each test. Readers of Extreme Programming Explained will notice a difference in tone between XP and TDD. TDD isn’t an absolute like Extreme Programming. XP says, “Here are things you must be able to do to be prepared to evolve further.” TDD is a little fuzzier. TDD is an awareness of the gap between decision and feedback during programming, and techniques to control that gap. “What if I do a paper design for a week, then test-drive the code? Is that TDD?” Sure, it’s TDD. You were aware of the gap between decision and feedback and you controlled the gap deliberately. That said, most people who learn TDD find their programming practice changed for good. “Test Infected” is the phrase Erich Gamma coined to describe this shift. You might find yourself writing more tests earlier, and working in smaller steps than you ever dreamed would be sensible. On the other hand, some programmers learn TDD and go back to their earlier practices, reserving TDD for special occasions when ordinary programming isn’t making progress. There are certainly programming tasks that can’t be driven solely by tests (or at least, not yet). Security software and concurrency, for example, are two topics where TDD is not sufficient to mechanically demonstrate that the goals of the software have been met. Security relies on essentially defect-free code, true, but also on human judgement about the methods used to secure the software. Subtle concurrency problems can’t be reliably duplicated by running the code. Once you are finished reading this book, you should be ready to: Start simplyWrite automated testsRefactor to add design decisions one at a time This book is organized into three sections. An example of writing typical model code using TDD. The example is one I got from Ward Cunningham years ago, and have used many times since, multi-currency arithmetic. In it you will learn to write tests before code and grow a design organically.An example of testing more complicated logic, including reflection and exceptions, by developing a framework for automated testing. This example also serves to introduce you to the xUnit architecture that is at the heart of many programmer-oriented testing tools. In the second example you will learn to work in even smaller steps than in the first example, including the kind of self-referential hooha beloved of computer scientists.Patterns for TDD. Included are patterns for the deciding what tests to write, how to write tests using xUnit, and a greatest hits selection of the design patterns and refactorings used in the examples. I wrote the examples imagining a pair programming session. If you like looking at the map before wandering around, you may want to go straight to the patterns in Section 3 and use the examples as illustrations. If you prefer just wandering around and then looking at the map to see where you’ve been, try reading the examples through and refering to the patterns when you want more detail about a technique, then using the patterns as a reference. Several reviewers have commented they got the most out of the examples when they started up a programming environment and entered the code and ran the tests as they read. A note about the examples. Both examples, multi-currency calculation and a testing framework, appear simple. There are (and I have seen) complicated, ugly, messy ways of solving the same problems. I could have chosen one of those complicated, ugly, messy solutions to give the book an air of “reality.” However, my goal, and I hope your goal, is to write clean code that works. Before teeing off on the examples as being too simple, spend 15 seconds imagining a programming world in which all code was this clear and direct, where there were no complicated solutions, only apparently complicated problems begging for careful thought. TDD is a practice that can help you lead yourself to exactly that careful thought.

1,797 citations


Proceedings ArticleDOI
01 Nov 2019
TL;DR: A network management protocol is proposed that enables programmability of out-of-channel management applications to combat the fate-sharing problem in Software-Defined Infrastructures and brings about a sound software-defined approach that can be expanded to other (combinations of) frequencies and even multiple physical channels.
Abstract: Network management traffic is usually carried in-band with the data plane traffic on a logically separate plane. For example, separate service queues and/or VLANs may be reserved for reliable and timely delivery of management messages. This approach has roots in history but carries a fundamental problem: fate sharing between the data plane traffic and management traffic. Failure in data plane networks often cuts off management traffic to the exact network regions at fault, making it impossible to achieve important and relevant management tasks, such as diagnostics and recovery. In this paper, we propose a network management protocol that enables programmability of out-of-channel management applications to combat the fate-sharing problem in Software-Defined Infrastructures. To test our approach and our implementation we used acoustics, a fairly unexplored physical layer for the control and management plane. We then use the notion of sonification to implement a few representative applications such as k-superseeder detection and TraceSound, a sonified version of traceroute, for out-of-channel network verification and debugging. While scaling acoustics could be an insurmountable challenge, our tests show how our protocol brings about a sound software-defined approach that can be expanded to other (combinations of) frequencies and even multiple physical channels.

1 citations


Cites background from "A Behavior-Driven Approach to Inten..."

  • ..., what to do instead of how to do it [25]....

    [...]


Proceedings ArticleDOI
01 Oct 2019
TL;DR: An algorithm for traffic management that takes advantage of a deep learning model to implement the forwarding mechanism during task offloading in challenged networked scenarios, and explores if and when it is worth using deep learning on a switch to route traffic generated by microservices and offloading requests.
Abstract: With edge computing, it is possible to offload computationally intensive tasks to closer and more powerful servers, passing through an edge network. This practice aims to reduce both response time and energy consumption of data-intensive applications, crucial constraints in mobile and IoT devices. In challenged networked scenarios, such as those deployed by first responders after a natural or human-made disaster, it is particularly challenging to achieve high levels of throughput due to scarce network conditions.In this paper, we present an algorithm for traffic management that takes advantage of a deep learning model to implement the forwarding mechanism during task offloading in these challenging scenarios. In particular, our work explores if and when it is worth using deep learning on a switch to route traffic generated by microservices and offloading requests. Our approach differs from classical ones in the design: we do not train centralized routing decisions. Instead, we let each router learn how to adapt to a lossy path without coordination, by merely using signals from standard performance-unaware protocols such as OSPF. Our results, obtained with a prototype and with simulations are encouraging, and uncover a few surprising results.

Additional excerpts

  • ...[10] F....

    [...]



Proceedings ArticleDOI
01 Oct 2019
TL;DR: This paper presents an architecture for traffic management that may use deep learning to support forwarding during task offloading in challenged networked scenarios, such as those deployed by first responders after a natural or man-made disaster.
Abstract: Edge computing allows computationally intensive tasks to be offloaded to nearby (more) powerful servers, passing through an edge network. The goal of such offloading is to reduce data-intensive application response time or energy consumption, crucial constraints in mobile and IoT devices. In challenged networked scenarios, such as those deployed by first responders after a natural or man-made disaster, it is particularly difficult to achieve high levels of throughput due to scarce network conditions. In this paper, we present an architecture for traffic management that may use deep learning to support forwarding during task offloading in these challenging scenarios. In particular, our goal is to study if and when it is worth using deep learning to route traffic generated by microservices and offloading requests in these situations. Our design is different than classical approaches that use learning since we do not train for centralized routing decisions, but we let each router learn how to adapt to a lossy path without coordination, by merely using signals from standard performance-unaware protocols such as OSPF. Our results, obtained with a prototype and with simulations are encouraging, and uncover a few surprising results.

References
More filters

Journal ArticleDOI
31 Mar 2008
TL;DR: This whitepaper proposes OpenFlow: a way for researchers to run experimental protocols in the networks they use every day, based on an Ethernet switch, with an internal flow-table, and a standardized interface to add and remove flow entries.
Abstract: This whitepaper proposes OpenFlow: a way for researchers to run experimental protocols in the networks they use every day. OpenFlow is based on an Ethernet switch, with an internal flow-table, and a standardized interface to add and remove flow entries. Our goal is to encourage networking vendors to add OpenFlow to their switch products for deployment in college campus backbones and wiring closets. We believe that OpenFlow is a pragmatic compromise: on one hand, it allows researchers to run experiments on heterogeneous switches in a uniform way at line-rate and with high port-density; while on the other hand, vendors do not need to expose the internal workings of their switches. In addition to allowing researchers to evaluate their ideas in real-world traffic settings, OpenFlow could serve as a useful campus component in proposed large-scale testbeds like GENI. Two buildings at Stanford University will soon run OpenFlow networks, using commercial Ethernet switches and routers. We will work to encourage deployment at other schools; and We encourage you to consider deploying OpenFlow in your university network too

8,411 citations


"A Behavior-Driven Approach to Inten..." refers methods in this paper

  • ...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]....

    [...]

  • ...We tested our interpreter over an SDI management tool, controlling an OpenStack cloud platform used to execute virtual network functions (VNFs) and two OpenFlowbased SDN controllers to properly steer traffic flows....

    [...]

  • ...The ordered set of network functions will be implemented on an SDI by means of an OpenFlowbased controller....

    [...]

  • ...Both the OpenFlow and the non-OpenFlow use cases are integrated with the framework and interact with the underlying SDI via the interpreter 8....

    [...]

  • ...Most of these approaches rely on OpenFlow [9], which defines the open southbound API towards network equipment....

    [...]


Book
01 Nov 2002
TL;DR: Drive development with automated tests, a style of development called “Test-Driven Development” (TDD for short), which aims to dramatically reduce the defect density of code and make the subject of work crystal clear to all involved.
Abstract: From the Book: “Clean code that works” is Ron Jeffries’ pithy phrase. The goal is clean code that works, and for a whole bunch of reasons: Clean code that works is a predictable way to develop. You know when you are finished, without having to worry about a long bug trail.Clean code that works gives you a chance to learn all the lessons that the code has to teach you. If you only ever slap together the first thing you think of, you never have time to think of a second, better, thing. Clean code that works improves the lives of users of our software.Clean code that works lets your teammates count on you, and you on them.Writing clean code that works feels good.But how do you get to clean code that works? Many forces drive you away from clean code, and even code that works. Without taking too much counsel of our fears, here’s what we do—drive development with automated tests, a style of development called “Test-Driven Development” (TDD for short). In Test-Driven Development, you: Write new code only if you first have a failing automated test.Eliminate duplication. Two simple rules, but they generate complex individual and group behavior. Some of the technical implications are:You must design organically, with running code providing feedback between decisionsYou must write your own tests, since you can’t wait twenty times a day for someone else to write a testYour development environment must provide rapid response to small changesYour designs must consist of many highly cohesive, loosely coupled components, just to make testing easy The two rules imply an order to the tasks ofprogramming: 1. Red—write a little test that doesn’t work, perhaps doesn’t even compile at first 2. Green—make the test work quickly, committing whatever sins necessary in the process 3. Refactor—eliminate all the duplication created in just getting the test to work Red/green/refactor. The TDD’s mantra. Assuming for the moment that such a style is possible, it might be possible to dramatically reduce the defect density of code and make the subject of work crystal clear to all involved. If so, writing only code demanded by failing tests also has social implications: If the defect density can be reduced enough, QA can shift from reactive to pro-active workIf the number of nasty surprises can be reduced enough, project managers can estimate accurately enough to involve real customers in daily developmentIf the topics of technical conversations can be made clear enough, programmers can work in minute-by-minute collaboration instead of daily or weekly collaborationAgain, if the defect density can be reduced enough, we can have shippable software with new functionality every day, leading to new business relationships with customers So, the concept is simple, but what’s my motivation? Why would a programmer take on the additional work of writing automated tests? Why would a programmer work in tiny little steps when their mind is capable of great soaring swoops of design? Courage. Courage Test-driven development is a way of managing fear during programming. I don’t mean fear in a bad way, pow widdle prwogwammew needs a pacifiew, but fear in the legitimate, this-is-a-hard-problem-and-I-can’t-see-the-end-from-the-beginning sense. If pain is nature’s way of saying “Stop!”, fear is nature’s way of saying “Be careful.” Being careful is good, but fear has a host of other effects: Makes you tentativeMakes you want to communicate lessMakes you shy from feedbackMakes you grumpy None of these effects are helpful when programming, especially when programming something hard. So, how can you face a difficult situation and: Instead of being tentative, begin learning concretely as quickly as possible.Instead of clamming up, communicate more clearly.Instead of avoiding feedback, search out helpful, concrete feedback.(You’ll have to work on grumpiness on your own.) Imagine programming as turning a crank to pull a bucket of water from a well. When the bucket is small, a free-spinning crank is fine. When the bucket is big and full of water, you’re going to get tired before the bucket is all the way up. You need a ratchet mechanism to enable you to rest between bouts of cranking. The heavier the bucket, the closer the teeth need to be on the ratchet. The tests in test-driven development are the teeth of the ratchet. Once you get one test working, you know it is working, now and forever. You are one step closer to having everything working than you were when the test was broken. Now get the next one working, and the next, and the next. By analogy, the tougher the programming problem, the less ground should be covered by each test. Readers of Extreme Programming Explained will notice a difference in tone between XP and TDD. TDD isn’t an absolute like Extreme Programming. XP says, “Here are things you must be able to do to be prepared to evolve further.” TDD is a little fuzzier. TDD is an awareness of the gap between decision and feedback during programming, and techniques to control that gap. “What if I do a paper design for a week, then test-drive the code? Is that TDD?” Sure, it’s TDD. You were aware of the gap between decision and feedback and you controlled the gap deliberately. That said, most people who learn TDD find their programming practice changed for good. “Test Infected” is the phrase Erich Gamma coined to describe this shift. You might find yourself writing more tests earlier, and working in smaller steps than you ever dreamed would be sensible. On the other hand, some programmers learn TDD and go back to their earlier practices, reserving TDD for special occasions when ordinary programming isn’t making progress. There are certainly programming tasks that can’t be driven solely by tests (or at least, not yet). Security software and concurrency, for example, are two topics where TDD is not sufficient to mechanically demonstrate that the goals of the software have been met. Security relies on essentially defect-free code, true, but also on human judgement about the methods used to secure the software. Subtle concurrency problems can’t be reliably duplicated by running the code. Once you are finished reading this book, you should be ready to: Start simplyWrite automated testsRefactor to add design decisions one at a time This book is organized into three sections. An example of writing typical model code using TDD. The example is one I got from Ward Cunningham years ago, and have used many times since, multi-currency arithmetic. In it you will learn to write tests before code and grow a design organically.An example of testing more complicated logic, including reflection and exceptions, by developing a framework for automated testing. This example also serves to introduce you to the xUnit architecture that is at the heart of many programmer-oriented testing tools. In the second example you will learn to work in even smaller steps than in the first example, including the kind of self-referential hooha beloved of computer scientists.Patterns for TDD. Included are patterns for the deciding what tests to write, how to write tests using xUnit, and a greatest hits selection of the design patterns and refactorings used in the examples. I wrote the examples imagining a pair programming session. If you like looking at the map before wandering around, you may want to go straight to the patterns in Section 3 and use the examples as illustrations. If you prefer just wandering around and then looking at the map to see where you’ve been, try reading the examples through and refering to the patterns when you want more detail about a technique, then using the patterns as a reference. Several reviewers have commented they got the most out of the examples when they started up a programming environment and entered the code and ran the tests as they read. A note about the examples. Both examples, multi-currency calculation and a testing framework, appear simple. There are (and I have seen) complicated, ugly, messy ways of solving the same problems. I could have chosen one of those complicated, ugly, messy solutions to give the book an air of “reality.” However, my goal, and I hope your goal, is to write clean code that works. Before teeing off on the examples as being too simple, spend 15 seconds imagining a programming world in which all code was this clear and direct, where there were no complicated solutions, only apparently complicated problems begging for careful thought. TDD is a practice that can help you lead yourself to exactly that careful thought.

1,797 citations


"A Behavior-Driven Approach to Inten..." refers methods in this paper

  • ...1 Our design principle is based on Behavior-Driven Development (BDD) [19], an agile software development technique, corollary of the Test-Driven Development paradigm [20]....

    [...]


01 Jan 2015

1,142 citations


Journal ArticleDOI
08 Apr 2014
TL;DR: The intellectual history of programmable networks, including active networks, early efforts to separate the control and data plane, and more recent work on OpenFlow and network operating systems are traced.
Abstract: Software Defined Networking (SDN) is an exciting technology that enables innovation in how we design and manage networks. Although this technology seems to have appeared suddenly, SDN is part of a long history of efforts to make computer networks more programmable. In this paper, we trace the intellectual history of programmable networks, including active networks, early efforts to separate the control and data plane, and more recent work on OpenFlow and network operating systems. We highlight key concepts, as well as the technology pushes and application pulls that spurred each innovation. Along the way, we debunk common myths and misconceptions about the technologies and clarify the relationship between SDN and related technologies such as network virtualization.

840 citations


"A Behavior-Driven Approach to Inten..." refers methods in this paper

  • ...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]....

    [...]


Proceedings Article
02 Apr 2013
Abstract: Networks are complex and prone to bugs. Existing tools that check network configuration files and the data-plane state operate offline at timescales of seconds to hours, and cannot detect or prevent bugs as they arise. Is it possible to check network-wide invariants in real time, as the network state evolves? The key challenge here is to achieve extremely low latency during the checks so that network performance is not affected. In this paper, we present a design, VeriFlow, which achieves this goal. VeriFlow is a layer between a software-defined networking controller and network devices that checks for network-wide invariant violations dynamically as each forwarding rule is inserted, modified or deleted. VeriFlow supports analysis over multiple header fields, and an API for checking custom invariants. Based on a prototype implementation integrated with the NOX OpenFlow controller, and driven by a Mininet OpenFlow network and Route Views trace data, we find that VeriFlow can perform rigorous checking within hundreds of microseconds per rule insertion or deletion.

810 citations


Frequently Asked Questions (1)
Q1. What are the contributions mentioned in the paper "A behavior-driven approach to intent specification for software-defined infrastructure management" ?

In this work, the authors propose a northbound interface ( NBI ) for intent declaration, based on Behavior-Driven Development. In their approach, intents are specified in plain English and translated by their 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. The authors demonstrated their 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. The authors believe that their approach is far more general and paves the way for a more expressive and simplified northbound interface for intent-driven networking.