Hephaestus: a cloud-based environment to virtual network automation
Roberio Gomes Patricio
Laboratory of Computer Network and Security – LARCES
University of Ceará State, UECE
Fortaleza, Brazil
roberio@larces.uece.br
Abstract— Cloud computing is well known for providing data
storage services and extensions for computing power.
Gradually, it begins to find new scenarios for its applicability,
more specically creating virtual computer networks. Many
companies would like to master the process of defining,
modeling, design, configure and initialization a virtual network
in an automated fashion way. This paper presents Hephaestus,
a tool for automating the process of creating virtual networks
in the cloud enviroment, using open standards and tools such
as NETCONF, YANG, OpenStack and OpenvSwitch. A proof
of concept helped to validate the architecture and to
understand how Hephaestus works.
Keywords-component; cloud computing; virtual networking;
netconf; yang; openstack
I. INTRODUCTION
Virtualization plays an important and crucial role when it
comes to cloud computing. In fact, in the cloud-computing
context, it is possible to think about virtualization in a fairly
broad, since any resource provided by clouds can be seen as
virtualized. Cloud computing was known primarily as a
means of providing data storage services, and after that as an
alternative extension of computational power. Now it begins
to define its applicability to new scenarios, including the
possibility of their use in creating virtual networks.
Starting from a set of real needs, many companies would
like to master the process of defining, modeling, designing,
configuring and initializing a virtual network so friendly and
automated. Surely, that brings competitive advantage for
both providers and consumers of clouds, if they can rely on
tools that have that power of expression.
This paper presents Hephaestus, a Java based tool that
enables the automation of the entire process involved in the
creation, initialization and configuration of virtual networks
in the cloud. To do this, open standards and tools widely
accepted and supported by the market and the academy are
used.
The remainder of this paper is organized as follows:
section II presents an overview of virtual networks,
configuration management and automation; section III
describes the related works done by other authors in this
area; section IV describes the Hephaestus’ architecture,
section V provides a Hephaestus’ evaluation, section VI
presents a proof of concept that validates the Hephaestus’
architecture and section VI concludes the work with some
conclusions.
Joaquim Celestino Junior
Laboratory of Computer Network and Security – LARCES
University of Ceará State, UECE
Fortaleza, Brazil
celestino@larces.uece.br
II. BACKGROUND
A. Virtual Networking
The concept of virtual networks has attracted a
significant effort involved in research areas like distributed
systems and computer networks. This happens because of the
constant debates about how to model, build and manage the
computer networks of the next generation, which can lead to
the replacement of the internet, or at least eradicate its so-
called "ossification".
Each virtual network (VN) can be understood as a
collection of virtual nodes and links, which act as a subset of
network resources of the underlying physical structure and
coexisting in isolation from each other. Thus, a single
physical network is able to support multiple logical networks
[1].
The major motivation for the adoption of virtual
networks is the Internet "ossification" [1]. According to [3],
changes in the current Internet’s architecture are limited to
just simple incremental, since the adoption of a new
architecture or modifications in the current architecture
requires that the interests of various stakeholders come into
consensus.
In addition, according to [4], from the business view,
networking virtualization changes how the Internet and its
related services are delivered to the end user. The old model
of delivering Internet based on ISPs (Internet Service
Providers), gives way to two new entities: Infrastructure
Providers (InPs), who manage the physical infrastructure and
Service Providers (SPs), which create and offer virtual
networks, adding resources from one or more InPs.
According to [1], the holy grail of network virtualization
would be an environment where multiple SPs lease
underlying physical resources from multiple InPs, and can
therefore dynamically compose heterogeneous virtual
networks, which co-exist in isolation within same physical
infrastructure and compete with each other for physical
resources underlying (see Figure 1).

Figure 1 - Virtual Networks over physical networks [4]
Among the major challenges encountered in the context
of virtual networks three points highlights: instantiation,
management and operation [3]. More specifically when it
comes to instantiation, problems related to interface and
bootstrap are receiving more attention in this research. With
respect to management, the issues pertaining to monitoring
and configuration management appear as points that cannot
fail to be addressed, even with less depth at the moment.
The challenges mentioned above are relevant because of
the many different ways in which virtual networks can be
created. In [4], the author points out that historically the
virtual networks has been created based on four distinct
approaches: VPN (Virtual Private Network), VLAN (Virtual
LAN), programmable networks and reactive networks and
overlays.
B. Network Configuration Management
The configuration management of a large number of
network devices remains an important and practical problem.
The configurations for a given device and the mechanisms
for retrieving and modifying them are something very
specific to each vendor, and the configuration interfaces
most widely used today are still proprietary command line
interfaces (CLI), becoming quite costly achieve a high level
of efficiency and reliability through automation of these,
especially when it comes to issues of maintenance and
version control [7].
NETCONF [8] emerged as a standard protocol for
network management proposed by IETF [9]. This is a
client/server and connection-oriented protocol, whose server
is a network device and the client is process in the field of
network management.
According to [11], NETCONF overcame the weaknesses
of SNMP and emerged as a promising approach to
standardize network management mechanisms based on
XML. It provides better mechanisms for configuration of IP
network devices, due to the effective use of technologies
such as XML and the like. The driving force behind
NETCONF is a need for an interoperable programmatic
interface between different vendors to manipulate the
configuration state of network devices [7].
It is common in the world of network management tools
that protocols and data models are separated, as it can be
seen on SNMP protocol [2] and its data modeling language
SMI. In this proposal, the YANG modeling language [22]
had evaluated its viability and thus was chosen for the
construction of models of information used in the
management of network elements involved here.
In Cloud-based environments, using tools like
NETCONF can greatly help in efficient management of
networks and the correctness of the related operations of
configuration management. This can be applied both on the
infrastructure and virtualized resources available in cloud.
C. Configuration Management Automation
The process of creating, configuring and managing
virtual network, even in public cloud environments such as
Amazon EC2 [12], still lacks maturity and flexibility in their
use in areas considered of great importance by the contractor
such as flexibility in specifying components and network
services, supporting various topologies, configuration
management support at lower levels aiming at efficiency and
optimization of computational resources and connectivity,
and even more attractive if all these services could be
automated in an agile and transparent way to the end user.
The automation of these processes involves a work of
adopting standards and even definition of others, followed by
an effort in understanding how technologies, practices and
standards can be applied to answer a new set of requirements
that arise in this different scenario of networks computers
use.
Furthermore, cloud computing brings a set of new
restrictions and requirements that need to be addressed and
met. Requirements such as high availability, scalability and
fault tolerance are striking in cloud computing. So virtual
networks built inside these environments end up inheriting
an obligation to behave in the same manner. This involves
issues that do not seem so clear, but for example, given a
virtual network, what happens if one of its virtual machines
goes out of work? From the viewpoint of cloud computing
the fault handling process is relatively simple, and can be
resolved in a few seconds by activating a new instance.
However, for configuration management, it will take a few
more steps, relating to ensuring the compatibility of this new
instance with the activities performed by the previous one.
Those steps are responsible for the correct initialization of
the instance, its services and its insertion in the correct
virtual network.
Most providers of private cloud to their contractors
presents a set of APIs Rest (REpresentional State Transfer)
with which you can automate the tasks required to
implement a search and operating system image, as well as
control of the life cycle of same, since its activation,
suspension and even migrating to other physical machines.
However, the power conferred by these APIs does not seem
enough for the assembly, startup and configuration of virtual
networks, requiring extra functions, especially with regard to
the configuration of these lower layers, to improve the
efficiency of services provided by these networks.
Some InPs offer besides the aforementioned APIs, a sort
of control panels with which consumers are able define
topology, interfaces and kind of instance that make their
virtual networks, but those tools are not able to providing
low granularity configurations in order to set up these
networks efficiently and personalized. In fact, consumers are
still working with prefabricated settings, some times because
of technological constraints or implementation issues that
restrict and impede automated, requiring even human
intervention in intermediate steps needed to make a virtual
network operating.
III. RELATED WORK
In [5], the authors introduce the concept of Cloud-based
Virtual Networks (CVN), highlighting the applicability and
challenges of virtual networks in the cloud-computing
context. It also presents the basic characteristics of a CVN,
their unique properties and a set of management
requirements, which cannot be forgotten. Using CVNs,
enterprises can extend their technological parks beyond its
physical facilities, increasing their number of computers and
devices interconnected, without taking those routine costs
involved in the acquisition and maintenance of the same.
In [24], the authors present VNEXT (Virtual Network Figure 2 – Hephaestus’s architecture: deployment view
Management for Xen-Based Testbeds), a system to control
and manage virtual networks based on Xen platform [16]. A. Hephaestus Core
The purpose of VNEXT is to help network administrators to This is the main component of the architecture. It is
perform decision making in this challenging environment responsible for orchestration of the creation, initialization
virtualized. The specificity of hypervisor restricts its use, and configuration of a virtual network based on XML
reducing the scope of that tool. The process of configuration definition provided as input (See Figure 3). This component
and monitoring of virtual machines is based on scripts and maintains a knowledge base of all networks created and
UNIX tools, which is characterized as so fragile mechanism managed by him. Inside of it there is a complete processing
for virtual machines with different operating system images. framework, able to connect to cloud management system,
In [6], the author proposed the use of network and servers taking care of issues such as authentication, provisioning and
virtualization techniques as a mechanism to support the allocation of computing resources in the cloud.
migration of data center services around the world, according
to the availability of renewable energy sources like solar and
wind. Even demonstrating efficiency in reducing costs and
carbon emissions, the migration approach and reconstruction
of virtual networks does not happen in an automated way.
In [25], there is a technical analysis of network
virtualization based software and hardware. In addition, it
presents the integration of an open source hypervisor with a
software-based virtual switch, along with cloud management
system, OpenNebula [26]. In addition, a couple of basic
scenarios are presented for the creation of virtual networks
using VLANs. Thus, users can rely on a cloud network Figure 3 - XSD Modeling to define a virtual network
environment more resilient and secure. Despite the use of
B. OpenStack
OpenNebula, the whole configuration process of virtual
machines is done based on predefined configuration files and The OpenStack project [13] aims to create an open platform
a set of scripts. There is not a standard interface for for cloud computing with which it is possible to create public
configuring instances and the process of creating tags that and private clouds designed to be highly scalable and low
define virtual networks requires much human intervention. complexity. The activation of various features of OpenStack
can be done either by a command line interface (CLI) or a
IV. HEPHAESTUS’ MAIN ARCHITECTURE REST-based API. The communication between the manager
The Hephaestus’ architecture definition was based on and the instances as well as other administrative components
some concepts of SOA (Service Oriented Architecture) such (see Figure 4) is made through asynchronous
as loose coupling, interoperability and use of open standards communication, provided by service message queues.
for communication. Figure 2 shows the deployment view of
Hephaestus, highlighting the major internal components of
this architecture, as described next.
 completely and logically. In Figure 2 tags tap0 and tap1 are
associated to tow separate virtual networks. However, OVS
opens the possibility of creating virtual networks using other
approaches, among them the OpenFlow [27], which will be
subject of further exploration and possibly incorporated into
the architecture of Hephaestus.
For those scenarios involving multiple InPs, it possible to
think about the use of private communication channels
between the InPs. The example of Figure 5 illustrates how a
customer who has leased computational resources from two
distinct cloud providers can establish a VPN.

Figure 4 – OpenStack’s Architecture [13]

In addition, OpenStack is agnostic to support hypervisors

and can handle the most diverse vendors as Xen [16]
XenServer/XCP [17], KVM [18], OVF [19], VMware
vSphere [20] and Hyper -V [21].
C. Open vSwitch (OVS)
According to [14], Open vSwitch (OVS) is a multilayer
virtual switch, designed to enable massive network
automation through programmatic extension, while
supporting management interfaces and standard protocols.
Figure 5 – Virtual Network with multiples InPs
According to [15], the main OVS’ communication interface
is based on JSON-RPC, but it is possible to find other like The use of OVS with a NETCONF-based interface
CLI, SNMP and NETCONF. ensures the viability of creating multiple virtual networks on
In order to conduct this study, a NETCONF interface was InPs. Because of transactional NETCONF’s characteristics,
defined using YANG [22] with YUMA [23] tools. To do this it is possible that a large number of devices are configured at
it is necessary that OVS and YUMA work together. In this the same time, ensuring consistency of operation.
case YUMA offers a NETCONF server known as netconfd.
D. YUMA VI. PROOF OF CONCEPT

YUMA Tools is an open source suite of tools designed to To validate the Hephaestus’ architecture, a test scenario
work with NETCONF protocol. It consists of a NETCONF was created based on the experiment described in [25]. After
client (yangcli), a NETCONF server (netconfd), an Open- a couple of the necessary adjustments to the proposed
SSH server and utility to compare YANG modules. architecture, as shown in Figure 6, we used two physical
In the Hephaestus’ architecture, the YUMA role is servers Host1 and Host2, each hosting two virtual machines.
creating the OVS’s access interface using NETCONF. The Additionally, each server executes a OpenStack computation
OVS’ configuration process, normally executed via CLI or module, known as Nova. In a third physical server run: the
JSON-RPC, is now performed using a standard interface. OpenStack controller, the OVS and YUMA.
The operations available in OVS, used to create virtual
networks, were exported to an interface based on XML-RPC,
accessible via NETCONF. The idea was to have a well-
defined interface, robust, secure, based on open standards.
V. HEFESTO’S EVALUATION
Within the Hephaestus’ architecture some details attract
attention from the implementation standpoint. The first one
is why OpenStack was chosen as a virtual machine
management environment. This choice was motivated by the
distributed nature of OpenStack and its flexibility in working
with different hypervisors, leaving Hephaestus vendor
independent. Figure 6 – Base Scenario
Another important point is the approach used to build the
virtual networks. Like VNEXT, Hephaestus uses VLANs,
associating tags to different virtual networks, isolating them
 Once modeled virtual network topology, Hephaestus is [3]
responsible for the creation of its elements by performing the
following steps:
[4]
1. Initializes virtual machines calling the OpenStack
Rest API.
2. Loads in OVS and the virtual machines (if [5]
necessary), via NETCONF, YANG management
modules,
3. Then, run NETCONF calls to OVS, creating tags [6]
(VLAN) used by the two virtual networks.
After creation of virtual networks, instances VM1 and
VM3 can communicate completely independently of VM2
[7]
and VM4. The separation of network traffic and the visibility
of the data was confirmed by performing tests with the tools
ping and tcpdump.
This scenario brings attention to an important point when [8]
it comes to traffic isolation, availability and fault tolerance:
during the test process, when OVS was disconnected, both [9]
networks became inoperable. In contrast, when OVS was
restarted, networks returned to work properly. Thus we [10]
considered the possibility of using more instances of OVS,
preferably one for each virtual network is thus assured of [11]
complete isolation networks. After this adjustment, by
repeating the test chains were shown to be sufficiently robust
without the event of failure of one interfering with the [12]
operation of the other.
[13]
VII. CONCLUSION [14]
This paper presents Hephaestus, a tool designed to help [15]
in the creation of virtual networks in cloud computing
environments. Among the many specific features
Hephaestus, we highlight the possibility of working on [16]
scenarios involving multiple InPs, and also the creation of [17]
these networks using transactions, based on interfaces [18]
compatible with the NETCONF protocol. Moreover, [19]
Hephaestus offers the possibility of working with various [20]
hypervisors, unlike other solutions mentioned above.
A proof of concept was done, which helped to validate
the architecture, strongly contributing to its improvement and [21]
maturity. Using more instances of OVS, Hephaestus gave the
[22]
robustness and complete isolation expected in cloud
computing environments.
As future work, we believe in the possibility of using [23]
OpenFlow to define flows between networks, thus increasing [24]
the number of virtual networks that can be created. This will
ensure significant improvements in the technique used for
isolation of virtual networks.
Moreover, YANG modules based on MIB HOST-
RESOURCES-V2-MIB [28] can be incorporated into virtual [25]
instances and OVS, thus giving greater control over the
allocation of computing resources. This opens doors for
deploying mechanisms for performance monitoring and SLA
(Service Level Agreement).
[26]
REFERENCES [27]
[1] George N. Rouskas, "Tutorial on Network Virtiualization". [28]
Presented at OFC/NFOEC 2012, March 7, 2012, Los Angeles,
CA.
[2] SNMP – RFC 2576, http://tools.ietf.org/html/rfc3584
N.M. Mosharaf Kabir Chowdhury, Raouf Boutaba, “A Survey
of Network Virtualization”, University of Waterloo Technical
Report CS-2008-25, Oct. 2008.
N. M. Mosharaf Kabir Chowdhury and R. Boutaba, “Network
virtualization: state of the art and research challenges,” IEEE
Communications, vol. 47, no. 7, pp. 20–26, July 2009.
T. Choi, K. Nodir, T. Lee, D. Kim, and J. Lee, "Autonomic
management framework for cloud-based virtual networks",
;in Proc. APNOMS, 2011, pp.1-7.
LeMay, M.; Kim-Khoa Nguyen; St. Arnaud, B.; Cheriet, M.;,
"Toward a Zero-Carbon Network: Converging Cloud
Computing and Network Virtualization," Internet Computing,
IEEE , vol.16, no.6, pp.51-59, Nov.-Dec. 2012.
Schönwälder, J.; Björklund, M.; Shafer, P.; , "Network
configuration management using NETCONF and YANG,"
Communications Magazine, IEEE , vol.48, no.9, pp.166-173,
Sept. 2010.
R. Enns, “NETCONF Configuration Protocol,” Juniper
Networks, RFC 4741, Dec. 2006.
IETF: The Internet Engineering Task Force,
http://www.ietf.org/
E. Nataf and O. Festor, "jYang : A YANG parser in java",
Computing Research Repository, August 2009 2009.
H. Xu, D. Xiao, Data Modeling for NETCONF-Based
Network Management: XML Schema or YANG, Proceeding
of 11th International Conference on Communication
Technologies, Washington DC: IEEE Press, 561-564, 2008.
Amazon Elastic Compute Cloud (Amazon EC2),
http://aws.amazon.com/ec2/
OpenStack, http://openstack.org.
Open vSwitch, http://openvswitch.org.
J. Pettit et al., Virtual Switching in an Era of Advanced
Edges, 2nd Workshop on Data Center -- Converged and
Virtual Ethernet Switching (DC-CAVES), Sept. 2010.
Xen, http://xen.org/
XenServer/XCP, http://xen.org/
KVM, http://www.linux-kvm.org/page/Main_Page
OVF, http://dmtf.org/standards/ovf
VMware vSphere,
http://www.vmware.com/products/vsphere/mid-size-and-
enterprise-business/overview.html
Hyper-V, http://www.microsoft.com/en-us/server-
cloud/windows-server/hyper-v.aspx
YANG - A Data Modeling Language for the Network
Configuration Protocol (NETCONF),
https://tools.ietf.org/html/rfc6020.
YUMA, http://www.yumaworks.com/yuma/
Pisa, P.S.; Couto, R.S.; Carvalho, H.E.T.; Neto, D.J.S.;
Fernandes, N.C.; Campista, M.E.M.; Costa, L.H.M.K.;
Duarte, O.C.M.B.; Pujolle, G.; , "VNEXT: Virtual network
management for Xen-based Testbeds," Network of the Future
(NOF), 2011 International Conference on the , vol., no.,
pp.41-45, 28-30 Nov. 2011.
Hui-Min Tseng; Hui-Lan Lee; Jen-Wei Hu; Te-Lung Liu; Jee-
Gong Chang; Wei-Cheng Huang; , "Network Virtualization
with Cloud Virtual Switch," Parallel and Distributed Systems
(ICPADS), 2011 IEEE 17th International Conference on ,
vol., no., pp.998-1003, 7-9 Dec. 2011.
OpenNebula, http://opennebula.org/
OpenFlow, http://www.openflow.org/
HOST-RESOURCES-V2-MIB,
http://www.oidview.com/mibs/0/HOST-RESOURCES-V2-
MIB.html