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 Controller process(es) and (replicated) database of network view (NOX’s network observations) Programs = Algorithms + Data Structures Management applications use this state to make management decisions

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 system-wide 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 not-matched 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 (flow-initiation) 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