SDN: Week 6: Future: Module 8.1: A broader vision of SDN

[gdt]

SDN paradigm is switches performing (match, action), both match and action are limited
- no payload examination
- no advanced actions

Expanding this requires a practical approach
- extending OpenFlow
- implementing a richer data plane in the controller: flexible, but performance
- send traffic through custom devices: middleboxes, custom hardware

Middlebox orchestration -- "Slick"
- installs code on middleboxes
- if the middleboxes raise events then Slick handles them
- installs OpenFlow rules on switches to divert desired traffic through the middleboxes

Slick elements
- arbitrary code. Functions implement Slick API. Raises trigger at controller.
- self-describing manifest: hardware requirements (so only placed on a middlebox which can run the element), triggers, network requirements (eg, seeing both directions of traffic, or all traffic to a host, etc)

Slick application
- implements network policies: which elements to run on which traffic, how to react to changes in network conditions
- controller abstracts policy away from the application (where to place elements, how traffic should be routed)

Slick controller
- manages and configures a network of middleboxes. Resource discovery. Deploys elements. Ensures element availability in the face of failure.
- implements policies for the application. Where to place elements. How to steer traffic to elements.

Eg: Dynamic redirection
- inspect all DNS traffic with a DPI device
- if suspicious lookup, send to traffic scubber

Custom data plane orchestration
- put Custom Packet Processors in network
- use a device abstraction layer to allow programming of the Processors (individually, and as a fabric)

Applications
- big data
- encryption, transcoding, classification
- selective DPI

Summary:
- SDN is broader than OpenFlow and (match, action)
- SDN is about separating data plane and control place
- That allows orchestration