Download networking

Abstractions for SDN
Martin Casado, Nate Foster, and
Arjun Guha
CACM, October 2014
Introduction
• SDN was invented to addressing some long-standing
challenges in networking
• SDN starts from two ideas
– generalize network hardware to provide a standard
collection of packet-processing functions instead of a fixed
set of narrow features
– decouple software that controls network from devices that
implement it
• The design of SDN
– makes it possible to evolve network without having to change
underlying hardware
– enables expressing network algorithms in terms of
appropriate abstractions for particular applications
Introduction
• One or more controller machines execute general-purpose
programs that respond to events (changes in network topology,
connections initiated by end hosts, shifts in traffic load, or
messages from other controllers) by computing a collection of
packet-forwarding rules
• Controllers then push these rules to switches, which implement
required functionality efficiently using specialized hardware
New Applications
•
•
•
•
•
Shortest-path routing
Policy-based access control
Adaptive traffic monitoring
Traffic engineering
Network virtualization
without new (distributed) protocols on proprietary
hardware
Need new abstractions to facilitate new applications
(like OS providing rich abstractions for managing
resources, need new abstractions for network
applications)
Network-Wide Structures
• SDN controllers can compute network-wide
structures that give global visibility into network
state → simplify networking applications
– Network Information Base (NIB) in controller
– evaluating Dijkstra's shortest-path algorithm over the
structure representing the topology
– spanning tree: difficult with distributed algorithms vs. Prim’s
algorithm
Distributed Updates
• Configuration updates to be eventually consistent
– if network configuration is recalculated due to link failure, a packet may
traverse a switch once in original state and a second time in updated state
→ forwarding loops or dropping packets
• eventually consistent updates do not always suffice in
SDN
– an SDN controller might manage both filtering rules and forwarding rules,
and these rules may be critical for ensuring invariants such as access
control or isolation between traffic of tenants sharing network → invariants
can be violated during periods of transition
Modular Composition
• In OS, processes allow multiple users to share
hardware resources; processes interact via wellspecified interfaces
• SDN controller as network OS, but lacks abstraction
analogous to process
• Network programming needs modularization
• SDN building blocks = {forwarding, broadcast,
monitoring, access control, …}
Virtualization (1)
• Decouples software that controls network from the
underlying forwarding hardware
• Does not decouple forwarding logic from underlying
physical network topology
• SDN controllers now provide primitives for writing
applications in terms of virtual network elements
• Decoupling programs from topology also creates
opportunities for making SDN applications more
scalable and fault tolerant
Virtualization (2)
• Access control
– encoding MAC or IP addresses into configuration
– topology changes (due to mobility) undermines security
– when access control lists are configured in terms of a virtual
switch connected to each host, then policy remains stable
even if topology changes
• Multi-tenant datacenter
– allow multiple tenants to impose different policies on devices
in a shared physical network
– overlapping addresses and services lead to complicated
forwarding tables → hard to guarantee that traffic
generated by one tenant will be isolated from other tenants
– using virtual switches, each tenant can be provided with a
virtual network they can configure however they like without
interfering with other tenants
Virtualization (3)
• Scale-out router
– in large networks, it can be necessary to make a collection of
physical switches behave like a single logical switch
– for example, a large set of low-cost commodity switches
could be assembled into a single carrier-grade router.
– besides simplifying forwarding logic for individual
applications, this approach can also be used to obtain
scalability—because such a router only exists at the logical
level, it can be dynamically augmented with additional
physical switches as needed
Virtualization makes applications more portable and scalable by
decoupling forwarding logic from specific physical topologies
Virtualization (4)
• Virtualization abstraction
– e.g., VMware’s NSX, Frenetic languages,
• Virtualization mechanism
– hypervisor
Formal Verification (1)
• Manual low-level network configuration → unreliable
and/or insecure networks
• SDN standardizes interface to network hardware →
tools to build and operate reliable networks
• Network invariants: properties can be checked
automatically using tools that formally model the
state of network and controller
• What properties?
• Many properties are topology-specific
– they can be stated and verified given a model of the
structure of network
Formal Verification (2)
–
Topology-specific properties
•
•
•
•
–
Connectivity: eventually packets are delivered except due to
congestion or failures
Loop freedom: no loop in network
Waypointing: packets emitted by untrustworthy hosts
traverse middlebox that scans for malicious traffic before
being forwarded to intended destinations
Bandwidth: provide minimum bandwidth specified in SLA
Topology-agnostic properties or properties for large
classes of topologies [correctness criteria]
•
•
•
Access control
Host learning
Spanning tree
Formal Verification (3)
• Both types of properties are difficult to establish in
traditional networks, as they require reasoning about
complex state distributed across many heterogeneous
devices
• Uniform interfaces provided by SDN simply
verification
• To verify configurations
– model both topology and switch configurations
– e.g., Header Space Analysis, FlowChecker, Antester,
VeriFlow, NetKAT
• To verify controllers (control programs)
– e.g., NICE, NetCore, VeriCon, Flowlog
Formal Verification (4)
• Need for tools that can provide rigorous guarantees
about behavior, performance, reliability, and security
of networked systems
• By standardizing interfaces for controlling networks,
SDN makes it feasible to build tools for verifying
configurations and controllers against precise formal
models
• Future directions
– developing custom logics and decision procedures for
expressing and checking properties
– enriching models with additional features such as latency and
bandwidth
– better integrating property checking and debugging tools
into SDN controller platforms