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

# Topology

Example_topo

= nxtopo.NXTopo ( )

Example_topo.add_switch (name

= “A”, ports [1,2,3,4])

Example_topo.add_switch (name

= “B”, ports [1,2,3,4])

Example_topo.add_link ((“A”, 4), (“B”, 4))

# Mappings

P_map

= “A”: “S2”, “B”: “S3”

Q_map

= identity_port_map (Example_topo, P_map)

Maps

= (P_map, Q_map)

# predicates

P reds =

\

([(p, header (“srcport”, 80))

For p in Example_topo.edge_ports (“A”)

+

[(p, header (“dstport”, 80))

For p in Exam_topo.edge_ports (“B”)])

# slice constructor

Slice

= Slice (Example_topo, phys_topo, maps, preds)

In the above example, we first define a network topology

called Example_topo, which has two switches: A and B. The

switches have 3 edge ports each. Then we define the switch

→

port mappings. Switch A maps to S2, and B maps to S3. Then

we associate a predicate with each edge port. The predicates

can map traffic (web only) to the slice. The last line officially

creates a slice [138].

III. C

ONTROLLER

The control plane can be managed by a central controller

or multiple ones. It gives a global view of the SDN status

to upper application layer. In this section, we look into the

---

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

2189

architecture and performance of controller in software defined

networks.

A. Types of Controllers

While SDN is suitable for some deployment environments

(such as homes [76], [77], data centers [78], and the enterprise

[79]), delegating control to a remote system has raised a number

of questions on control-plane scaling implications of such an

approach. Two of the most often voiced concerns are: (a) how

fast the controller can respond to data path requests; and (b)

how many data path requests it can handle per second. For

software controller, there are four publicly-available OpenFlow

controllers: NOX, NOX-MT, Beacon, and Maestro [80].

A typical OpenFlow controller is NOX-MT [80]. NOX [48]

whose measured performance motivated several recent propos-

als on improving control plane efficiency has a very low flow

setup throughput and large flow setup latency. Fortunately, this

is not an intrinsic limitation of the SDN control plane: NOX is

not optimized for performance and is single-threaded.

NOX-MT is a slightly modified multi-threaded successor

of NOX. With simple tweaks we are able to significantly

improve NOX’s throughput and response time. The techniques

used to optimize NOX are quite well-known: I/O batching to

minimize the overhead of I/O, porting the I/O handling harness

to Boost Asynchronous I/O (ASIO) library (which simplifies

multi-threaded operation), and using a fast multiprocessor-

aware malloc implementation that scales well in a multi-core

machine.

Despite these modifications, NOX-MT is far from perfect.

It does not address many of NOX’s performance deficiencies,

including but not limited to: heavy use of dynamic memory

allocation and redundant memory copies on a per-request basis,

and using locking while robust wait-free alternatives exist.

Addressing these issues would significantly improve NOX’s

performance. However, they require fundamental changes to

the NOX code base. NOX-MT was the first effort in enhancing

controller performance. The SDN controllers can be optimized

to be very fast.