![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
gdtSDN 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
- 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