Extending the NetServ autonomic management capabilities using OpenFlow

Abstract

Autonomic management capabilities of the Future Internet can be provided through a recently proposed service architecture called NetServ. It consists of the interconnection of programmable nodes which enable dynamic deployment and execution of network and application services. This paper shows how this architecture can be further improved by introducing the OpenFlow architecture and implementing the OpenFlow controller as a NetServ service, thus improving both the NetServ management performance and its flexibility. These achievements are demonstrated experimentally on the GENI environment, showing the platform self-protecting capabilities in case of a SIP DoS attack.

Full text

Extending the NetServ autonomic management
capabilities using OpenFlow
E. Maccherani1, M. Femminella1, J.W. Lee2, R. Francescangeli1, J. Janak2, G. Reali1, H. Schulzrinne2
1 DIEI – University of Perugia, Perugia, Italy {maccherani,femminella,francescangeli,reali}@diei.unipg.it
2 Dept of Computer Science, Columbia University, New York, USA {jae,janakj,hgs}@cs.columbia.edu
Abstract— Autonomic management capabilities of the Future
Internet can be provided through a recently proposed service
architecture called NetServ. It consists of the interconnection of
programmable nodes which enable dynamic deployment and
execution of network and application services. It allows creating a
suitable environment for hosting an autonomic management
architecture. This paper shows how this architecture can be further
extended by introducing the OpenFlow architecture and
implementing it as a NetServ service, thus improving both the
NetServ management performance and its flexibility. These
achievements are demonstrated experimentally on the GENI
environment, showing the platform self-protecting capabilities in
case of a SIP DoS attack.
Keywords: autonomic management, programmable nodes, dynamic
deployment, OpenFlow, NetServ, GENI
I. INTRODUCTION
A progressively more complex and interconnected
networking infrastructure is leading to an increasing difficulty in
managing multi-vendor environment and services. Usually they
are manually deployed and managed, requiring labor-intensive
support structures and making room to security problems or
errors. Observing that networks are becoming more dynamic,
heterogeneous and large, researchers and companies are
addressing these problems investigating the application of
autonomic principles, trying to simplify the network management
by automating and distributing the decision making processes. In
[16] the authors showed how the NetServ platform [11] can be
successfully used for implementing an autonomic management
architecture for the future Internet. NetServ is a programmable
node architecture, intended for dynamically deploying in-network
services. Service modules are written in Java and deployed by
sending NSIS signaling messages [12].
The proposed autonomic management architecture, which is
an extension of the FOCALE framework [2], fully exploits the
NetServ dynamic properties, such as the automatically deploying,
configuring and removing services at runtime. In fact NetServ is
an enabling platform for every kind of network management
architecture, because the NetServ implementation relies on Linux
and Java technologies, permitting its deployment in every linux-
enabled device, such as routers, servers, access points and
modems. However, in some cases, NetServ could be a bottleneck
for some platforms, because in its actual implementation all the
incoming packets must go at user space, slowing down the
system [26].
This paper shows how the architecture proposed in [16] can
be further extended and improved by the introduction of the
OpenFlow technology [14] [15]. In more detail, we will show
how the OpenFlow technology can be integrated with the
NetServ platform, in order to improve the flexibility and the
performance of the autonomic management platform
implementation.
The paper is organized as follows. In Section II, we present
the autonomic management background and related works,
including an overview of the OpenFlow platform. Section III
describes the proposed autonomic architecture and its
implementation, presenting both the NetServ platform and its
integration with OpenFlow. Section IV shows the experiment
conducted inside the GENI environment [13] as a practical
demonstration of how the platform can self-protect from a denial
of service (DoS) attack and how the OpenFlow integration
enables us to design a scalable architecture. Final thoughts and
conclusions can be found in Section V.
II. BACKGROUND AND RELATED WORK
A. Autonomic Management
Networks will be changing over time and continuously
expanding, open to the introduction of new type of networks,
depending only on the technology level and the designer’s
creativity. The Future Internet will probably extend even more
this vision, adding new contents, algorithms, nodes, protocols. In
addition, network activities happen at very different time and
spatial scale, makes any system analysis very difficult. The
management of a so complex system [1] can be conceived as a
set of control loops, where every control element may be fed
back to other elements. One of the most suitable approach to
manage such complex networks is the introduction of autonomic
procedures. In particular several scopes have been identified [3]:
self-locating, self-configuring, self-healing, self-optimizing and
self-protecting. An essential requirement of all these autonomic
features is a context awareness, a deep knowledge of the whole
data representing the current state of the network elements. This

can be in terms of server loads, router capabilities, available
bandwidth, supported services, etc.
In the literature, several management paradigms have been
proposed to achieve a context awareness and then to implement
an effective autonomic management system.
Autonomic computing [4] consists of several controlling
devices, called autonomic managers. Each manager supervise a
managed entity (a network resource in our case) through a
control loop. The manager is goal-oriented and takes decisions
according to the “monitor-analyze-plan-execute” concept.
Semantic reasoning [5] is an inductive process for extract
useful management information from available data of the
managed system. It utilize ontological representation of system
components in order to create an hierarchical data structure that
represent the whole system. The use of ontologies allows to react
to an abnormal behavior and to determine the closest match
between resources allocation and management goals.
Overlay management backbones [6] consist of the use of
distributed hash tables for implementing distributed self-
organizing activity management. Using these overlays, network
components are associated with a specific management activity
in an autonomic and dynamic way.
Ambient networking [7] has been defined in the wireless
network context as a strategy for provide connectivity by
cascading multiple network segments. The objective is to
integrate any available network seamlessly, in an autonomic way,
through negotiation of policies and agreements.
Bio-inspired autonomic systems [8] get its inspiration from
another complex system, the biological one, trying to adapt its
self-regulating mechanisms for network management.
Federated autonomic management [17] wants to enable
network and service management as result of threading
negotiations for evolving value chains composed of providers
and/or consumers, enabling end-users to take a more proactive
role managing their quality of experience in a semantic way. A
federation, as a set of domains, is identified, governed by a set of
distributed collaborating governing authorities in which each
domain has a set of limited powers regarding their own local
interests.
All these paradigms have been included in different network
management platforms. The FOCALE architecture [2] consists of
multiple control loops including the main achievements of the
autonomic computing and semantic reasoning. The AutoI [9]
project has a similar approach, showing a layered organization of
management functions. The Cisco ANA project is a
virtualization-based architecture where Virtualized Network
Element is associated with a network device and autonomously
retrieves information and enforces management policies.
4WARD, CONMan [10] and in-network management [19]
projects approach the problem differently, proposing an
architecture where the management functions are embedded in
network devices. The Univerself project [18] proposes the
Unified Management Framework (UMF) specification, that aims
to create an unified set of interfaces for the management of
different domain of operation, such as access network, core
network and service domain.
B. OpenFlow
The OpenFlow project [14] [15] proposes to separate the
control path from the data path, identifying a common set of
functions implemented in an open software platform. An
OpenFlow switch is a dumb element that forwards packets
between ports, as defined by a remote control process, called
OpenFlow Controller (OFC). These two elements communicate
through a secure channel using the OpenFlow protocol, an open
protocol to program the hardware data path of OpenFlow-enabled
devices. The data path implements a flow table where every entry
contains a flow description, in terms of some header fields match
(e.g. MAC/IP address or transport port). Each entry has one or
more associated actions that instruct the switch how to process
the flow. Various actions can be performed, such as packet
dropping, forwarding to a given port, modifying some header
fields. When a packet arrives, the switch matches the packet’s
header fields with its flow table entries. If a match is found, the
required action is performed at wire speed, otherwise the switch
sends the packet to the OFC. The OFC is implemented in
software on a remote machine and decides how to handle packets
flows. It can add and remove rules and actions inside the switch’s
flow table, gathering statistics and send commands.
III. MANAGEMENT ARCHITECTURE
A static management architecture although autonomic, is not
suited for modern complex networks, handling multiple devices
and mangement entities. A viable solution consists of a
management architecture that provides discovery capabilities
and deployable components, so that management elements may
be instantiated where needed [16]. Programmable network nodes
based on the NetServ paradigm implement a service container
and a common execution environment for hosting both networks
services and management agents. A signaling protocol is used in
order to accomplish node discovery and module deployment
goals. The architecture is inspired to the FOCALE [2] paradigm,
since it already includes most of enabling mechanisms for
autonomic management and its modularity is well suited for a
dynamic network and service management. The main control
element of that proposal is the NetServ Autonomic Management
Element (NAME). It provides all the capabilities listed and, in
addition, implements other autonomic-related components. It is
in charge to gather context related information from external
collectors (which may be heterogeneous), and to translate them
into a common syntax for further processing. It implements a
decision module, the PDP (policy decision point), which is in
charge to take management actions. If the PDP cannot associate a
context-related information to any known system state, it invokes
additional components, having the job of process the information
in order to define the needed actions and the relevant policies for
keeping the system within an acceptable state [16]. Finally, the
PDP decides, when needed, to deploy management services over
the selected resources at runtime, taking them from a

management service repository. Also policy enforcements point
(PEP) entities are based on the NetServ architecture, since it
allows running "generic" services varying from addressable
services to packet processing ones.
Since the NAME is just a NetServ service, it can be replicated
and the system management may be organized hierarchically,
with outer control loops implementing orchestration functions
and inner loops having specific device management tasks.
A. NetServ
NetServ is a programmable node architecture designed for
deploying in-network services [11]. It is suited for any type of
nodes, such as routers, access points, set-top boxes, and user
equipment. NetServ includes an in-network virtualized service
container and a common execution environment, as well as an
NSIS-based signaling protocol [12], used for dynamic NetServ
node discovery and service modules deployment therein.
NetServ fits perfectly as the enabling platform for our
autonomic management architecture, not only for its intrinsic
dynamic capabilities, but also for its modularity, allowing the
implementation of NAME itself and its modules as NetServ
services. In addition, the dynamic discovery and deployment
capabilities of this architecture can either enable a NAME
replication or movement to other NetServ network nodes,
according to the system needs, such as a fulfillment of some
policies. The NAME deployment in NetServ makes it
straightforward to implement autonomic management functions
governing the management architecture itself, which is a further
self-management level with respect to traditional systems.
The NetServ prototype architecture is shown in Figure 1. The
NetServ controller coordinates NSIS signaling daemons, service
containers, and the node transport layer. It receives control
commands from the NSIS signaling daemons, which may trigger
installation or removal of both application modules within
service containers and filtering rules in the data plane. The
NetServ controller is also in charge of setting up and tearing
down service containers, authenticating users, fetching and
isolating modules, and managing service policies.
Service containers are user space processes, executing an OSGi
framework for hosting service modules. Each container may
handle different modules, which are OSGi Java bundles, allowing
hot-deployment of them. Hence, the NetServ controller may
install modules in service containers, remove or update them, at
runtime. Each container holds a number of preinstalled modules,
which implement essential services. They include system and
library modules, and wrappers for native system functions. Two
types of modules can be identified: server modules, that acts as a
standard network server, communicating with external resources
through a TCP or UDP port, and packet processing modules, that
can both inspect and modify packets in transit to a node. This
module classification is only logical, since each NetServ module
may act in both ways. This is actually an important NetServ
feature since it overcomes the traditional distinction between
router and server by sharing each other’s capabilities.
Figure 1 – NetServ node internal architecture.
B. OpenFlow Integration
The NetServ prototype architecture described in Section III.A
uses Linux kernel as the packet forwarding plane. We are
currently developing a version of NetServ that can use an
OpenFlow switch as the forwarding plane. Our approach is
described in detail in our companion technical report [24]. We
provide a brief description of the architecture here.
Figure 2 shows the component organization and the packet
paths when NetServ nodes are running on top of an OpenFlow
switch. The NetServ node at the top of the figure hosts the
OpenFlow controller (OFC). The OFC runs as a NetServ module.
At the bottom of the figure, one or more NetServ nodes run
packet processing modules. We call these NetServ nodes
"processing units" (PUs). All the NetServ nodes are connected to
the OpenFlow switch at the center of the figure.
The arrow labeled as the "first packet of a flow" indicates the
path of a packet when it arrives at the OpenFlow switch and the
flow table in the switch does not contain a matching entry. The
packet gets routed to the OFC. The OFC will determine if the
packet should be routed to one of the PUs for processing. If so,
the OFC will instruct the OF switch to add an entry to its flow
table so that the subsequent packets of the same flow will get
routed directly to a PU. The path of the subsequent packets are
depicted as the arrow labeled as the "subsequent packets". The
first packet is processed by a PU as well, since the OFC sends the
packet back to the switch after the flow table entry is inserted.
When we compare the OpenFlow-based NetServ with the
Linux kernel-based one depicted in Figure 1, the benefits of the
OpenFlow-based architecture are clear. The fast data path is in an
OpenFlow switch, a hardware component. The packets that do
not require processing by PUs will get forwarded at the line rate
(as a future work, we want to design an architecture where
instead some modules are hardware processing modules,
implemented by NetFPGA cards [22]).
Moreover, the ability to attach multiple PUs to the OpenFlow
switch effectively eliminates the scalability problem associated
with a single NetServ node. This, in fact, is the key feature that

enabled us to design the scalable autonomic management
architecture that we present in this paper.
The integration of the OpenFlow switch inside the NetServ
architecture enables advanced features and capabilities in an
autonomic management point of view. External services, or the
NAME itself, can exploit remote calls to the OFCs, and hence to
OpenFlow-enabled NetServ nodes, in order to totally control the
data path layer. Gathering several information about the state of
the nodes or traffic statistics is useful to estimated an accurate
network context. The data path maintains counters divided by
table, flow, port and queue, and they include received/transmitted
packets and bytes, flow duration, packet matches and drops,
frame/overrun/CRC errors, collisions. Using this information, the
management engine can easily detect fault situations and alarms,
and plan requested actions to restore a stable network state.
The OpenFlow data path can be utilized to perform active
network management operations directly mangling packet flows,
such as dynamically redirect or output it to certain ports,
split/join/drop flows, manipulate VLANs tags and priority,
change several fields of layer two/three/four headers, create
queue linked to an output port in order to provide Quality-of-
Service support. All this capabilities are performed in hardware,
so they run at wire speed and allows avoiding processing
bottlenecks.
The OFC sends periodically Link Layer Discovery Protocol
(LLDP) [21] messages over the network, in order to advertise
network devices about the identity and capabilities of the
switches that he handles. It also listens for incoming LLDP
frames, so that it can reconstruct the network topology (at least
inside the local area network where the OF switches are located).
NAME can asks this information to OFCs and acquire the
knowledge about local network topologies. This will help it to
better know the actual context and then define needed actions and
strategies to pursue active policies.
Figure 2 – OpenFlow-enabled NetServ node architecture.
The OpenFlow/NetServ integration also adds an important
features to the OpenFlow architecture, since it can exploit the
capabilities of NSIS signaling to discover which part of the
network is managed with OF switches and the identities of
relevant OFCs. This can be done utilizing the newly proposed
NSIS-based discovery protocol, that permits to discover NetServ
nodes within an autonomous system [23]. Finally, according to
the system needs, such as the fulfillment of some policies, the
NAME can choose to replicate or move to any NetServ node the
OFC itself, when it is running inside a NetServ container.
Our experiment described in the next section was performed
using the early prototype of the OpenFlow-based NetServ. The
OpenFlow controller used is a modified version of the Beacon
controller [25], that runs inside the OSGi environment.
IV. CASE STUDY
This section describes an experiment showing the NetServ
platform self-protecting a SIP server from a DoS attack. This
scenario will make use of an IP flow-based intrusion detection
technique [20]. The final goal is to show how OpenFlow-enabled
NetServ nodes can enhance the autonomic management
capabilities of such solution, in particular in terms of
performance and reliability.
In order to detect network attacks, the usual approach for
intrusion detection is to inspect the content of every packet, a
technique also known as deep packet inspection (DPI). However
DPI cannot easily be performed at high speeds, so researchers are
investigating alternative approaches, such as flow-based intrusion
detection [20]. In that kind of approach the analysis is carried out
on the data “flow” through the network, instead of analyzing the
contents of each individual packet. An IP flow is defined as a set
of IP packets passing an observation point in the network during
a certain time interval. All packets belonging to the same flow
have a set of common properties, as source and destination
addresses, source and destination port numbers and IP protocol.
The flow-based intrusion detection is a two-step process, the flow
exporting and the flow collection. The first one is responsible for
creating flow records from observed traffic. This module extracts
the packet header from each packet, marks it with a timestamp
and pass it to the flow collector. The flow collector’s job is to
store these data for monitoring and analyzing it.
Flow-based detection can be seen as a complement of packet
inspection. Both techniques can be combined into a two-stage
detection process. First, a flow-based approach can be used to
detect certain network attacks or a suspicious flow. Then, a DPI
can be used to additionally protect a critical server or to deeply
analyze the nature of a specific flow.
Flows represent aggregated information regarding network
interactions and do not carry payload. With these data, it is still
possible to identify communication patterns between hosts, when
the communication takes place and which amount of traffic has
been exchanged. For many attacks, header information is
sufficient to identify the following classes of attacks: denial of
service (DoS), scans, worms and botnets. Although most

contributions in this area now rely on centralized data processing,
our architecture easily allows using distributed processing units,
because they can be implemented just as a NetServ service and
can be deployed in every NetServ node. Moreover we can also
implement a distributed flow-based detection, because also flow
exporting modules can be remotely deployed. This approach is
very useful in order to potentially detect botnets, because their
detection will involve a long term analysis of large infrastructures
with multiple monitoring points [20].
Figure 3 shows the network topology of this experiment,
which we have implemented in the GENI (Global Environment
for Network Innovation) experimental platform [13]. The victim
is a SIP application server (AS) attached to an OF switch, which
is part of a OpenFlow-enabled NetServ (OF/NS) node. This node
consists of an OF switch an multiple PUs. A separate NetServ
node runs the OFC and the NAME. A Flow-based Intrusion
Detection System (FIDS) service runs inside PU1, implementing
both the flow exporting and the flow collector module. It records
all packets directed toward the SIP AS, reporting statistics and
information to the NAME module.
In our experiment, we have chosen to directly forward the
packets to the SIP AS by the OF switch. At the same time, all SIP
traffic is duplicated and sent to the PU that can monitor and
analyze the traffic. In this way, the working load of the OF switch
is reduced and the packets latency decreased.
Figure 4 shows the signaling flow for the experiment run
inside the GENI environment. At time t1 several SIP requests
arrives to the SIP AS. Different flows goes through the NetServ-
enabled routers (NS1, NS2, NS3) and converge to the OF/NS
node. Flows are directed to the AS and, at the same time, they are
replicated to the first processing unit (PU1). PU1 is in charge to
analyze all the packets with the flow-based intrusion detection
system (FIDS). At time t2 an unknown attacker starts a SIP DoS
passing for the NS1 node. The FIDS on PU1 detects it and
informs the NAME. It decides to send probe requests in all
directions to discover NetServ nodes that can potentially run a
DPI service [16][23]. NAME chooses the NS1 node as the best
candidate for this goal. When the DPI is deployed into NS1, the
service itself takes care of the malicious flow, blocking it if
necessary (at time t3). The attack increases and it is wide spread
across several paths (time t4). In our test bed it goes through NS2
and NS3 nodes. NAME recognize the increased attack rate, and,
at first, decides to instantiate additional OF/NS nodes’s
processing unit to avoid processing bottlenecks. It can takes
advantage of OF/NS capabilities, enabling parallel packet
processing through multiple modules in different PUs. So the
NAME can deploys the FIDS service in additional PU2 and PU3,
and instructs the OFC to split the packets flow over several
output ports, in order to reach each processing node (time t5). On
the basis of reports also from PU2 and PU3, NAME deploys the
DPI service also in the other NetServ boundary nodes, in order to
definitely block the attack (time t6).
In this experiment we have executed NAME and the COF
inside a separate NetServ node, but the division is just logical,
indeed we could have launched both of them also inside a PU of
a OF/NS node or in every other NetServ-enabled node
Figure 5 shows the runtime behaviour of the experiment, in
particular the packet rate of the ingress (solid) and egress (dotted
with marker) interfaces of NetServ boundary nodes. The ingress
interface is the one receiving the aggregate malicious traffic, and
the egress interface is the one forwarding the unblocked portion
of such traffic towards the victim. The SIP server line (green with
marker) shows the traffic arriving to the victim server. The SIP
traffic sent before the attack is 15 packets per second (pkt/s) and
the target rate for the SIP server is 20 pkt/s. When the attacks
begins at t2=28s, an extra traffic beyond the background traffic
arrives at the SIP server, with an attack intensity Ir measured in
pkt/s (in this case Ir = 25 pkt/s, see solid red line). The autonomic
system takes few seconds to recognize it and take the appropriate
decisions. In this case we have that the malicious portion of the
traffic is dropped, leaving the good one untouched.
Figure 3 – Network topology for our DoS experiment on GENI.

Figure 4 – Signaling Flow for the GENI experiment.
During the second phase of the attack, starting at t4=48s, the
aggregate intensity on the victim is doubled (2×Ir ). As in the
previous case, after few seconds, the system react and returns to
an acceptable state.
We have repeated this experiment at different attack rates Ir,
to figure out how the reaction time of our autonomic platform
changes, measured at the ingress interface of the SIP AS. This is
shown in Figure 6, the axis reports the attack intensity Ir
measured in pkt/s. The Figure 6 shows that the reaction time is
basically insensitive to increasing values of traffic intensity. It is
about 1.6 s for the first attack, and 2.4 s for the second one. This
increments is justified by the procedure for deploying additional
PUs. In fact, PU1 detects another attack, but in order to correctly
identify the attack sources, the NAME decides the deployment of
the FIDS module into PU2 and PU3. Then, even if the discovery
phase (NetServ probe messages [16]) is no more needed, it is
necessary to wait the processing outcomes of PU2 and PU3 to
decide where deploying additional DPI modules (NS2 and NS3).

Figure 5 – Runtime behavior of network traffic.
Figure 6 – The reaction time measured at the victim SIP server.
We have also measured the overhead added by having the
OpenFlow controller exchanging messages with the OF switch
(instead of having an usual one) and it has an average rate of 15
Kb/s. The signaling overhead instead, between NAME and the
various NetServ modules has an average rate of 24 Kb/s, while
during the modules deployment we have a peak rate of 500 Kb/s
for about 20 ms. Thus, the overall overhead is well tolerable.
Boundaries NetServ nodes not implemented according to the
OF/NS architecture can have limited processing power, so if the
traffic intensity of the flow to inspect is too high and a node
reaches its limits in terms of CPU and/or memory utilization,
NAME can decide to process only a fraction of the suspect traffic
on that node, leaving the other portion to be forwarded as in an
usual router, so decreasing the processing load on that node,
avoiding traffic losses [26]. Then, NAME can then instruct other
NetServ nodes that are on the same flow’s path to inspect these
remaining packets, just by deploying on them other DPI service
instances. If there are no other NetServ nodes on path, it can
deploy the module directly inside a PU of the OF/NS node. This
case is illustrated in Figure 7. The packets that are not inspected
by a boundary NetServ node are tagged with a VLAN ID so,
when they arrives to the OpenFlow switch, it knows that must not
forward them directly to the SIP server, but must pass through a
PU in order to be processed by the DPI module. The usual
OF/NS architecture has been designed in order to permit packets
processing and mangling inside NetServ modules. In fact, after a
packet is processed by a PU, it goes out and come back to the OF
switch, where it is forwarded to the destination (see also [27]). If
the required bandwidth is very high, we can avoid the OF switch
overloading by adding a second OF switch that will receive all
PUs outbound traffic and will route it to destination (as shown in
Figure 7). With this processing-optimized architecture, we can
halve the packet load in the first OF switch.
When the elaboration must be splitted across several PUs, the
OFC informs the OF switch that a certain type of packet flow
must be equally splitted to the NICs where the PUs are attached.
Now, to our best knowledge, it is not possible to perform this
type of action inside an OF switch, but it will when the OF
specifications v.1.2 will be ready. It will contain an extension of
the usual flow mod command that can match every bit inside the
packet header, so we can utilize, e.g., the packet identification
field in the IP header (IP ID), to split the packet flow by
comparing it to a bitmask. In our implementation, we split the
flow utilizing another technique. We send the whole packet flow
to every involved PU by replicating it. The packet separation is
done inside the linux kernel, taking advantage of the netfilter u32
module that can extend a filtering rule matching a certain bit’s
pattern of a packet. So part of the traffic is just dropped by the
kernel, whereas the portion matching the bitmask on the IP ID is
forwarded to the user space to NetServ modules.
An additional consideration is that deployed service as the
same as in usual NetServ nodes as in PUs of the OF/NS node.
This means that the developer can write his service logic utilizing
a common API without knowing on which platform the service
will run. The API will then implement different functions
depending of the different running platform, exploiting the OF
data path power if present.
V. CONCLUSION
This paper illustrates how the OpenFlow technology can be
utilized to further enhance an implementation of an autonomic
management architecture, based on the NetServ programmable
node architecture. OpenFlow has been integrated with NetServ,
utilizing an OpenFlow-enabled switch as an hardware data path
for a NetServ node, enabling wire speed capabilities. An ad-hoc
OpenFlow controller is used to control the packet flow from the
switch to the node, that is still the container for packet processing
and services modules. Adding this capabilities to the NetServ
autonomic management platform improves its performances and
flexibility. It allows a full control over the node data path,
allowing to avoid bottlenecks through directly mangle packet

Figure 7 – Processing-optimized architecture.
flows, and allowing an accurate packet statistics monitoring.
Processing power constrain can be well managed and solved
through the use of multiple PUs attached to the same data path.
In order to show the effectiveness of the platform, we have
presented a case study carried out on the GENI environment,
which highlights the flexibility of the NetServ management
architecture and the enhanced capabilities of a OpenFlow-
enabled NetServ node. The experiment shows the self-protecting
features against a DoS attack to a SIP application server, utilizing
a flow-based intrusion detection techniques. The results are that
the reaction times are nearly insensitive to increased traffic
intensity, and the overall signaling overhead is acceptable.
VI. REFERENCES
[1] K. Park, “The Internet as a complex system”, K. Park and W. Willinger,
Editors, The Internet as a Large-Scale Complex System, Oxford University
Press, 2005.
[2] B. Jennings et al., “Towards Autonomic Management of Communications
Networks”, IEEE Communications Magazine, 45(10), 2007.
[3] N. Agoulmine e al., “Challenges for Autonomic Network Management”,
MACE 2006, October 2006, Dublin, Ireland.
[4] J. O. Kephart, D. M. Chess, “The Vision of Autonomic Computing”, IEEE
Computer Magazine, 36(1), 2003.
[5] J. Strassner et al. “The Design of a New Policy Model to Support
Ontology-Driven Reasoning for Autonomic Networking”, Journal of
Network and Systems Management, 17(1-2), 2009.
[6] L. Cheng, et al., “Self-organising Management Overlays for Future
InternetServices”, MACE 2008, September 2008, Samos Island, Greece.
[7] B. Mathieu et al., “Self-Management of Context-Aware Overlay Ambient
Networks”, IFIP/IEEE IM 2007, Munich, Germany, May 2007.
[8] S. Balasubramaniam et al., “BiRSM: bio-inspired resource self-
management for all IP-networks”, IEEE Network, 24(3), 2010, pp. 20-25.
[9] S.S. Kim et al., “Towards Management of the Future Internet”, IFIP/IEEE
IM 2009, Long Island, NY, USA, June 2009.
[10] H. Ballani, C. Francis, “CONMan: taking the complexity out of network
management”, INM’06 workshop, Pisa, Italy, September 2006.
[11] J.W. Lee et al, “NetServ: Active Networking 2.0”, IEEE FutureNet IV
2011 Workshop, Kyoto, Japan, June 2011.
[12] X. Fu et al., “NSIS: a new extensible IP signaling protocol suite”, IEEE
Communications Magazine, 43(10), 2005, pp. 133- 141.
[13] The Global Environment for Network Innovations (GENI) project,
http://www.geni.net.
[14] The OpenFlow Project Website, http://www.openflow.org.
[15] N. McKeown et al, “OpenFlow: Enabling Innovation in Campus
Networks”,ACM SIGCOMM Computer Communication, 38(2), April
2008.
[16] M. Femminella et al, “An Enabling Platform for Autonomic Management
of the Future Internet”, to appear in IEEE Network Magazine, Special Issue
on Managing an Autonomic Future Internet, 2011, available for reviewers
at: http://conan.diei.unipg.it/pub/netserv-mngmt.pdf.
[17] M. Serrano et al, “Review and Designs of Federated Management in Future
Internet Architectures”, FIA book 2011 "Future Internet: Achievements
and Promising Technology", Springer Verlag, 2011.
[18] Univerself project website, http://www.univerself-project.eu.
[19] D. Dudkowski et al, “Architectural Principles and Elements of In-Network
Management”, IFIP/IEEE IM 2009, Long Island, NY, USA, June 2009.
[20] A. Sperotto et al., “An Overview of IP Flow-Based Intrusion Detection”,
IEEE Communications Surveys & Tutorials, 12(3), 2010, pp. 343 – 356.
[21] Link Layer Discovery Protocol, IEEE 802.1AB,
http://ieee802.org/1/pages/802.1ab.html.
[22] NetFPGA Project Website, http://netfpga.org.
[23] M. Femminella, R. Francescangeli, G. Reali, H. Schulzrinne, "Gossip-
based Signaling Dissemination Extension for Next Steps in Signaling",
Tech. Report, available at: http://conan.diei.unipg.it/pub/nsis-gossip.pdf.
[24] E. Maccherani et al., "NetServ on OpenFlow 1.0", Technical Report
CUCS-036-11, Columbia University, September 2011, available at:
http://www.cs.columbia.edu/~jae/papers/netserv-openflow-tr-1.0.pdf,.
[25] Beacon Controller Website,
http://www.openflowhub.org/display/Beacon/Beacon+Home.
[26] S. Srinivasan et al., “NetServ: Dynamically Deploying In-network
Services”, ACM CoNEXT, ReArch workshop, Rome, Italy, December
2009.
[27] A. Greenhalgh et al, “Flow Processing and the Rise of Commodity
Network Hardware”, ACM SIGCOMM Computer Communication, 39(2),
April 2009.