Network Integration

University of Murcia
Computer Science Faculty

SDN in IoT

Author:
Sara N. Matheu Garca

June 2, 2016

SDN in IoT

Sara N. Matheu Garca

Contents
1 Introduction

2 SDN

3 SDN in IoT
3.1 SDN based architecture for IoT: Sensor Openflow (SOF) . . .
3.2 Security in SDN for IoT . . . . . . . . . . . . . . . . . . . . .

5
6
9

4 Conclusions

11

List of Figures
1
2
3
4
5
6
7

SDN architecture[8] . . . . . . . . . . . . . . . . . . . . . .
Use of OXM SOF CAV type for 30 < temperature < 60 [7]
Sensor OpenFlow architecture [7] . . . . . . . . . . . . . .
Peer compatibility in SOF[7] . . . . . . . . . . . . . . . . .
SDN Domains[2] . . . . . . . . . . . . . . . . . . . . . . .
Interconnection between domains [2] . . . . . . . . . . . .
Security in SDN domains [2] . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.

. 4
. 7
. 8
. 9
. 10
. 11
. 12

Introduction

With the exponential growth of devices connected to the Internet, security

networks as one of the hardest challenge for network managers. Maintaining
and securing such large scale and heterogeneous network is a challenging
task. In this context, the new networking paradigm, the Software Defined
Networking (SDN), introduces many opportunities and provides the potential
to overcome those challenges.
Software-Defined Networking has emerged as a new paradigm for enabling
innovation in networking research and development. The control and data
planes are decoupled while network intelligence and state are logically centralized. A new device called controller connects to the switch through a
secured OpenFlow channel and manages this switch via the OpenFlow protocol (there are other protocols, but OpenFlow is the most used). The controller can add, update, and delete flow entries, both reactively in response
to packets and proactively with predefined rules. Moreover, SDN enables fast
reaction to security threats, granular traffic filtering, and dynamic security
policies deployment.
1

SDN in IoT

Sara N. Matheu Garca

The goal of SDN is to allow network engineers and administrators to respond quickly to changing business requirements. In a software-defined network, a network administrator can shape traffic from a centralized control
console without having to touch individual switches, and can deliver services
to wherever they are needed in the network, without regard to what specific devices a server or other device is connected to. The key technologies
are functional separation, network virtualization and automation through
programmability.
With SDN, the applications can be network aware, as opposed to traditional networks where the network is application aware and the control plane
is logically centralized and decoupled from the data plane. The SDN Controller summarizes the network state for applications and translates application requirements to low-level rules. This does not imply that the controller
is physically centralized. For performance, scalability, and/or reliability reasons, the logically centralized SDN Controller can be distributed so that several physical controller instances cooperate to control the network and serve
the applications. The SDN Controller has complete control of the SDN Datapaths, subject to the limit of their capabilities. This allows networks to run
with complex and precise policies with greater network resource utilization
and quality of service guarantees.
With these properties, the SDN architecture has a lot of advantages,
because it is:
Directly programmable: Network control is directly programmable because it is decoupled from forwarding functions.
Agile: Abstracting control from forwarding lets administrators dynamically adjust network-wide traffic flow to meet changing needs.
Centrally managed: Network intelligence is (logically) centralized in
software-based SDN controllers that maintain a global view of the network, which appears to applications and policy engines as a single,
logical switch.
Programmatically configured: SDN lets network managers configure,
manage, secure, and optimize network resources very quickly via dynamic, automated SDN programs, which they can write themselves
because the programs do not depend on proprietary software.
Open standards-based and vendor-neutral: When implemented through
open standards, SDN simplifies network design and operation because
instructions are provided by SDN controllers instead of multiple, vendorspecific devices and protocols.
2

SDN in IoT

Sara N. Matheu Garca

The problem of IoT networks is that they are rigid to policy changes. Policies are rules related to network-exogenous factors such as business operation
and user access. Policy changes, engendered by the ever-changing business
needs, are hard to cope with by algorithms and often dictate manual reconfiguration or reprogramming of IoT networks. They are also hard to manage.
This is because developing a network management system (NMS) for distributed WSN is a demanding task in the first place. The above problems
are not superficial symptoms but are inherent to IoT networks. Although
this architecture works well most of the time due to many well-designed algorithms, it lacks good abstraction and carries too much complexity, making
IoT networks unwieldy, inelastic to change and hard to manage. As a result of this, there are many articles that propose a solution using SDN with
IoT networks such as [7], that creates a new architecture based on OpenFlow taking into account the problems of the IoT devices, [4], which explains
briefly how SDN and IoT can work together and [9], that proposes a new
SDN controller and is more centered in latency problems. We are going to
see the first proposal in the subsection 3.1, since OpenFlow is a well known
protocol in SDN and it analyses all the problems derived of joining SDN and
IoT, which is very interesting.
In terms of security, SDN architecture extends the security perimeter to
the network access end point devices (access switches, wireless access points,
etc.), by pushing security policies to those devices. This is a good advantage
that can be used in the IoT field. However, although as we said before some
authors have proposed architecture for IoT, security is usually a forgotten
topic. We can find some articles regarding security like [2], [1] or [10]. We are
going to see the first proposal in the subsection 3.2, since the three articles
are very similar, the idea is the same.

SDN

Software-defined networking (SDN) is an approach to computer networking

that allows network administrators to manage network services through abstraction of higher-level functionality. This is done by decoupling the system
that makes decisions about where traffic is sent (the control plane) from the
underlying systems that forward traffic to the selected destination (the data
plane).
The main entities of the SDN architecture are, as we can see in figure 1:
SDN Application (SDN App): SDN Applications are programs that
communicate their network requirements and desired network behaviour
to the SDN Controller via NBIs (SDN Northbound interfaces). An
3

SDN in IoT

Sara N. Matheu Garca

Figure 1: SDN architecture[8]

SDN Application consists of one SDN Application Logic and one or
more NBI Drivers.
SDN Controller: The SDN Controller is a logically centralized entity
in charge of translating the requirements from the SDN Application
layer down to the SDN Datapaths and providing the SDN Applications
with an abstract view of the network (which may include statistics and
events). An SDN Controller consists of one or more NBI Agents, the
SDN Control Logic, and the CDPI driver.
SDN Datapath: The SDN Datapath is a logical network device. The
logical representation may encompass all or a subset of the physical
substrate resources. An SDN Datapath comprises a CDPI agent and
a set of one or more traffic forwarding engines and zero or more traffic
processing functions. These engines and functions may include simple
forwarding between the datapaths external interfaces or internal traffic
processing or termination functions. An SDN Datapath may also be
defined across multiple physical network elements.
4

SDN in IoT

Sara N. Matheu Garca

SDN Control to Data-Plane Interface (CDPI): The SDN CDPI is the

interface defined between an SDN Controller and an SDN Datapath,
which provides at least programmatic control of all forwarding operations, capabilities advertisement, statistics reporting, and event notification. Here we can find protocols such as OpenFlow.
SDN Northbound Interfaces (NBI): SDN NBIs are interfaces between
SDN Applications and SDN Controllers and typically provide abstract
network views and enable direct expression of network behavior and
requirements.
Interface Drivers and Agents: Each interface is implemented by a
driver-agent pair, the agent representing the southern, bottom, or
infrastructure facing side and the driver representing the northern,
top, or application facing side.
Management and Admin: The Management plane covers static tasks
that are better handled outside the application, control and data planes.
Examples include assigning resources to clients, coordinating reachability and credentials among logical and physical entities, configuring
bootstrapping, etc.
There is increased network performance with multiple controllers, because
each controller has a partial view of the network, and the controllers have
to collaborate and exchange informations with each other. The interaction
between the Controller(s) and the enabled switches is essentially to have one
switch multi-homed to multiple controllers. If one of the controllers goes
down, another is ready to control the switch. Openflow, for example, since
version 1.2, specifies two modes of operation when multiple controllers exist in
the network: Equal interaction, where all controllers have read/write access
to the switch, and master/slave interaction, where there will be one master
and multiple slaves.

SDN in IoT

The exponential growth of devices connected to the network has resulted in

the development of new IoT applications and on-line services. However, these
advances are limited by the rigidity of the current network infrastructure, in
which the administrator has to implement high-level network policies adapting and configuring protocols manually and usually through a command line
interface (CLI). At this point, Software-Defined Networking (SDN) appears
5

SDN in IoT

Sara N. Matheu Garca

as a viable alternative network architecture that allows for programming

the network and opening the possibility of creating new services and more
efficient applications to cover the actual requirements.
The problem of IoT networks is that they are rigid to policy changes. Policies are rules related to network-exogenous factors such as business operation
and user access. Policy changes, engendered by the ever-changing business
needs, are hard to cope with by algorithms and often dictate manual reconfiguration or reprogramming of IoT networks. They are also hard to manage.
This is because developing a network management system (NMS) for distributed WSN is a demanding task in the first place. The above problems
are not superficial symptoms but are inherent to IoT networks. Although
this architecture works well most of the time due to many well-designed algorithms, it lacks good abstraction and carries too much complexity, making
IoT networks unwieldy, inelastic to change and hard to manage. As a result
of this, there are many articles that propose a solution using SDN with IoT
networks. We are going to see one of this proposals, made by T.Luo, which
is Sensor OpenFlow.

3.1

SDN based architecture for IoT: Sensor Openflow

(SOF)

Despite of the benefits of using SDNS, there are some technicals challenges
that must be solved in order to adapt SDNs to IoT.
One of the problems is that at the data plane, packets are handled as per
flows. A flow is a programmable set of packets that share certain properties specified by a Match in a flow-table entry, or flow entry for short. The
Match is often wild-carded, like IP source address is 10.0.*.*, and packets that match it will be treated as in the same flow and be imposed an
action specified by the same flow entry. OpenFlow implicitly assumes the
presence of IP-like addressing so as to create flows. For example, it defines
Match fields such as IPv4 SRC or ETH DST to match packets with IPv4
source address or Ethernet destination, respectively. However, as opposed to
address-centric OpenFlow networks, IoT networks are typically data-centric,
that is, acquiring data of interest is more important than knowing who sent
the data, and employ different addressing such as attribute-based naming.
This problem could be solved, as T. Luo proposes in [7] augmenting the
network with IP, using for example UIP on Contiki OS or Blip on TinyOS,
which are IP implementations for low power networks, or redefining flow
tables in order to add the addressing schemes of these type of networks.
For compact unique addresses, they explote the OpenFlow extensible match

SDN in IoT

Sara N. Matheu Garca

(OXM), a type-length-value (TLV) format used to define flow Matches and

they introduce two new types to represent source (OXM SOF SRC) and
destination (OXM SOF DST). For concatenated attribute-value pairs such
as 30 < temperature < 60 they add a new oxm type, OXM SOF CAV, as
we can see in figure 2.

Figure 2: Use of OXM SOF CAV type for 30 < temperature < 60 [7]
Another problem of this adaptation is that an OpenFlow channel is an
end-to-end connection used to transmit control messages between a controller
and a switch. However, this channel must provide TCP/IP connectivity for
reliable end-to-end in-order message delivery. These are generally unavailable
in this networks and need to be addressed. This problem is solved using
IP implementations like the described before, which include ready to use
TCP implementations or overlying a transport protocol[6] directly over the
network if we choose the solution of redefining flow tables.
We also have a problem with the overhead of control traffic. SDN can
(and usually would) host the OpenFlow channel out of band, i.e., using a
separate dedicated network. This is normally not practical for constrained
networks and the SOF channel has to be hosted in band, i.e., by the network
itself. Thus, the resource constrained networks will have to additionally
carry control traffic between controllers and sensors. This is a big problem
since the control traffic in this networks tends to be large due to the high
network dynamics (node/link failures, energy-aware routing, mobility, etc.).
Hence, without a proper mechanism to curb control traffic overhead, the
underlying network can be overloaded. Taking into account that control
traffic in mainly composed by packet-in when a sensor wants to know what
to do with a packet and packet-out, which is the response of the controller
with the instructions for that packet, and knowing that in this networks an
important event can trigger a lot of packets from several sensor leading to
many flows simultaneously, the proposal is to send only one packet-in for
all the packets with the same destination until the packet-out arrives or a
predefined timeout occurs.
Another problem is the traffic generation. End-users are considered peripheral to SDN and hence out of the scope of OpenFlow. On the contrary,
sensor nodes behave like end-users by generating data packets, in addition
to merely forwarding data as OpenFlow switches do. The author proposes
adding a traf-gen module on each sensor as in the figure 3. It is a simple
7

SDN in IoT

Sara N. Matheu Garca

module that can be implemented as an interrupt routine, because sensory

data generation consists of two very simple steps: reading data from the
sensing hardware, and converting the data if needed.

Figure 3: Sensor OpenFlow architecture [7]

At times, WSN need to process data in situ, for example to perform
data aggregation or decision fusion, in order to reduce data redundancy and
conserve network resource such as bandwidth and energy. This is another
feature absent in SDN. This could be solved adding a in-net proc module.
If the processing is not needed by a packet, this module simply passes the
packet intact to the flow table. However, this module makes the design not
purely clean-slate, but as data aggregation is the most common in-network
processing and can usually be accomplished using standard operations such as
average, median, min, max, or removing redundant data, it could be absorbed
into flow tables as a special way of packet handling. This is something to
discuss.
As a final requirement, this architecture should desirably provide backward compatibility, with respect to traditional (non-OpenFlow and nonSOF) networks, so as to protect legacy investments. It is also desirable
for SOF to offer peer compatibility, i.e., to be compatible with OpenFlow
networks which are concurrently being developed and standardized, for in8

SDN in IoT

Sara N. Matheu Garca

teroperability purposes. SOF inherits backward compatibility from OpenFlow. An SOF-hybrid sensor will have a logical port defined similarly as by
OpenFlow, which directs packets to traditional sensor network forwarding, so
there are not problems. The only thing to manage is the peer compatibility.
To be compatible with OpenFlow, SOF should enable OpenFlow to recognize SOF flow tables so that OpenFlow can relegate the new addressing
types that we defined before to SOF. For this new flows, they designate two
unused values of ETH TYPE, 0x0802 and 0x0808, respectively. Thus, an
SOF flow entry (oxm type=OXM SOF SRC/DST or OXM SOF CAV) can
be defined as in figure 4, which achieves peer compatibility.

Figure 4: Peer compatibility in SOF[7]

3.2

Security in SDN for IoT

With the exponential growth of devices connected to the Internet, security

networks have become one of the hardest challenge for network managers.
Maintaining and securing such large scale and heterogeneous network is a
challenging task. Software Defined Networking introduces many opportunities and provides the potential to overcome those challenges. In [2], O.
Flauzac proposes a SDN based architecture for IoT defining SDN domains
and describing how to interconnect domains and how to distribute the security rules in order not to compromise the security of one domain.
This proposal is based in the use of multiple controllers with equal interaction. We can divide the nodes in sensor or constrained devices and nodes
with enough resources, that will be called OF nodes, because OpenFlow protocol is used. Sensors will be associated to OF nodes and OF nodes will
have a legacy interface (physical layer), SDN compatible virtual switch and
controller (programmable layer) and operating system and applications (OS
layer). In this model, all legacy interfaces are connected to a virtual switch,
and this switch is controlled by an SDN controller, integrated on the node.
Users will connect with other nodes through their embedded SDN-compatible
switch. At the same time, the SDN controller, in equal interaction, can enhance the security and connectivity between the nodes.

SDN in IoT

Sara N. Matheu Garca

Figure 5: SDN Domains[2]

As a result, each domain has its SDN controller (or multiple controllers)
which controls all traffic in its domain, and we have two types of nodes in a
domain, sensors and OF nodes. A domain could be an enterprise network or
a datacenter. The figure 5 shows the current scenario.
An SDN-based architecture for the IoT requires interconnection with a
large number of SDN domains. In order to achieve such large scale interconnection, they introduce a new type of controller in each domain, the root
controller, also called a Border controller. They propose not to distribute
control functions on multiple controllers but to distribute routing functions
and security rules on each border controller. These controllers are also responsible for establishing connections and exchanging information with other
SDN border controllers. We can see the full scenario in the figure 6.
In order to secure network access and network resources, the SDN controllers begin by authenticating the network devices. Once the OpenFlow
secure connection between the switch and the controller is established, the
controller blocks switch ports directly connected to the users. After that,
the controller authorizes only users authentication traffic. Once the user
is authenticated, and based on the authorization level of the user, the controller will push the appropriate flow entries to the software or the hardware
access switch. This authentication process is extended to devices. Each device has to associate itself with an OpenFlow enable node, each of which is

10

SDN in IoT

Sara N. Matheu Garca

Figure 6: Interconnection between domains [2]

connected to one controller in their domain. Border Controllers behave as
security guards on the edge of the extended SDN Domain to ensure the network safety. Safety connections between domains could be provisioned and
only added to SDN Controllers. Only recognized traffic could be accepted.
The controllers know policies in their domain but they do not know policies
of the other domains. So, when a node wants to communicate with another
node of another domain, the flow has to be forward to the Border Controller
and it will ask each neighbour controller if it knows the destination of the
information, as we can see in figure 7.

Conclusions

The problem of IoT networks is that they are rigid to policy changes. Policies
are rules related to network-exogenous factors such as business operation and
user access. Policy changes, engendered by the ever-changing business needs,
are hard to cope with by algorithms and often dictate manual reconfiguration or reprogramming of IoT networks. They are also hard to manage. This
is because developing a network management system (NMS) for distributed
WSN is a demanding task in the first place. The above problems are not
11

SDN in IoT

Sara N. Matheu Garca

Figure 7: Security in SDN domains [2]

superficial symptoms but are inherent to IoT networks. Although this architecture works well most of the time due to many well-designed algorithms,
it lacks good abstraction and carries too much complexity, making IoT networks unwieldy, inelastic to change and hard to manage. As a result of this,
there are many articles that propose a solution using SDN with IoT networks.
We have seen the T. Luo proposal, which analyses the problems of these type
of networks and creates an architecture based on SDNs adapted to IoT.
In terms of security, many works have studied it using the SDN architecture, either by implementing firewalls, IPS and IDS modules on top of the
SDN controller [3], [5], [11], or by installing security policies into OpenFlow
switches, but they have not take into account security solutions in IoT, except the proposals we have mentioned in the section 1, one of them explained
with details in subsection 3.2.
The emergence of the next generation Internet architecture, requires high
security levels, such as authenticating network devices, users and objects
connecting to users, authorization mechanisms and key distribution solutions,
but nowadays, we can conclude that this is a field that is not explored yet.

12

SDN in IoT

Sara N. Matheu Garca

References
[1] C.P, V. Security improvement in iot based on software defined networking (SDN). International Journal of Science, Engineering and Technology Research (IJSETR) 5 (2016).
[2] FLAUZAC, O., GONZALEZ, C., HACHANI, A., and NOLOT,
F. SDN based architecture for iot and improvement of the security.
IEEE (Mar. 2015).
[3] Hu, H., Han, W., Ahn, G.-J., and Zhao, Z. FLOWGUARD:
Building robust firewalls for software-defined networks. Workshop on
Hot Topics in Software Defined Networking (2014).
[4] Huang, H., Zhu, J., and Zhang, L. An sdn based management
framework for iot devices. In Irish Signals & Systems Conference 2014
and 2014 China-Ireland International Conference on Information and
Communications Technologies (2014).
[5] Jin, R., and Wang, B. Malware detection for mobile devices using
software defined networking. Proceedings of the Workshop of Research
and Educational (2013).
[6] Luo, T., Tan, H. P., and Quek, T. Q. S. A compiled list of
transport protocols for wireless sensor networks. May 2012.
[7] Luo, T., Tan, H. P., and Quek, T. Q. S. Sensor openflow: Enabling
software-defined wireless sensor networks. IEEE COMMUNICATIONS
16, 11 (Nov. 2012), 4.
[8] Open Networking Foundation. SDN architecture overview, Dec.
2013.
[9] Qin, Z., Denker, G., Giannelli, C., Bellavista, P., and
Venkatasubramanian, N. A software defined networking architecture for the internet-of-things. IEEE (2014).
[10] Sahoo, K. S., Sahoo, B., and Panda, A. A secured sdn framework
for iot.
[11] Skowyra, R., Bahargam, S., and Bestavros, A. Software-defined
ids for securing embedded mobile devices. In Proceedings of the High
Performance Extreme Computing Conference (2013).

13