Ieee communication surveys & tutorials, vol. 16, No. 4, Fourth quarter 2014

Why OpenFlow for optical networks? There is a great deal

of benefits when adopting SDN/OpenFlow for optical network

control: (1) Current optical networks have difficulties to react

independently to requests from client systems distributed at the

network edge. SDN provides programmable, abstracted inter-

face for flexible application re-configurations in optical control

units. (2) Existing optical networks cannot easily upgrade the

software in each optical switch due to the embedded software

nature. OpenFlow could easily upgrade services due to its sep-

aration of control and data planes. (3) SDN/OpenFlow allows

multi-level abstraction via its networked re-programming and

virtualization technologies. This makes optical network stack

suit easily adapt to different network topologies. (4) The cost

of optical hardware is typically high, especially the photonics

and associated electronic components. SDN/OpenFlow could

reduce those costs due to its ‘dump’ hardware operations—just

simply following the flow table.

B. OpenFlow for Wireless Sensor Networks

Wireless sensor networks (WSN) have become important

platforms for environmental monitoring. There are many sensor

hardware designs such as CrossBow, Imotes, etc. However,

all those sensor products cannot be easily programmed due to

vendor-specific SDK (software development kit) and the tight

integration of hardware and software in one sensor node.

Moreover, those sensors are difficult to re-task [115], [116]

if a new environmental monitoring mission is required. For

example, how can we re-program 100 sensors in a lake WSN

to detect a new type of pollution? Obviously today we need

---

HU et al.: SURVEY ON SDN AND OPENFLOW: FROM CONCEPT TO IMPLEMENTATION

2199

Fig. 20.

SDN-based sensor networks.

to take each sensor out of the water and change the programs

embedded into the sensor hardware. This is not realistic in

large-scale WSN with so many nodes.

Although some over-the-air programming techniques are

used for some vendors’ sensor boards, their data sensing and

forwarding schemes are still vendor-specific. For example, they

may use different operating systems, or different programming

languages. The programmer needs to check different manuals

to get familiar with the API functions. It will be better if

the user just simply configure a network controller based on

universal networked operating system. The sensor hardware

and embedded stack protocols could be decoupled such that the

users do not need to worry about the data forwarding details

in each sensor, and just simply configure the controller’s flow

table. The data forwarding rules do not necessarily follow the

specific MAC layer protocols (such as ZigBee, 802.11, or other

protocols).

SDN/OpenFlow can well solve the above issues. It makes

each sensor just simply forward the sensor data based on the

specified flow table and rules. All those rules can be easily

changed through controllers’ programming. Since all nodes fol-

low universal operating system (such as NOX), the re-tasking

can be easily achieved by following standard scripts program-

ming. A Software-Defined WSN architecture, called sensor

openflow [116], can be used to address key technical challenges

mentioned above. We illustrate its main ideas in Fig. 20.

It has three layers: the application layer has all sensor data

query related applications such as local data processing; the

control plane and data plane are totally separate: the former can

remotely re-configure the sensor parameters, and the latter can

check the flow table and perform the corresponding actions. Its

main idea is to make the large-scale sensor network easy-to-

manage via programmable control plane and user-customizable

flow table. Sensors are no longer application-dependent and the

sensor data query policies can be easily reset. Sensor OpenFlow

allows policy changes in an easy style since a programmer can

simply change the controller’s software instead of dealing with

the wireless sensors.