CS 5376- Advanced Communication

Networks
Software Defined Networking-2
Spring 2016
Mahshid R. Naeini, PhD

NOX: Towards an Operating System for Networks

Network operating system provides the ability to observe and control a
network.
Does not manage the network itself, but provides a programmatic
interface.
Applications implemented on top of the network operating system
perform the actual management tasks.

One of the key services of an operating system is that it

provides abstraction for common system functionality.
Providing meaningful and easy to use Wrapper functions that in turn
encapsulate the system functions offered by the OS
Easier and faster code development for the system

GUDE, N., KOPONEN, T., PETTIT, J., PFAFF, B., CASADO, M., MCKEOWN, N., AND SHENKER, S. NOX: Towards an Operating System for
Networks. In SIGCOMM CCR (July 2008).

Abstraction in SDN
An SDN can be defined by three fundamental abstractions: forwarding,
distribution, and specification
Forwarding abstraction should allow any forwarding behavior desired by the
network application (the control program) while hiding details of the
underlying hardware.
Distribution abstraction should shield SDN applications from the vagaries of
distributed state, making the distributed control problem a logically centralized
one.
Collect status information about the forwarding layer (network devices and links),
to offer a global network view to network applications.

Specification abstraction should allow a network application to express the

desired network behavior without being responsible for implementing that
behavior itself.
This can be achieved through virtualization solutions, as well as network
programming languages.
3

NOX Components
Primary components
A set of switches:
support OpenFlow
abstraction
One or more networkattached servers:
run NOX softwares;
can be thought of as
involving several
different controller
processes and a single
network view.

NOX Granularity
When designing a network operating system, we need to decide abut
granularity at observation and control level.
Choosing the granularity involves trading off between scalability vs.
flexibility.
At observation level:
NOXs network view:
The switch-level topology; the locations of users, hosts, middle-boxes, and other network
elements; and the services (e.g., HTTP or NFS) being offered.
All bindings between names and addresses.
Does not include the current state of network traffic.

Granularity
At control level:
A centralized per-packet control: infeasible to implement across any
sizable network. No scalability.
Prefix-based routing table: not allow sufficient control, since all packets
between two hosts would have to follow the same path. No flexibility.
An intermediate flow-based granularity
Once control is exerted on some packet, subsequent packets with the same header
are treated in the same way.

NOX Switch Abstraction

Independent of the particular switch hardware.
Support the flow-level control granularity.
Switches are represented by flow tables with entries like:
<header : counters; actions>
For each packet matching the specified header, the counters are
updated and the appropriate actions taken. If a packet matches
multiple flow entries, the entry with the highest priority is chosen.
Basic set of OpenFlow actions:
Forward as default (i.e., forward as if NOX were not present)
Forward out specified interface
Deny
Forward to a controller process
Modify various packet header fields (e.g., VLAN tags, source
and destination IP address and port).

Operation
NOX applications use flow-initiations and other forwarded
traffic to
Observe: Construct the network view.
Use DNS, DHCP, and flow-initiations to construct the network view,
including both the network topology and the set of name-address
bindings.
Control: Determine whether to forward traffic, and, if so, which route.
Develop access-control and routing applications that determine if a
flow should be allowed, compute an appropriate L2 route, install flow
entries in all the switches along the path, and then return the packet to
the originating switch

NOX Scaling
Events in NOX
Packet arrivals: millions per sec.
Flow initiations: one or more orders of magnitude less than the packet
arrival rate.
Changes in the network view: tens of events per second for networks of
thousands of hosts.
Consistency:
The only network state that is global consistent is the network view, can
be handled by the centralized controller.
Neither packet state nor flow state are part of the network view, can be
kept in local storage.

Use parallelism to handle events that occur on rapid timescales

A single controller process running on a generic PC can currently

handle 100,000 flow initiations per second, more than sufficient for the
large campus networks weve measured in previous work

Programmatic Interface
Events
Use a set of handlers that are registered to execute when a particular
event happens.
A handlers return value indicate to NOX wether to stop execution of
the vent or to continue by passing the event to the next registered
handler.
Some events are generated directly by OpenFlow messages.
Other events are generated by NOX applications as a result of
processing these low-level events and/or other application-generated
events.
For example, NOX includes applications that will authenticate a user by redirecting
raw HTTP traffic (a packet received event) to a captive web portal. Once the user is
authenticated, the NOX application generates a user authenticated event which can
be used by other applications.

Programmatic Interface
Network View and Namespace
NOX includes a number of base applications that construct the network view
and maintain a high-level namespace that can be used by other applications.
These applications handle user and host authentications and create name
bindings.
Allow applications to be written in a topology independent manner.
High-level declarations can be compiled against the network view to produce
low-level lookup functions that are enforced per-packet.
The worst result of a poorly written application is performance degradation, not
incorrect function (due to cost of change and access the global view).

Programmatic Interface
Control
Management applications exert network control through OpenFlow
OpenFlow will not include custom per-packet processing (e.g., deep packet
inspection).
NOX applications can direct traffic through specialized middle-boxes

Higher-Level Services
A set of system libraries to provide efficient implementations of functions
common to many network applications
Routing
Packet Classification
And standard network services,

Example 1: User-based VLAN Tagging

VLAN

Example 1: User-based VLAN Tagging

NOTE: Each OpenFlow instance on a switch is identified by a Datapath Identifier. This

is a 64 bit number determined as follows according to the OpenFlow specification:
The datapath_id fleld uniquely identifies a datapath. The lower 48 bits are intended
for the switch MAC address, while the top 16 bits are up to the implementer

Example 2: Simplistic Scan Detection

Count the number of unique L2 and L3 destinations a host tries to contact that have
not authenticated.
Detect scanning hosts by tracking the number of unique, unknown L2 and L3
destinations attempted by a single host.
scans = defaultdict(dict)
def check_for_scans(dp, inport, packet):
dstid = nox.resolve_host_dest(packet)
if dstid == None:
scans[packet.l2.srcaddr][packet.l2.dstaddr] = 1
if packet.l3 != None:
scans[packet.l2.srcaddr][packet.l3.dstaddr] = 1
if len(scans[packet.l2.srcaddr].keys()) > THRESHOLD:
print nox.resolve_user_source_name(packet)
print nox.resolve_host_source_name(packet)
# To be called on all packet-in events
nox.register_for_packet_in(check_for_scans)

References

Natasha Gude et al., NOX: Towards an Operating System for Networks

Nick McKeown et al., OpenFlow: Enabling Innovation in Campus Networks
Teemu Koponen et al., Onix: A distributed control platform for large-scale production networks, OSDI,
Oct, 2010
D Levin et. al., Logically centralized?: state distribution trade-offs in software defined networks, HotSDN
2012
Brandon Heller et al., The controller placement problem
N Handigol et. al., Where is the debugger for my Software-Defined Network?, HotSDN 2012
L Suresh et. al., Towards programmable enterprise WLANS with Odin, HotSDN 2012
Some are adopted from Slides by Jennifer Rexford
Some are adopted from Slides by Rob Sherwood Saurav Das Yiannis Yiakoumis, AT&T tech talk, 2010.