2
networks and decoupled control logic has been around for
many years. In this section, we provide an overview of early
programmable networking efforts, precursors to the current
SDN paradigm that laid the foundation for many of the ideas
we are seeing today.
a) Open Signaling: The Open Signaling (OPENSIG)
working group began in 1995 with a series of workshops
dedicated to “making ATM, Internet and mobile networks
more open, extensible, and programmable” [6]. They believed
that a separation between the communication hardware and
control software was necessary but challenging to realize; this
is mainly due to vertically integrated switches and routers,
whose closed nature made the rapid deployment of new
network services and environments impossible. The core of
their proposal was to provide access to the network hardware
via open, programmable network interfaces; this would allow
the deployment of new services through a distributed program-
ming environment.
Motivated by these ideas, an IETF working group was
created, which led to the specification of the General Switch
Management Protocol (GSMP) [7], a general purpose pro-
tocol to control a label switch. GSMP allows a controller
to establish and release connections across the switch, add
and delete leaves on a multicast connection, manage switch
ports, request configuration information, request and delete
reservation of switch resources, and request statistics. The
working group is officially concluded and the latest standards
proposal, GSMPv3, was published in June 2002.
b) Active Networking: Also in the mid 1990s, the
Active Networking [8], [9] initiative proposed the idea of
a network infrastructure that would be programmable for
customized services. There were two main approaches being
considered, namely: (1) user-programmable switches, with in-
band data transfer and out-of-band management channels;
and (2) capsules, which were program fragments that could
be carried in user messages; program fragments would then
be interpreted and executed by routers. Despite considerable
activity it motivated, Active Networking never gathered crit-
ical mass and transferred to widespread use and industry
deployment, mainly due to practical security and performance
concerns [10].
c) DCAN: Another initiative that took place in the
mid 1990s is the Devolved Control of ATM Networks
(DCAN) [11]. The aim of this project was to design and
develop the necessary infrastructure for scalable control and
management of ATM networks. The premise is that control and
management functions of the many devices (ATM switches in
the case of DCAN) should be decoupled from the devices
themselves and delegated to external entities dedicated to that
purpose, which is basically the concept behind SDNs. DCAN
assumes a minimalist protocol between the manager and the
network, in the lines of what happens today in proposals such
as OpenFlow. More on the DCAN project can be found at [12].
Still in the lines of SDNs and the proposed decoupling of
control and data plane over ATM networks, amongst others,
in the work proposed in [13] multiple heterogeneous control
architectures are allowed to run simultaneously over single
physical ATM network by partitioning the resources of that
switch between those controllers.
d) 4D Project: Starting in 2004, the 4D project [14],
[15], [16] advocated a clean slate design that emphasized
separation between the routing decision logic and the pro-
tocols governing the interaction between network elements.
It proposed giving the “decision” plane a global view of the
network, serviced by a “dissemination” and “discovery” plane,
for control of a “data” plane for forwarding traffic. These ideas
provided direct inspiration for later works such as NOX [17],
which proposed an “operating system for networks” in the
context of an OpenFlow-enabled network.
e) NETCONF: In 2006, the IETF Network Configu-
ration Working Group proposed NETCONF [18] as a man-
agement protocol for modifying the configuration of network
devices. The protocol allowed network devices to expose an
API through which extensible configuration data could be sent
and retrieved.
Another management protocol, widely deployed in the past
and used until today, is the SNMP [19]. SNMP was proposed
in the late 80’s and proved to be a very popular network
management protocol, which uses the Structured Management
Interface (SMI) to fetch data contained in the Management
Information Base (MIB). It could be used as well to change
variables in the MIB in order to modify configuration settings.
It later became apparent that in spite of what it was originally
intended for, SNMP was not being used to configure network
equipment, but rather as a performance and fault monitoring
tool. Moreover, multiple shortcomings were detected in the
conception of SNMP, the most notable of which was its lack
of strong security. This was addressed in a later version of the
protocol.
NETCONF, at the time it was proposed by IETF, was
seen by many as a new approach for network management
that would fix the aforementioned shortcomings in SNMP.
Although the NETCONF protocol accomplishes the goal of
simplifying device (re)configuration and acts as a building
block for management, there is no separation between data
and control planes. The same can be stated about SNMP.
A network with NETCONF should not be regarded as fully
programmable as any new functionality would have to be
implemented at both the network device and the manager so
that any new functionality can be provided; furthermore, it is
designed primarily to aid automated configuration and not for
enabling direct control of state nor enabling quick deployment
of innovative services and applications. Nevertheless, both
NETCONF and SNMP are useful management tools that
may be used in parallel on hybrid switches supporting other
solutions that enable programmable networking.
The NETCONF working group is currently active and the
latest proposed standard was published in June 2011.
f) Ethane: The immediate predecessor to OpenFlow was
the SANE / Ethane project [20], which, in 2006, defined
a new architecture for enterprise networks. Ethane’s focus
was on using a centralized controller to manage policy and
security in a network. A notable example is providing identity-
based access control. Similar to SDN, Ethane employed two
components: a controller to decide if a packet should be
forwarded, and an Ethane switch consisting of a flow table