Download network view

NOX: Towards an
Operating System
for Networks
Natasha Gude, et al.
ACM SIGCOMM CCR, July 2008
Motivation
• Issue: enterprise networks are difficult to manage
– through low-level configuration of individual components
• Need a different network management paradigm
• Draw inspiration from OS
• OS provides abstractions for physical resources
(memory, storage, etc.) and information (file and
directory)
– abstractions enable programs to carry out complicated tasks
safely and efficiently on a variety of computing hardware
• Enterprise network resembles a computer without
OS, with network-dependent configuration playing
role of hardware-dependent machine-language
programming
OS for Networks (NOS)
• Provides a uniform and centralized programmatic
interface to entire network so as to observe and
control network – general enough for many
management applications
• Two key concepts
– presents programs with centralized programming model →
require centralized network state
– programs are written in terms of high-level abstractions
(e.g., user and host names), not low-level configuration
parameters (e.g., IP and MAC addresses)
• This allows management directives to be enforced
independent of underlying network topology, but it
requires NOS maintain bindings (i.e., mappings)
between abstractions and low-level configurations
Network Operating System
• Network operating system allows management
applications to be written as centralized programs
over high-level names as opposed to distributed
algorithms over low-level addresses
• Challenges of transforming from distributed
algorithms to centralized programming: scalability
NOX Overview
•
•
•
•
•
Constituent components
Observation and control granularity
Switch abstraction
Basic operation
Scaling
Components
observat ion, NOX ’s n
t opology; t he locat io
NOX Controller
ot her net work elemen
Network
NFS) being offered. T
View
PC Server
names and addresses,
OF switch
of net work t raffic. T
wireless OF
provides adequat e inf
switch
ment t asks and change
OF switch
maint ained in large n
T he quest ion of con
cent ralized per-packet
feasible t o implement
ot her ext reme, operat
rout ing t ables would
packet s bet ween two
pat h. For
Controller
process(es)
(replicated)
ofNOX we ch
F i gu r e 1: C
om p on ent s of and
a N OX
-b ased n et w or database
k:
(similar in spirit t o [13
O p en F lowview
( O F ) (NOX’s
sw i t ch es, a
ser ver r u nobservations)
n i n g a N OX
network
network
some packet , subsequ
cont r ol l er pr ocess an d a d at abase cont ai n i n g t h e net t reat ed in t he same wa
– wPrograms
or k v i ew . = Algorithms + Data Structures
were able t o build a sy
Management applications use this state to make
while st ill providing fl
We argue for an affirmat ive answer t o t his quest ion via proofmanagement
decisions
Sw i t ch A b st r act i on
by-example; herein we describe a network operat ing syst em
app1
•
•
app2
app3
Granularity
• Observation and control granularity
• Trade off between scalability and flexibility
• NOX’s network view includes switch-level topology;
locations of users, hosts, middleboxes, and other
network elements; and services (e.g., HTTP or NFS)
• Control granularity: flow (once control is exerted on
some packet, subsequent packets with same header
are treated in same way) [scalable and flexible]
Switch Abstraction
• Management applications control network traffic by
sending instructions to switches
• Switch instructions should be independent of switch
hardware, and should support flow-level control
granularity
• Use OpenFlow switch abstraction
– switches are represented by flow tables of entries
• ⟨header : counters, actions⟩
– for each packet matching specified header, counters are
updated and appropriate actions taken
NOX vs. OpenFlow
• NOX provides network-wide abstractions,
much like operating systems provide systemwide abstractions
• OpenFlow provides an abstraction for a
particular network component, and is thus
more analogous to a device driver
Operation
• NOX applications use flow-initiations (first notmatched packet) and other forwarded traffic to
– construct network view (observation)
• use DNS, DHCP, LLDP, and flow-initiations to construct network
view (including network topology and set of name-address
bindings)
• intercept authentication traffic to perform user and host
authentications (using 802.1x, port-based network access
control)
– determine whether to forward traffic, and, if so, along which
route (control)
• access-control and routing applications determine if a flow
should be allowed, compute an appropriate L2 route, install flow
entries in all switches along the path, and then return (flowinitiation) packet to originating switch (which then forwards it
along designated path)
Scaling (1)
• In terms of timescales, NOX processing occurs at
three very different rates
– packet arrival rate: e.g., on order of millions of arrivals per
second for a 10Gbps link
– flow-initiation rate: typically one or more orders of
magnitude less than packet arrival rate
– changes in network view: on order of tens of events per
second for networks of thousands of hosts
• In terms of consistency, network view is the only
network state that is global (i.e., must be used
consistently across controller processes)
– since neither packet state nor flow state are part of network
view, they can be kept in local storage (i.e., packet state in
switches, and flow state in controller instances)
Scaling (2)
• In terms of
NOX Programmatic Interface
NOX Management Applications