software-defined networks as databases

http://opennetsummit.org/workshops/?utm_source=ONS&utm_medium=speakerdeck&utm_campaign=ONS2015

http://opennetsummit.org/conference/?utm_source=ONS&utm_medium=speakerdeck&utm_campaign=ONS2015

http://opennetsummit.org/webinars/?utm_source=ONS&utm_medium=speakerdeck&utm_campaign=ONS2015

http://archives.opennetsummit.org?utm_source=ONS&utm_medium=speakerdeck&utm_campaign=ONS2015

http://opennetsummit.org/conference/?utm_source=ONS&utm_medium=speakerdeck&utm_campaign=ONS2015

http://twitter.com/opennetsummit

Software-defined Networks as Databases

Anduo Wang* Wenchao Zhou† Brighten Godfrey* Matthew Caesar*

*University of Illinois at Urbana-Champaign †Georgetown University

SDN not built with consistency in mind

2

writing app program is easy

OSdistributed state abstraction: view

PLconfiguration abstraction:

function(view)

features techniques, abstractions

control-plane

interfaces end user

data-plane serves

concurrent apps


2




function(view)


control-plane

interfaces end user

data-plane serves

concurrent apps

?forwarding abstraction:

any switch that speaks openflow


2




function(view)


control-plane

interfaces end user

data-plane serves

concurrent apps

no control over event ordering, timing of changes

how to instill customizable, flexible correctness criteria?

how to achieve continuous, reliable correctness guarantee?



this presents a challenge for SDN

3

this presents a challenge for SDNas networks become foundation of modern lives- used for critical infrastructure: military, financial, healthcare... - higher correctness concerns: regulatory requirements (HIPAA, Sarbanes Oxley),

security, privacy

3


security, privacy

as SDN deployments advance

3


security, privacy

as SDN deployments advancetension between control- /data-plane increases

3




function(view)






inspiration: databases

4


control-plane

interfaces single user

data-plane serves

concurrent apps




function(view)






inspiration: databases

4


control-plane


data-plane serves

concurrent apps

should (like DB)hide app program from data-plane

concurrency, updates

permit data-plane concurrency and optimization with correctness

guarantee

DBforwarding abstraction:

view as database

our approach: map database structure onto SDN

5


data item corresponds to network view (configuration)- data item = configuration = path attributes ≠ switching rules- the attributes associated with each flow’s forwarding path

- switches = distributed data-structure- the data-structure implements the data item

5




write corresponds to configuration update

5




write corresponds to configuration updateread corresponds to data traffic forwarding

5

our work: map database structure onto SDN

6

network view = configuration = path attributes data item

configuration update W(data item, value), OK()

traffic traversal R(data item), OK(value)

networking entity database structure

k(kids➙YouTube)

S1 S2 S3

parents

controller

kidsYouTube

operationsW(k, S1)OK()R(k)OK(S1)

p(parents➙Youtube)

y1 (Youtube➙parents)

y2 (Youtube➙kids)

flows: y1 y2 p k

dest ... p: ... k: ... y1: ... y2: ...

database


6





k(kids➙YouTube)

S1 S2 S3

parents

controller

kidsYouTube

k: fwd YouTube k: S1 k: S2




y2 (Youtube➙kids)

flows: y1 y2 p k

dest ... p: ... k: ... y1: ... y2: ...

database


6





k(kids➙YouTube)

S1 S2 S3

parents

controller

kidsYouTube

k: fwd YouTube k: S1 k: S2


ackackack



y2 (Youtube➙kids)

flows: y1 y2 p k

dest ... p: ... k: ... y1: ... y2: ...

database

k: S1


6





k(kids➙YouTube)

S1 S2 S3

parents

controller

kidsYouTube




y2 (Youtube➙kids)

flows: y1 y2 p k

dest ... p: ... k: ... y1: ... y2: ...

database

k: S1


6





k(kids➙YouTube)

S1 S2 S3

parents

controller

kidsYouTube


k(kids➙YouTube)p(parents➙Youtube)


y2 (Youtube➙kids)

flows: y1 y2 p k

dest ... p: ... k: ... y1: ... y2: ...

database

k: S1


6





k(kids➙YouTube)

S1 S2 S3

parents

controller

kidsYouTube


k(kids➙YouTube)p(parents➙Youtube)


y2 (Youtube➙kids)

flows: y1 y2 p k

dest ... p: ... k: ... y1: ... y2: ...

database

k: S1k: S1


6





k(kids➙YouTube)

S1 S2 S3

parents

controller

kidsYouTube




y2 (Youtube➙kids)

flows: y1 y2 p k

dest ... p: ... k: ... y1: ... y2: ...

database

k: S1k: S1


7

network view= per-flow configurations (policies) data item

control domainactual network view as switch flow tablesnetwork view maintained by controller

database siteregister

secure storage

network view updatetraffic forwarding

writeread

network view updates = updates for all affected flows in an app transaction

two configuration update overlapconfiguration update overlaps in-flight traffic

(ACID, CAP ...)write/write conflictread/write conflict

our contribution: design a database model, a basis for porting DB techniques towards a more tractable and powerful SDN


our work: port DB techniques identify correctness criteria by adapting well-studied DB properties - ACID (atomicity, consistency, isolation, durability)- build solid and reliable SDN by using ACID as reference properties

- CAP: only two of consistency, availability, and partition are achievable- understand the limitation, potential, and trade-off of SDN

achieve correctness with well-tested DB mechanism- scheduling SDN write/read by linearization- improving performance (concurrency) while retaining the correctness (sequential behavior)

8

ongoing work: prototyping scheduling

9

controlprogram

scheduler

ongoing work: prototyping scheduling

9

controlprogram

scheduler

scheduler

applicationproperties

(ACID,CAP)

SDNdatabasemodel

linearizationalgorithm

readwrite

control app

dependency




function(view)






recap: SDN as databases

10


control-plane


data-plane serves

concurrent apps

should (like DB)hide app program from data-plane

concurrency, updates

permit data-plane concurrency and optimization with correctness

guarantee

DBforwarding abstraction:

view as database

grand challenge and great potential

11

grand challenge and great potentialSDN database design space is unusual - data item = path attributes, implemented by distributed data-structure = switches- very large scale, communication gap between register & storage

11

grand challenge and great potentialSDN database design space is unusual - data item = path attributes, implemented by distributed data-structure = switches- very large scale, communication gap between register & storage

future work-write control apps with DB query language, which offers- data-dependency hiding: hide apps from data-plane- query suggestion/completion: provide hints and automation

- ensure data-plane correctness with general DB mechanism- synchronizing R/W, W/W by scheduling / locking

11

backup

12

dest ... p: S1 k: S1

y1: S3 y2: S3

map data to configuration

13

S1 S2 S3

parents

C

kidsYouTube

per flow policy,implemented by a distributed set of switches

data item attributes, describe the collective effects of switch

actions

database

p(parents➙Youtube) k(kids➙Youtube)


y2 (Youtube➙kids)

switching rules that implement data item k (policy for k)k: fwd YouTube k: S2 k: S1

flows: y1 y2 p k

data-plane and distributed databases

14

destp: S1 k: S1y1: S3y2: S3

DM

S1 S2 S3

parents

C

kidsYouTube



y2 (Youtube➙kids)

flows: y1 y2 p k paths:

s1s2s3


14

S1 S2 S3

parents

C

kidsYouTube



y2 (Youtube➙kids)


14

S1 S2 S3

parents

C

kidsYouTube

S5

S4

k1,2: S5*: drop



y2 (Youtube➙kids)

flows: y1,2 p k1,2

paths:s1s2s5s3s1s2s4s3

k1(kids➙firewall)

k2(kids➙Youtube)


14

destk1: S5

k2: drop y1: drop

DM B

B =S1S2S5S3

S1 S2 S3

parents

C

kidsYouTube

S5

S4

k1,2: S5*: drop



y2 (Youtube➙kids)

flows: y1,2 p k1,2


k1(kids➙firewall)

k2(kids➙Youtube)


14

destk1: S5

k2: drop y1: drop

DM B

B =S1S2S5S3

S1 S2 S3

parents

C

kidsYouTube

S5

S4

k1,2: S5

*: S2

*: drop

p: S4


y2 (Youtube➙kids)

flows: y1,2 p k1,2



k1(kids➙firewall)

k2(kids➙Youtube)


14

destp: S4 y1: S3

DM A

A=S1...S2S4S3

destk1: S5

k2: drop y1: drop

DM B

B =S1S2S5S3

S1 S2 S3

parents

C

kidsYouTube

S5

S4

k1,2: S5

*: S2

*: drop

p: S4


y2 (Youtube➙kids)

flows: y1,2 p k1,2



k1(kids➙firewall)

k2(kids➙Youtube)


14

destp: S4 y1: S3

DM A

A=S1...S2S4S3

DM B

B =S1S2S5S3

S1 S2 S3

parents

C

kidsYouTube

S5

S4

k1,2: S5

*: S2

p: S4 destk1: S5

k2: S1 y1: S3

k2: S1

y1,2: S3


y2 (Youtube➙kids)

flows: y1,2 p k1,2



k1(kids➙firewall)

k2(kids➙Youtube)

networking activities transactions operations

controller sets up paths for kids and parents T1WB(k1, S5), ok()WA(p, S4), ok()

kids send firewall set-up request to S5 T2 RB(k1), ok(S5) firewall accepts kids’ request and controller sets up paths between kids and YouTube T3

WB(k2, S1), ok()WB(y, S3), ok()

kids send request to YouTube T4 RB(k2), ok(S1) YouTube respond with video streaming T5 RB(y), ok(S3)


14

destp: S4 y1: S3

DM A

A=S1...S2S4S3

DM B

B =S1S2S5S3

S1 S2 S3

parents

C

kidsYouTube

S5

S4

k1,2: S5

*: S2

p: S4 destk1: S5

k2: S1 y1: S3

k2: S1

y1,2: S3


y2 (Youtube➙kids)

flows: y1,2 p k1,2



k1(kids➙firewall)

k2(kids➙Youtube)

15

destp: S4 y: S3

DM A

A=S1...S2S4S3

DM B

B =S1...S2S5S3

S1 S2 S3

parents

C

kidsYouTube

p flowy flow

S5

S4

k1 flow (to S5)k2 flow (to YouTube)

destk1: S5

k2: S1 y: S3

ACID atomicity,consistency, isolation,durability

durable transaction- a transaction commits after those it depends on commit- T3 depends on T1- T1: WB(k1, S5), ok(),WA(p, S4), ok(),T3:WB(k2, S1), ok(),WB(y, S3), ok()

- durability enables- recovery data-plane failures from controller’s view

15

destp: S4 y: S3

DM A

A=S1...S2S4S3

DM B

B =S1...S2S5S3

S1 S2 S3

parents

C

kidsYouTube

p flowy flow

S5

S4

k1 flow (to S5)k2 flow (to YouTube)

destk1: S5

k2: S1 y: S3


16

destp: S4 y: S3

DM A

A=S1...S2S4S3

DM B

B =S1...S2S5S3

S1 S2 S3

parents

C

kidsYouTube

S5

S4

destk1: S5

k2: S1 y: S3


networking activities transactions operations

controller sets up paths for kids and parents T1WB(k1, S5), ok()WA(p, S4), ok()

kids send firewall set-up request to S5 T2 RB(k1), ok(S5) firewall accepts kids’ request and controller sets up paths between kids and YouTube T3

WB(k2, S1), ok()WB(y, S3), ok()

kids send request to YouTube T4 RB(k2), ok(S1) YouTube respond with video streaming T5 RB(y), ok(S3)

flows: y1,2 p k1,2



k1(kids➙firewall)

k2(kids➙Youtube)


y2 (Youtube➙kids)

16

destp: S4 y: S3

DM A

A=S1...S2S4S3

DM B

B =S1...S2S5S3

S1 S2 S3

parents

C

kidsYouTube

S5

S4

destk1: S5

k2: S1 y: S3

ACID atomicity,consistency, isolation,durabilityflows: y1,2 p k1,2



k1(kids➙firewall)

k2(kids➙Youtube)


y2 (Youtube➙kids)

atomic transaction- all operations are (effectively) all or none- T3:WB(k2, S1), ok(),WB(y, S3), ok()

- atomicity ensures- YouTube could always respond whenever kids request a video

16

destp: S4 y: S3

DM A

A=S1...S2S4S3

DM B

B =S1...S2S5S3

S1 S2 S3

parents

C

kidsYouTube

S5

S4

destk1: S5

k2: S1 y: S3

ACID atomicity,consistency, isolation,durabilityflows: y1,2 p k1,2



k1(kids➙firewall)

k2(kids➙Youtube)


y2 (Youtube➙kids)

software-defined networks as databases

Technology

control data

dataplane concurrency

writing app program

reliable correctness

higher correctness concerns

correctness guarantee

exible correctness criteria

concurrent apps