SDN Architecture Based on “OpenFlow: Enabling Innovation in Campus Networks” Michael Rausch and Benjamin Ujcich CS 538 – October 16, 2014

“OpenFlow: Enabling Innovation in Campus Networks” • Published in 2008 •  “A way for researchers to run

experimental protocols in the networks they use every day” • University campus audience in

mind • First implemented at Stanford

University

Motivation

•  Introducing innovations into networks is difficult • Network administrators don’t want to •  risk running experiments on their network •  adopt untested protocols

• Researchers cannot test new protocols in realistic environments at scale and with real traffic

One Solution: Virtualized Programmable Networks • Pros: • Programmable switches and routers that

can process traffic for multiple experiments • GENI as an example • Lower the barrier to entry for new ideas

• Cons: • Most plans for nationwide at-scale

implementation are ambitious and costly

One Solution: Open and Programmable Hardware • Pros • Persuade hardware vendors to open up

their hardware to an open, programmable platform

• Cons • Unlikely in the short term • Costly for vendors to build and develop

their hardware platforms • Lowers the barrier-to-entry for new

competitors

A Platform Compromise

• The authors’ approach was to compromise by wanting a switch that possesses: • High performance and low cost

implementation • Support for broad and diverse research •  Isolation mechanisms to clearly separate

experimental traffic from production traffic • Consistent with vendors’ need for closed

platforms

How to Implement the Platform

• Convince vendors to provide the platform? • Use existing platforms? • PC-based solutions: low performance • Supercharged PlanetLab Platform: high

cost • NetFPGA: only four network interfaces

• Create new platform?

Solution: OpenFlow

• Key idea: Exploit the fact that many Ethernet switches and routers have flow tables with ternary content-addressable memory (TCAM), which can ordinarily be used to help with the implementation of firewalls, NAT, and QoS • Create a common open protocol (OpenFlow)

that allows for programming the flow tables within networking devices

OpenFlow Components

1.  Flow table 2.  Controller 3.  Secure channel

Source: http://web.engr.illinois.edu/~pbg/courses/cs598fa10/readings/mabpprst08.pdf

Flow Entries

• Each datapath has a flow entry and an associated action •  10 header fields matched in an OpenFlow

(v1.0) switch: •  Ingress port • VLAN ID • Ethernet: source, destination, type •  IP: source, destination, protocol • TCP: source, destination

Actions

• Actions that can be performed on traffic matching a flow entry: 1.  Forward traffic to a given port or ports

(at line rate) 2.  Encapsulate and forward traffic to the

controller for inspection (either first packet in a flow of traffic or all packets)

3.  Drop traffic 4.  Forward traffic through switch’s normal

processing pipeline

Flow Entries and Actions

Source: http://arxiv.org/pdf/1406.0440v3.pdf

Dedicated OpenFlow Switches vs. OpenFlow-enabled Switches • Dedicated OpenFlow Switches • Dumb datapath element that forwards

packets between ports • OpenFlow-enabled Switches • Re-use existing hardware and software •  TCAMs in hardware •  Secure channel and OpenFlow protocol in

software

• Perform OpenFlow experiments while not interfering with normal production traffic

Controllers

• Static controller: • Statically establish flow entries in switches

for the duration of an experiment • Generalized VLAN

• More sophisticated controllers: • Allow for simultaneous experiments from

different experimenters • Dynamically add or remove flows as an

experiment progresses

Controllers and Flow Entries

• Proactive flow entry instantiation: • Flow entries are pre-determined • Useful when traffic type is known before • No disruption if controller goes down

• Reactive flow entry instantiation: • Flow entries are determined by sending

traffic to controller to decide what to do • Additional latency due to first packet in

the flow being processed • More limited if controller goes down

Popular Controllers (2014)

Source: http://hal.archives-ouvertes.fr/docs/00/93/29/82/PDF/hal_final.pdf

Use Cases

• The authors mentioned several use cases: • Network Management and Control • VLANs • Mobile wireless VOIP clients • A non-IP network • Processing packets instead of flows

• Any others?

Thoughts: A Generalized SDN Architecture • OpenFlow is a particular approach (by far the

most popular) but it is not the same thing as SDN •  In “Software-Defined Networking: A

Comprehensive Survey,”1 four criteria are given for SDN: • Control and data planes are decoupled •  Forwarding decisions are flow-based, not

destination based • Control logic is handled by controller • Network is programmable

1 Source: http://arxiv.org/abs/1406.0440

A Generalized SDN Architecture

Source: http://arxiv.org/pdf/1406.0440v3.pdf

A Generalized SDN Architecture

Source: http://arxiv.org/pdf/1406.0440v3.pdf

A Generalized SDN Architecture

Source: http://arxiv.org/pdf/1406.0440v3.pdf

A Generalized SDN Architecture vs. Conventional Network

Source: http://arxiv.org/pdf/1406.0440v3.pdf

Thoughts: The “Pragmatic Compromise” • Perhaps one of the reasons why OpenFlow

development succeeded after this paper was written • Hardware vendors could more easily

implement OF by adding support for the protocol without exposing the internal workings of their devices • Network administrators could more easily

test out OF in their networks while still having the confidence that experimental and production traffic would remain isolated

Thoughts: Use in Campuses

• The authors of the paper had a very narrow focus on providing research opportunities by implementing OpenFlow on campus networks • SDN and OpenFlow, however, are very

flexible and powerful and are now being used in enterprise systems

Thoughts: “Fabric: A Retrospective on Evolving SDN” • Decouple the edge of a network from its core

internal fabric • Separate forwarding decisions so that the

edge and fabric can evolve independently • Separate control decisions so that the edge is

responsible for network policy (security, isolation, mobility, etc.) and the fabric is responsible for packet transport • Extends SDN concepts while leveraging

SDN’s control plane flexibility

Thoughts: “Fabric: A Retrospective on Evolving SDN”

Source: http://conferences.sigcomm.org/sigcomm/2012/paper/hotsdn/p85.pdf

Discussion

• Where would an SDN architecture not be appropriate? Why? • What are the security implications for an

SDN architecture? How do they differ from the requirements of a conventional network architecture? • How should multiple controllers be

supported? Does the centralized concept in SDN change because of this?