Software-defined Networks as Databases

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

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

?forwarding abstraction:

any switch that speaks openflow

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

no control over event ordering, timing of changes

how to instill customizable, flexible correctness criteria?

how to achieve continuous, reliable correctness guarantee?

?forwarding abstraction:

any switch that speaks openflow

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

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

as SDN deployments advance

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

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

3

writing app program is easy

OSdistributed state abstraction: view

PLconfiguration abstraction:

function(view)

no control over event ordering, timing of changes

how to instill customizable, flexible correctness criteria?

how to achieve continuous, reliable correctness guarantee?

?forwarding abstraction:

any switch that speaks openflow

inspiration: databases

4

features techniques, abstractions

control-plane

interfaces single user

data-plane serves

concurrent apps

writing app program is easy

OSdistributed state abstraction: view

PLconfiguration abstraction:

function(view)

no control over event ordering, timing of changes

how to instill customizable, flexible correctness criteria?

how to achieve continuous, reliable correctness guarantee?

?forwarding abstraction:

any switch that speaks openflow

inspiration: databases

4

features techniques, abstractions

control-plane

interfaces single user

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

writing app program is easy

OSdistributed state abstraction: view

PLconfiguration abstraction:

function(view)

no control over event ordering, timing of changes

how to instill customizable, flexible correctness criteria?

how to achieve continuous, reliable correctness guarantee?

?forwarding abstraction:

any switch that speaks openflow

inspiration: databases

4

features techniques, abstractions

control-plane

interfaces single user

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

our approach: map database structure onto SDN

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

our approach: map database structure onto SDN

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

write corresponds to configuration update

5

our approach: map database structure onto SDN

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

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

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

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

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

k: fwd YouTube k: S1 k: S2

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

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

k: fwd YouTube k: S1 k: S2

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

ackackack

p(parents➙Youtube)

y1 (Youtube➙parents)

y2 (Youtube➙kids)

flows: y1 y2 p k

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

database

k: S1

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

k: S1

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)

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

y1 (Youtube➙parents)

y2 (Youtube➙kids)

flows: y1 y2 p k

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

database

k: S1

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)

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

y1 (Youtube➙parents)

y2 (Youtube➙kids)

flows: y1 y2 p k

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

database

k: S1k: S1

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

k: S1k: S1

our work: map database structure onto SDN

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

networking entity database structure

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

writing app program is easy

OSdistributed state abstraction: view

PLconfiguration abstraction:

function(view)

no control over event ordering, timing of changes

how to instill customizable, flexible correctness criteria?

how to achieve continuous, reliable correctness guarantee?

?forwarding abstraction:

any switch that speaks openflow

recap: SDN as databases

10

features techniques, abstractions

control-plane

interfaces single user

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)

y1 (Youtube➙parents)

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

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

y1 (Youtube➙parents)

y2 (Youtube➙kids)

flows: y1 y2 p k paths:

s1s2s3

data-plane and distributed databases

14

S1 S2 S3

parents

C

kidsYouTube

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

y1 (Youtube➙parents)

y2 (Youtube➙kids)

data-plane and distributed databases

14

S1 S2 S3

parents

C

kidsYouTube

S5

S4

k1,2: S5*: drop

p(parents➙Youtube)

y1 (Youtube➙parents)

y2 (Youtube➙kids)

flows: y1,2 p k1,2

paths:s1s2s5s3s1s2s4s3

k1(kids➙firewall)

k2(kids➙Youtube)

data-plane and distributed databases

14

S1 S2 S3

parents

C

kidsYouTube

S5

S4

k1,2: S5*: drop

p(parents➙Youtube)

y1 (Youtube➙parents)

y2 (Youtube➙kids)

flows: y1,2 p k1,2

paths:s1s2s5s3s1s2s4s3

k1(kids➙firewall)

k2(kids➙Youtube)

data-plane and distributed databases

14

destk1: S5

k2: drop y1: drop

DM B

B =S1S2S5S3

S1 S2 S3

parents

C

kidsYouTube

S5

S4

k1,2: S5*: drop

p(parents➙Youtube)

y1 (Youtube➙parents)

y2 (Youtube➙kids)

flows: y1,2 p k1,2

paths:s1s2s5s3s1s2s4s3

k1(kids➙firewall)

k2(kids➙Youtube)

data-plane and distributed databases

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

y1 (Youtube➙parents)

y2 (Youtube➙kids)

flows: y1,2 p k1,2

paths:s1s2s5s3s1s2s4s3

p(parents➙Youtube)

k1(kids➙firewall)

k2(kids➙Youtube)

data-plane and distributed databases

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

y1 (Youtube➙parents)

y2 (Youtube➙kids)

flows: y1,2 p k1,2

paths:s1s2s5s3s1s2s4s3

p(parents➙Youtube)

k1(kids➙firewall)

k2(kids➙Youtube)

data-plane and distributed databases

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

y1 (Youtube➙parents)

y2 (Youtube➙kids)

flows: y1,2 p k1,2

paths:s1s2s5s3s1s2s4s3

p(parents➙Youtube)

k1(kids➙firewall)

k2(kids➙Youtube)

data-plane and distributed databases

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

y1 (Youtube➙parents)

y2 (Youtube➙kids)

flows: y1,2 p k1,2

paths:s1s2s5s3s1s2s4s3

p(parents➙Youtube)

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)

data-plane and distributed databases

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

y1 (Youtube➙parents)

y2 (Youtube➙kids)

flows: y1,2 p k1,2

paths:s1s2s5s3s1s2s4s3

p(parents➙Youtube)

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)

data-plane and distributed databases

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

y1 (Youtube➙parents)

y2 (Youtube➙kids)

flows: y1,2 p k1,2

paths:s1s2s5s3s1s2s4s3

p(parents➙Youtube)

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)

data-plane and distributed databases

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

y1 (Youtube➙parents)

y2 (Youtube➙kids)

flows: y1,2 p k1,2

paths:s1s2s5s3s1s2s4s3

p(parents➙Youtube)

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

ACID atomicity,consistency, isolation,durability

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,durability

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

paths:s1s2s5s3s1s2s4s3

p(parents➙Youtube)

k1(kids➙firewall)

k2(kids➙Youtube)

y1 (Youtube➙parents)

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

paths:s1s2s5s3s1s2s4s3

p(parents➙Youtube)

k1(kids➙firewall)

k2(kids➙Youtube)

y1 (Youtube➙parents)

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

paths:s1s2s5s3s1s2s4s3

p(parents➙Youtube)

k1(kids➙firewall)

k2(kids➙Youtube)

y1 (Youtube➙parents)

y2 (Youtube➙kids)