SDN: Week 1: History of SDN

[gdt]

Why separate control plane?

• rapid innovation, not tied to hardware vendor


• network-wide view


• flexibility to introduce new services

Control plane: FORCES

• Control Elements set forwarding table for Forwarding Elements using the FORCES interface


• Minus: Requires standardisation, deployment, etc. But these are the exact problems.

Control plane: Routing Control Platform

• Hijack BGP as the device to modify the forwarding plane


• Each AS runs a RCP and communicates routes to forwarding plane using BGP.


• Plus: Easy transition, doesn't require a new set of protocols


• Minus: constrained by what an existing protocol can do

Custom hardware: Ethane

• "Domain controller" computes forwarding tables for each switch


• Needed custom switches. Ethane implemented these for OpenWRT, NetFPGA, Linux.


• Minus: Requires custom switches which support Ethane protocol

What we want:

• Existing protocols


• Not custom hardware

Answer: OpenFlow

• Take capabilities of existing hardware


• Open those so a standard control protocol can set their behaviour


• "Controller" communicates with switches to set forwarding table entries.


• Most switches already implement flow tables, so only thing which is necessary for deployment is to persuade vendors to provide interface to the flow tables.

What have we learned:

• Control and data planes should be decoupled, as coupling makes it too difficult to introduce new protocols.


• Control plane protocols which require alterations to the hardware can't get traction.


• Existing protocols can't express the full range of behaviour desired by network operators.


• Open hardware allows decoupling of control.