CMSC 137 - Software Defined Networks (SDN)

[Short History of SDN] 2004

Research on new management paradigms

• RCP, 4D [Princeton, CMU,....]

• SANE, Ethane [Stanford/Berkeley]

[Short History of SDN] 2008

Software-Defined Networking (SDN)

• NOX Network Operating System [Nicira]

• OpenFlow switch interface [Stanford/Nicira]

[Short History of SDN] 2011

Open Networking Foundation (~69 members)

• Board: Google, Yahoo, Verizon, DT, Microsoft, Facebook, NTT

• Members: Cisco, Juniper, HP, Dell, Broadcom, IВМ,

[Short History of SDN] 2013

Latest Open Networking Summit

• 1600 attendees, Google: SDN used for their WAN Commercialized, in production use (few places)

Why Was SDN Needed?

• Networks are hard to manage

• Networks are hard to evolve

• Networks design not based on formal principles

[Why Was SDN Needed?] Networks are hard to manage

• Computation and storage have been virtualized

  • Creating a more flexible and manageable infrastructure

• Networks are still notoriously hard to manage

  • Network administrators large share of sysadmin staff

[Why Was SDN Needed?] Networks are hard to evolve

• Ongoing innovation in systems software

  • Routing algorithms change very slowly

  • Network management extremely primitive

• Networks are stuck in the past

  • New languages, operating systems, etc.

[Why Was SDN Needed?] Networks design are not based on formal principles

• OS courses teach fundamental principles

  • Mutual exclusion and other synchronization primitives

  • Files, file systems, threads, and other building blocks

• Networking courses teach a big bag of protocols

• Networks used to be simple

  • Basic Ethernet/IP straightforward, easy to manage

• New control requirements have led to complexity

  • ACLs, VLANs, TE, Middleboxes, DPI,...

• The infrastructure still works…

  • Only because of our great ability to master complexity

• Ability to master complexity both blessing and curse

How Programming Made the Transition

• Machine Languages: No Abstractions

  • had to deal with low-level details

• Higher-level Languages: OS and other Abstractions

  • file system, virtual memory, abstract data types

• Modern Languages: Even More Abstractions

  • object orientation, garbage collection

Abstraction

• simplify programming

• the way we extracted simplicity

The Two Networking “Planes”

• Data Plane

• Control Plane

Data Plane

processing and delivery of packets with local forwarding state

• forwarding state + packet header → forwarding decision

Control Plane

compute the state in routers (forwarding state)

• Determines how and where packets are forwarded

• Routing, traffic engineering, firewall state

• Implemented with distributed protocols, manual configuration (and scripting) or centralized computation

Data Plane Abstractions: Layers

• Applications

  ...built on...

• Reliable (or unreliable) transport

  ...built on...

• Best-effort global packet delivery

  ...built on...

• Best-effort local packet delivery

  ...built on...

• Local physical transfer of bits

[Many Control Plane Mechanisms] Variety of Goals

• Routing: distributed routing algorithms

• Isolation: ACLs, VLANs, Firewalls, etc.

• Traffic engineering: adjusting weights, MPLS, etc.

[Many Control Plane Mechanisms] modularity

no _____, limited functionality

[The Control Plane Problem] forwarding

Control plane must compute _____ state. To accomplish its task, the control plane must:

1. Figure out what network looks like (topology)

2. Figure out how to accomplish goal on given topology

3. Tell the switches what to do (configure forwarding state)

SDN: Two Control Plane Abstractions

• Global Network View

• Forwarding Model

Global Network View

• one of the two control plane abstractions

• provides information about current network

• implementation: "Network Operating System"

  • runs on servers in network (replicated for reliability)

Forwarding Model

• one of the two control plane abstractions

• provides standard way of defining forwarding state

• this is OpenFlow

  • specification of <match,action> flow entries

OSPF and Dijkstra

• example of using a Global Network View to compute optimal paths

• shows the idea of local routers using a global map

Load Balancing

• example of using the Forwarding Model to dynamically control how traffic flows

Specification Abstraction

• Control program must express desired behavior

  • Whether it be isolation, access control, or QoS

• It should not be responsible for implementing that behavior on physical network infrastructure

  • Requires configuring the forwarding tables in each switch

• Proposed abstraction: Virtual Topology of network

  • Virtual Topology models only enough detail to specify goals

  • Will depend on task semantics

Network Virtualization

introduce new abstraction and new SDN layer

[Network Virtualization] Virtual Topology

• Abstraction: _____

  • Allows operator to express requirements and policies

  • Via a set of logical switches and their configurations

[Network Virtualization] Network Hypervisor

• Layer: _____

  • Translates those requirements into switch configurations

  • "Compiler" for virtual topologies

Virtualization

_____ Simplifies Control Program

[Clean Separation of Concerns] Control Program

express goals on Virtual Topology

• Operator Requirements

• Configuration = Function(view)

• Not a distributed protocol, now just a graph algorithm

SDN: Layers for the Control Plane

Complexity

Abstractions Don’t Eliminate _____

[Abstractions Don’t Eliminate Complexity] tractable

every component of system is _____

• NOS, Virtualization are still complicated pieces of code

[Abstractions Don’t Eliminate Complexity] SDN Main Achievements

• simplifies interface for control program (user-specific)

• pushes complexity into reusable code (SDN platform)

Killer App

Virtualization is _____ for SDN.

• it allows multiple tenants in a data center to each have their own custom virtual network, while still sharing the same physical infrastructure

Four Crucial Points

• SDN is merely set of abstractions for control plane

  • Not a specific set of mechanisms

  • OpenFlow is least interesting aspect of SDN, technically

• SDN involves computing a function....

  • NOS handles distribution of state

• ...on an abstract network

  • Can ignore actual physical infrastructure

• Network virtualization is the "killer app"

  • Already virtualized compute, storage; network is next

SDN Larger Implications

• Control/Data Planes Become Separate

• Networking Becomes Edge-Oriented

[SDN Larger Implications] Control/Data Planes Become Separate

• Currently control plane tied to data plane

• NOS runs on servers: observes/controls data plane

• Changes the deployment and business models

  • Can buy the control plane separately from the switches

  • Enabling commodity hardware and 3rd party software

• Changes the testing model

  • Simulator to analyze large-scale control planes

[SDN Larger Implications] Networking Becomes Edge-Oriented

• Can implement most control functionality at edge

  • Access control, QoS, mobility, migration, monitoring...

• Network core merely delivers packets edge-to-edge

  • Current protocols do a good job (mostly)

• Let edge handle all complexity

  • Complicated matching, actions

  • "Overlay" networking via tunnels

• This has two important implications

  • Makes SDN Incrementally Deployable

  • Networking Becomes Software-Oriented

[Networking Becomes Edge-Oriented - Implication] Makes SDN Incrementally Deployable

• Host software often has OpenFlow switch

  • Open vSwitch (OVS) in Linux, Xen,...

• The edge becomes a software switch

  • Core of network can be legacy hardware

• Enables incremental deployment of SDN

  • Might never need OpenFlow in hardware switches....

[Networking Becomes Edge-Oriented - Implication] Networking Becomes Software-Oriented

• All complicated forwarding done in software (edge)

• And control plane is a program (on a server)...

  • ...not a protocol (on a closed proprietary switch/router)

• We are programming the network, not designing it

  • Focus on modularity and abstractions, not packet headers

• Innovation at software, not hardware, speeds

• Software lends itself to clean abstractions

SDN Vision

Networks Become “Normal”

[SDN Vision] Hardware

Cheap, interchangeable, Moore's Law

[SDN Vision] Software

Frequent releases, decoupled from HW

[SDN Vision] Functionality

Mostly driven by SW

• Edge (software switch)

• Control program

[SDN Vision] foundations

solid intellectual _____

OpenFlow

• a key protocol used in Software-Defined Networking (SDN) that allows the controller to talk to switches and routers

• It lets the controller send "match-action" rules to switches

[Primitives <Match,Action>] Match

• Match on any header, or new header

• Allows any flow granularity

[Primitives <Match,Action>] Action

• Forward to port(s), drop, send to controller

• Overwrite header with mask, push or pop

• Forward at specific bit-rate

[SDN “Implementations” - Software/Hardware] Forwarding Model

• OpenFlow

• ForCES

[SDN “Implementations” - Software/Hardware] Software Switches compliant with OpenFlow std.

• Open vSwitch

• Pantou/OpenWRT

• Ofsoftswitch13

• Indigo

[SDN “Implementations” - Software/Hardware] Controller compliant with OpenFlow std.

• POX

• NOX

• MUL

• Maestro

[SDN “Implementations” - Software/Hardware] Available Commodity Switches compliant with OpenFlow std.

• Hewlett-Packard 8200zl, 6600, 6200zl

• Brocade 5400zl, and 3500/3500yl

• IBM Netlron CES 2000 Series