81
SDN abstraction and security: a database perspective Anduo Wang * Jason Croft Xueyuan Mei Matthew Caesar Brighten Godfrey * Temple University University of Illinois Urbana-Champaign June 17, 2016 SoSSDN

SDN abstraction and security: a database perspectivepublish.illinois.edu/science-of-security...SoSSDN-Wang-June2016.pdfSDN abstraction and security: a database perspective Anduo Wang*

  • Upload
    lyhuong

  • View
    221

  • Download
    0

Embed Size (px)

Citation preview

SDN abstraction and security: a database perspective

Anduo Wang* Jason Croft† Xueyuan Mei† Matthew Caesar† Brighten Godfrey†

*Temple University †University of Illinois Urbana-Champaign

June 17, 2016 SoSSDN

software-defined networkcontrol applications of disparate nature

OpenFlow network

forwarding

controller

switch

servicechain

…statefulmiddlebox

switchswitch switch

1

software-defined networkcontrol applications of disparate nature

OpenFlow network

forwarding

controller

switch

servicechain

…statefulmiddlebox

switchswitch switch

an insertion point for network abstractions

controller(abstraction runtime)

1

abstractionswhat is the right abstraction?

OpenFlow rules

abstraction runtime

forwarding servicechain

statefulmiddlebox

abstraction runtime

2

abstractionswhat is the right abstraction?

OpenFlow rules

abstraction runtime

routing servicechain

statefulmiddlebox

functions

Frenetic / Pyretic

[NSDI’13] [PLDI’13]

2

abstractionswhat is the right abstraction?

OpenFlow rules

abstraction runtime

routing graphs statefulmiddlebox

functions

PGA

[SIGCOMM’15]

2

abstractionswhat is the right abstraction?

OpenFlow rules

abstraction runtime

routing graphs automatafunctions

Kinetic

[NSDI’15]

2

abstractionsdiverse abstractions

OpenFlow rules

abstraction runtime

graphs automatafunctions …

2

but network keeps evolvingnew/changing requirements

OpenFlow rules

abstraction runtime

graphs automatafunctions

3

but network keeps evolvingnew/changing requirement

OpenFlow rules

graphs automatafunctions newstructure

add / re-engineer runtime

3

and applications (components) interact

functions

graphs automata

PGA

Pyretic

Kinetic

OpenFlow rulesnetwork

policies

4

and applications (components) interact

functions

graphs automata

PGA

Pyretic

Kinetic

OpenFlow rulesnetwork

language-level orchestration restricted to each abstraction

policies

composing (+) policy→ graph +PGA graph→ function +Pyretic function

4

and applications (components) interact

functions

graphs automata

PGA

Pyretic

Kinetic

OpenFlow rulesnetwork

language-level orchestration restricted to each abstraction

policies

composing (+) policy→ graph +? automata

how to integrate the runtime?hard-wire internals?

4

and applications (components) interact

functions

graphs automata

PGA

Pyretic

Kinetic

OpenFlow rulesnetwork

language-level orchestration restricted to each abstraction

abstraction-agonistic coordination often low-levelCo-visor [NSDI’15] statesman [SIGCOMM’14]

policies

4

current state of abstraction research

structure

structure structure

runtime

runtime

runtime

OpenFlow rulesnetwork

4

current state of abstraction research

structure

structure structure

runtime

runtime

runtime

newstructure

newruntime

enlarging body of abstractions

OpenFlow rulesnetwork

4

current state of abstraction research

structure

structure structure

runtime

runtime

runtime

newstructure

newruntime

enlarging body of abstractions

OpenFlow rulesnetwork

fragmented orchestration

4

SDN control revolves around data representation-discard specialized, pre-compiled,

fixed structures-adopt a plain data representation

our perspective

data

data new data

data data

operator and/or application

OpenFlow rulesnetwork

low

-leve

l re

pres

enta

tion

high

-leve

l re

pres

enta

tion

5

SDN control revolves around data representation-discard specialized, pre-compiled,

fixed structures-adopt a plain data representation-use a universal data language

our perspective

data

data new data

data data

operator and/or application

OpenFlow rulesnetwork

low

-leve

l re

pres

enta

tion

high

-leve

l re

pres

enta

tion

5

-relation — the plain data representation- table — stored relation- view — virtual relation

a database-defined network

view

view new view

table table

operator and/or application

OpenFlow rulesnetwork

low

-leve

lin

vent

ory

tabl

eshi

gh-le

vel

app

view

s

6

-relation — the plain data representation- table — stored relation- view — virtual relation-SQL — the universal data

language- query, update, trigger, rule

a database-defined network

view

view new view

table table

operator and/or application

OpenFlow rulesnetwork

low

-leve

lin

vent

ory

tabl

eshi

gh-le

vel

app

view

s

6

view

view new view

table table

+

operator and/or application

OpenFlow rulesnetwork

6

attractive features-ad-hoc programmable

abstraction via views

-orchestration across abstractions via view mechanism

-orchestration across applications via data mediation

-network control via SQL

Ravel: a realization with SQL databaseda

taba

se r

untim

e

view

view new view

table table

+

operator and/or application

OpenFlow rulesnetwork

6

attractive features-ad-hoc programmable

abstraction via views

-orchestration across abstractions via view mechanism

-orchestration across applications via data mediation

-network control via SQL

Ravel: a realization with SQL databaseda

taba

se r

untim

e

view

view new view

table table

+

operator and/or application

OpenFlow rulesnetwork

6

attractive features-ad-hoc programmable

abstraction via views

-orchestration across abstractions via view mechanism

-orchestration across applications via data mediation

-network control via SQL

Ravel: a realization with SQL databaseda

taba

se r

untim

e

view

view new view

table table

+

operator and/or application

OpenFlow rulesnetwork

6

attractive features-ad-hoc programmable

abstraction via views

-orchestration across abstractions via view mechanism

-orchestration across applications via data mediation

-network control via SQL

Ravel: a realization with SQL databaseda

taba

se r

untim

e

view

view new view

table table

+

operator and/or application

OpenFlow rulesnetwork

6

attractive features-ad-hoc programmable

abstraction via views

-orchestration across abstractions via view mechanism

-orchestration across applications via data mediation

-network control via SQL

Ravel: a realization with SQL databaseda

taba

se r

untim

e

view

view new view

table table

+

operator and/or application

OpenFlow rulesnetwork

6

attractive features-abstraction

-orchestration

-SQL

Ravel: a realization with SQL databaseda

taba

se r

untim

e

abstraction: network tables

S2

S1

S3

S4

h2

h4

E

h3

h1

flow 1

flow 2

configurationfid sid nid1 S1 S4

1 S4 h4

reachability matrixfid src dst vol …1 h1 h4 52 h2 h3 9

topologysid nidS1 S2

S1 S3

S1 h1

7

……

abstraction: application view

CREATE TABLE acl ( end1 integer, end2 integer, allow integer );

firewall view: monitoring unsafe flows violatingacl policyCREATE VIEW acl_violation AS ( SELECT fid FROM rm WHERE FW = 1 AND (src, dst) NOT IN (SELECT end1, end2 FROM acl

WHERE allow = 1) );

firewall control: repairing violation

CREATE RULE acl_repair AS ON DELETE TO acl_violation DO INSTEAD DELETE FROM rm WHERE fid = OLD.fid;

8

abstraction: application view

many more- routing, stateful firewall, service chain policy between subdomains …

CREATE TABLE acl ( end1 integer, end2 integer, allow integer );

firewall view: monitoring unsafe flows violatingacl policyCREATE VIEW acl_violation AS ( SELECT fid FROM rm WHERE FW = 1 AND (src, dst) NOT IN (SELECT end1, end2 FROM acl

WHERE allow = 1) );

firewall control: repairing violation

CREATE RULE acl_repair AS ON DELETE TO acl_violation DO INSTEAD DELETE FROM rm WHERE fid = OLD.fid;

8

routing app: check broken path, re-route

Mininet

orch

estr

ated

Rav

el r

untim

e

orchestration across representationsne

twor

k ta

ble

app

view shortest

path view

configurationtable

topologytable

shortest path

configurationtopology

SQL rule:upon broken path, re-route

9

routing app: check broken path, re-route

Mininet

orch

estr

ated

Rav

el r

untim

e

orchestration across representationsne

twor

k ta

ble

app

view shortest

path view

configurationtable

topologytable

shortest path

configurationtopology

SQL rule:upon broken path, re-route

link downMininet link (172,39) down

topologysid nid active

- 172 39 1

+ 172 39 0

app

9

routing app: check broken path, re-route

Mininet

orch

estr

ated

Rav

el r

untim

e

orchestration across representationsne

twor

k ta

ble

app

view shortest

path view

configurationtable

topologytable

shortest path

configurationtopology

SQL rule:upon broken path, re-route

link downMininet link (172,39) down

topologysid nid active

- 172 39 1+ 172 39 0

shortest path… path

-…

{…,172,39,156,…}

topologysid nid active

- 172 39 1

+ 172 39 0

app

9

routing app: check broken path, re-route

Mininet

orch

estr

ated

Rav

el r

untim

e

orchestration across representationsne

twor

k ta

ble

app

view shortest

path view

configurationtable

topologytable

shortest path

configurationtopology

SQL rule:upon broken path, re-route

link downMininet link (172,39) down

topologysid nid active

- 172 39 1

+ 172 39 0

shortest path… path

-…

{…,172,39,156,…}

+…

{…,172,38,148,…}

app

9

routing app: check broken path, re-route

Mininet

orch

estr

ated

Rav

el r

untim

e

orchestration across representationsne

twor

k ta

ble

app

view shortest

path view

configurationtable

topologytable

shortest path

configurationtopology

SQL rule:upon broken path, re-route

link downMininet link (172,39) down

topologysid nid active

- 172 39 1

+ 172 39 0

shortest path… path

-…

{…,172,39,156,…}

+…

{…,172,38,148,…}

configurationfid sid nid

- … 172 39

- … 39 156

+ … 172 38

+ … 38 148

app

9

routing app: check broken path, re-route

Mininet

orch

estr

ated

Rav

el r

untim

e

orchestration across representationsne

twor

k ta

ble

app

view shortest

path view

configurationtable

topologytable

shortest path

configurationtopology

SQL rule:upon broken path, re-route

link downMininet link (172,39) down

topologysid nid active

- 172 39 1

+ 172 39 0

shortest path… path

-…

{…,172,39,156,…}

+…

{…,172,38,148,…}

configurationfid sid nid

- … 172 39

- … 39 156

+ … 172 38

+ … 38 148add_flowdel_flow

orchestrated updates: re-route via (172, 38)

apps

9

Mininet

orch

estr

ated

dat

abas

e ru

ntim

e

netw

ork

tabl

eap

p vi

ew

shortest path

configurationtable

reachabilitymatrix

loadbalancer

accesscontrol

firewallbalanceload

maintain path

priority: low → high

apps load balancer shortest path

reachability matrix

tenant virtual net

configuration

orchestration across applicationsaccess control

10

tenantvirtual net

Mininet

orch

estr

ated

dat

abas

e ru

ntim

e

netw

ork

tabl

eap

p vi

ew

shortest path

configurationtable

reachabilitymatrix

loadbalancer

accesscontrol

firewallbalanceload

maintain path

priority: low → high

apps load balancer shortest path

reachability matrix

tenant policy

configuration

orchestration across applications

tenantrequest

tenant requesthost 1238 toserver 1003

tenant virtual net… host server

+ … 1238 1003

access control

10

tenantvirtual net

Mininet

orch

estr

ated

dat

abas

e ru

ntim

e

netw

ork

tabl

eap

p vi

ew

shortest path

configurationtable

reachabilitymatrix

loadbalancer

accesscontrol

firewallbalanceload

maintain path

priority: low → high

app load balancer shortest path

reachability matrix

tenant policy

configuration

orchestration across applications

tenantrequest

tenant requesthost 1238 toserver 1003

tenant virtual net… host server

+ … 1238 1003

load balancersid load

+ 1003 4

- 1003 3

access control

10

tenantvirtual net

Mininet

orch

estr

ated

dat

abas

e ru

ntim

e

netw

ork

tabl

eap

p vi

ew

shortest path

configurationtable

reachabilitymatrix

loadbalancer

accesscontrol

firewallre-load maintain path

priority: low → high

app load balancer shortest path

reachability matrix

tenant policy

configuration

orchestration across applications

tenantrequest

tenant requesthost 1238 toserver 1003

tenant virtual net… host server

+ … 1238 1003+ 1238 1034

load balancersid load

+ 1003 4

- 1003 3

- 1034 1

+ 1034 2

access control

10

tenantvirtual net

Mininet

orch

estr

ated

dat

abas

e ru

ntim

e

netw

ork

tabl

eap

p vi

ew

shortest path

configurationtable

reachabilitymatrix

loadbalancer

accesscontrol

checkre-load maintain path

priority: low → high

app load balancer shortest path

reachability matrix

tenant policy

configuration

orchestration across applications

tenantrequest

tenant requesthost 1238 toserver 1003

tenant virtual net… host server

+ … 1238 1003+ 1238 1034

load balancersid load

+ 1003 4

- 1003 3

- 1034 1

+ 1034 2

access controlsrc dst allow

12381034 112381003 0

10

tenantvirtual net

Mininet

orch

estr

ated

dat

abas

e ru

ntim

e

netw

ork

tabl

eap

p vi

ew

shortest path

configurationtable

reachabilitymatrix

loadbalancer

accesscontrol

checkre-load maintain path

priority: low → high

app load balancer shortest path

traffic matrix

tenant policy

configuration

orchestration across applications

tenantrequest

tenant requesthost 1238 toserver 1003

tenant virtual net… host server

+ … 1238 1003

+ 1238 1034

load balancersid load

+ 1003 4

- 1003 3

- 1034 1

+ 1034 2

access controlsrc dst allow

12381034 112381003 0

reachability matrix

fid sid nid+ … 1238 1034

10

tenantvirtual net

Mininet

orch

estr

ated

dat

abas

e ru

ntim

e

netw

ork

tabl

eap

p vi

ew

shortest path

configurationtable

reachabilitymatrix

loadbalancer

accesscontrol

checkre-load maintain path

priority: low → high

app load balancer shortest path

traffic matrix

tenant policy

configuration

orchestration across applications

tenantrequest

tenant requesthost 1238 toserver 1003

tenant virtual net… host server

+ … 1238 1003

+ 1238 1034

load balancersid load

+ 1003 4

- 1003 3

- 1034 1

+ 1034 2

access controlsrc dst allow

12381034 112381003 0

reachability matrixfid sid nid

+ … 1238 1034

shortest path… path

+ … {1238,…,1034}

10

tenantvirtual net

Mininet

orch

estr

ated

dat

abas

e ru

ntim

e

netw

ork

tabl

eap

p vi

ew

shortest path

configurationtable

reachabilitymatrix

loadbalancer

accesscontrol

checkre-load maintain path

priority: low → high

app load balancer shortest path

traffic matrix

tenant policy

configuration

orchestration across applications

tenantrequest

tenant requesthost 1238 toserver 1003

tenant virtual net… host server

+ … 1238 1003

+ 1238 1034

load balancersid load

+ 1003 4

- 1003 3

- 1034 1

+ 1034 2

access controlsrc dst allow

12381034 112381003 0

reachability matrix

fid sid nid

+ … 1238 1034

shortest path… path

+ … {1238,…,1034}

configurationfid sid nid

+ … … 1034

10

tenantvirtual net

Mininet

orch

estr

ated

dat

abas

e ru

ntim

e

netw

ork

tabl

eap

p vi

ew

shortest path

configurationtable

reachabilitymatrix

loadbalancer

accesscontrol

checkre-load maintain path

priority: low → high

app load balancer shortest path

traffic matrix

tenant policy

configuration

orchestration across applications

tenantrequest

tenant requesthost 1238 toserver 1003

tenant virtual net… host server

+ … 1238 1003

+ 1238 1034

load balancersid load

+ 1003 4

- 1003 3

- 1034 1

+ 1034 2

access controlsrc dst allow

12381034 112381003 0

reachability matrixfid sid nid

+ … 1238 1034

shortest path

… path

+ … {1238,…,1034}

configurationfid sid nid

+ … … 1034

orchestrated updates: install alternative route that is load-balanced and safe10

tenantvirtual net

attractive features-ad-hoc programmable

abstraction via views

-orchestration across abstractions via view mechanism

-orchestration across applications via data mediation

-network control via SQL

achieving Ravel advantages

view

view new view

table table

+

operator and/or application

OpenFlow rulesnetwork

data

base

run

time

11

view viewview

notification

view view

operation viaSQL interface

view

mai

nten

ance

network

tabletabletable

optimizer

ad-hoc programmable abstraction via views

- challenge: inefficient user view

- solution: optimizer - materialize user view with fast

maintenance algorithm- one order of magnitude faster access

with small maintenance overhead — 0.01~10ms

11

runtime

orchestration

view viewview

notification

view view

operation viaSQL interface

network

tabletabletable

optimizer

11

view

mai

nten

ance

view

upd

ate

orchestration across applications

- challenge: database lacking inter-view support

- solution: mediation protocol - translate app priority into view updates

that dynamically merge into a coherent data plane

runtime

orchestration

OpenFlow manager

view viewview

notification

even

tsco

ntro

l

view view

operation viaSQL interface

SQL trigger

view

mai

nten

ance

view

upd

ate

Post

greS

QL

Rav

el r

untim

e

network

tabletabletable

optimizer

11

SDN control via SQL

- challenge: database lacks connection to network data plane

- solution: SQL trigger + OF manager

runtime

runtime

orchestration

OpenFlow manager

view viewview

notification

even

tsco

ntro

l

view view

operation viaSQL interface

SQL trigger

view

mai

nten

ance

view

upd

ate

Post

greS

QL

Rav

el r

untim

e

network

tabletabletable

optimizer

a high-performance runtime

- PostgreSQL

- orchestration

- optimizer

- SQL trigger and OF manager

11

evaluation

text text text

text

text

12

Rocketfuel ISP topologyAS# nodes links4755 142 2583356 1772 136407018 25382 11292

�������� ������� �������

��

������������������� ������������������������Figure 3: Sources of Ravel delay (ms) for route insertion and deletion.

Figure 4: CDF of orchestration delay: normalized per-rule orches-tration delay (ms) on various network sizes.

Figure 5: (a) CDF of querying (ms) on a view and its materializedequivalent. (b,c) CDF of maintenance delay (ms).

lb+acl+rt is bound by rt, and x@t is almost identical to thatof x.

Optimizing application viewsRavel optimizes application views by translating them into equiv-

alent materialized tables that offer faster access with small over-head. Figure 5 (a) compares the performance (query delay) on aload balancer view (v) and its materialized version (o) for threepolicy sizes (10,100,1000). Queries on optimized views (blueshade) are an order of magnitude faster (.1ms vs 1-2ms). As pol-icy size grows (from 10 to 1000), the performance gain is moreobvious. Figure 5 (b,c) shows the overhead of view maintenance,measured on three fat-tree topologies (k=16,32,64) and two sce-narios: updates (deletion and insertion) to lb_tb and rm. In allcases, view maintenance incurs small delay (single-digit ms) thatscales well to large network size.

7. RELATED WORKDeclarative networking. In the pre-SDN era, declarative network-ing [17, 16, 19] — a combined effort of deductive database (recur-sive datalog) and distributed system (distributed query optimiza-tion) research — uses a distributed recursive query engine as anextensible and efficient routing infrastructure. This allows rapid im-plementation and deployment of new distributed protocols, makingit an alternative design point that strikes a balance among its peerslike overlay [18] and active networks [11]. Ravel differs in everyaspect. We build on relational database research, making novel use

of SQL views and contributing new data mediation techniques, withtarget usage — mediating applications with higher-level user sup-port in a centralized setting — better described in network OS andSDN programming APIs.

Database usage in network controllers. The use of database andthe notion of network-wide views are not unfamiliar. Advanceddistributed controllers such as Onix [15] and ONOS [3] provideconsistent network-wide views over distributed network elementsand multiple controller instance. Unlike Ravel, these systems usethe database as a mere transactional repository to “outsource” statemanagement for distributed and replicated network states, and treatthe database as a passive recipient that only executes queries andtransactions. Furthermore, the network-wide views are often pre-defined by the system (e.g., Onix’s NIB APIs with fixed schemas forall control applications), making little use of user-centered databaseviews. In Ravel, the database is the reactive controller with user-centered database views: control applications and the dynamic or-chestrations are moved into the database itself, while SQL offers anative means to create and adjust application-specific ad-hoc views.

8. CONCLUSIONWe present a novel SDN design, Ravel, based on a standard SQL

database. With the simple and familiar SQL query, constraints, andtriggers, non-experts can rapidly launch, modify, and switch be-tween abstractions that best fit their needs. The database runtime,enhanced with view mechanisms and a data mediating protocol, al-lows multiple disparate applications — collaborative or competi-tive — to collectively drive the network in a user-defined mean-ingful way. A prototype built on the PostgreSQL database exhibitspromising performance even for large scale networks.

9. ACKNOWLEDGMENTSThis work was supported by an NSA Science of Security grant,

and NSF grant CNS 1513906.

10. REFERENCES[1] Route views project. http://www.routeviews.org.[2] BANCILHON, F., AND SPYRATOS, N. Update semantics of

relational views. ACM Trans. Database Syst. 6, 4 (Dec.1981), 557–575.

[3] BERDE, P., GEROLA, M., HART, J., HIGUCHI, Y.,KOBAYASHI, M., KOIDE, T., LANTZ, B., O’CONNOR, B.,RADOSLAVOV, P., SNOW, W., AND PARULKAR, G. Onos:Towards an open, distributed sdn os. In Proceedings of theThird Workshop on Hot Topics in Software DefinedNetworking (New York, NY, USA, 2014), HotSDN ’14,ACM, pp. 1–6.

[4] BOHANNON, A., PIERCE, B. C., AND VAUGHAN, J. A.Relational lenses: A language for updatable views. InProceedings of the Twenty-fifth ACMSIGMOD-SIGACT-SIGART Symposium on Principles ofDatabase Systems (New York, NY, USA, 2006), PODS ’06,ACM, pp. 338–347.

profile end to end delay (normalized per-rule, 30 rounds) for route insertion and deletion

dele

tion

(ms)

inse

rtio

n(m

s) compute pathlookup portswrite to tabletrigger/rule

evaluation

text text text

text

text

12

Rocketfuel ISP topologyAS# nodes links4755 142 2583356 1772 136407018 25382 11292

�������� ������� �������

��

������������������� ������������������������Figure 3: Sources of Ravel delay (ms) for route insertion and deletion.

Figure 4: CDF of orchestration delay: normalized per-rule orches-tration delay (ms) on various network sizes.

Figure 5: (a) CDF of querying (ms) on a view and its materializedequivalent. (b,c) CDF of maintenance delay (ms).

lb+acl+rt is bound by rt, and x@t is almost identical to thatof x.

Optimizing application viewsRavel optimizes application views by translating them into equiv-

alent materialized tables that offer faster access with small over-head. Figure 5 (a) compares the performance (query delay) on aload balancer view (v) and its materialized version (o) for threepolicy sizes (10,100,1000). Queries on optimized views (blueshade) are an order of magnitude faster (.1ms vs 1-2ms). As pol-icy size grows (from 10 to 1000), the performance gain is moreobvious. Figure 5 (b,c) shows the overhead of view maintenance,measured on three fat-tree topologies (k=16,32,64) and two sce-narios: updates (deletion and insertion) to lb_tb and rm. In allcases, view maintenance incurs small delay (single-digit ms) thatscales well to large network size.

7. RELATED WORKDeclarative networking. In the pre-SDN era, declarative network-ing [17, 16, 19] — a combined effort of deductive database (recur-sive datalog) and distributed system (distributed query optimiza-tion) research — uses a distributed recursive query engine as anextensible and efficient routing infrastructure. This allows rapid im-plementation and deployment of new distributed protocols, makingit an alternative design point that strikes a balance among its peerslike overlay [18] and active networks [11]. Ravel differs in everyaspect. We build on relational database research, making novel use

of SQL views and contributing new data mediation techniques, withtarget usage — mediating applications with higher-level user sup-port in a centralized setting — better described in network OS andSDN programming APIs.

Database usage in network controllers. The use of database andthe notion of network-wide views are not unfamiliar. Advanceddistributed controllers such as Onix [15] and ONOS [3] provideconsistent network-wide views over distributed network elementsand multiple controller instance. Unlike Ravel, these systems usethe database as a mere transactional repository to “outsource” statemanagement for distributed and replicated network states, and treatthe database as a passive recipient that only executes queries andtransactions. Furthermore, the network-wide views are often pre-defined by the system (e.g., Onix’s NIB APIs with fixed schemas forall control applications), making little use of user-centered databaseviews. In Ravel, the database is the reactive controller with user-centered database views: control applications and the dynamic or-chestrations are moved into the database itself, while SQL offers anative means to create and adjust application-specific ad-hoc views.

8. CONCLUSIONWe present a novel SDN design, Ravel, based on a standard SQL

database. With the simple and familiar SQL query, constraints, andtriggers, non-experts can rapidly launch, modify, and switch be-tween abstractions that best fit their needs. The database runtime,enhanced with view mechanisms and a data mediating protocol, al-lows multiple disparate applications — collaborative or competi-tive — to collectively drive the network in a user-defined mean-ingful way. A prototype built on the PostgreSQL database exhibitspromising performance even for large scale networks.

9. ACKNOWLEDGMENTSThis work was supported by an NSA Science of Security grant,

and NSF grant CNS 1513906.

10. REFERENCES[1] Route views project. http://www.routeviews.org.[2] BANCILHON, F., AND SPYRATOS, N. Update semantics of

relational views. ACM Trans. Database Syst. 6, 4 (Dec.1981), 557–575.

[3] BERDE, P., GEROLA, M., HART, J., HIGUCHI, Y.,KOBAYASHI, M., KOIDE, T., LANTZ, B., O’CONNOR, B.,RADOSLAVOV, P., SNOW, W., AND PARULKAR, G. Onos:Towards an open, distributed sdn os. In Proceedings of theThird Workshop on Hot Topics in Software DefinedNetworking (New York, NY, USA, 2014), HotSDN ’14,ACM, pp. 1–6.

[4] BOHANNON, A., PIERCE, B. C., AND VAUGHAN, J. A.Relational lenses: A language for updatable views. InProceedings of the Twenty-fifth ACMSIGMOD-SIGACT-SIGART Symposium on Principles ofDatabase Systems (New York, NY, USA, 2006), PODS ’06,ACM, pp. 338–347.

profile end to end delay (normalized per-rule, 30 rounds) for route insertion and deletion

dele

tion

(ms)

inse

rtio

n(m

s) compute pathlookup portswrite to tabletrigger/rule

evaluation

text text text

text

text

12

Rocketfuel ISP topologyAS# nodes links4755 142 2583356 1772 136407018 25382 11292

�������� ������� �������

��

������������������� ������������������������Figure 3: Sources of Ravel delay (ms) for route insertion and deletion.

Figure 4: CDF of orchestration delay: normalized per-rule orches-tration delay (ms) on various network sizes.

Figure 5: (a) CDF of querying (ms) on a view and its materializedequivalent. (b,c) CDF of maintenance delay (ms).

lb+acl+rt is bound by rt, and x@t is almost identical to thatof x.

Optimizing application viewsRavel optimizes application views by translating them into equiv-

alent materialized tables that offer faster access with small over-head. Figure 5 (a) compares the performance (query delay) on aload balancer view (v) and its materialized version (o) for threepolicy sizes (10,100,1000). Queries on optimized views (blueshade) are an order of magnitude faster (.1ms vs 1-2ms). As pol-icy size grows (from 10 to 1000), the performance gain is moreobvious. Figure 5 (b,c) shows the overhead of view maintenance,measured on three fat-tree topologies (k=16,32,64) and two sce-narios: updates (deletion and insertion) to lb_tb and rm. In allcases, view maintenance incurs small delay (single-digit ms) thatscales well to large network size.

7. RELATED WORKDeclarative networking. In the pre-SDN era, declarative network-ing [17, 16, 19] — a combined effort of deductive database (recur-sive datalog) and distributed system (distributed query optimiza-tion) research — uses a distributed recursive query engine as anextensible and efficient routing infrastructure. This allows rapid im-plementation and deployment of new distributed protocols, makingit an alternative design point that strikes a balance among its peerslike overlay [18] and active networks [11]. Ravel differs in everyaspect. We build on relational database research, making novel use

of SQL views and contributing new data mediation techniques, withtarget usage — mediating applications with higher-level user sup-port in a centralized setting — better described in network OS andSDN programming APIs.

Database usage in network controllers. The use of database andthe notion of network-wide views are not unfamiliar. Advanceddistributed controllers such as Onix [15] and ONOS [3] provideconsistent network-wide views over distributed network elementsand multiple controller instance. Unlike Ravel, these systems usethe database as a mere transactional repository to “outsource” statemanagement for distributed and replicated network states, and treatthe database as a passive recipient that only executes queries andtransactions. Furthermore, the network-wide views are often pre-defined by the system (e.g., Onix’s NIB APIs with fixed schemas forall control applications), making little use of user-centered databaseviews. In Ravel, the database is the reactive controller with user-centered database views: control applications and the dynamic or-chestrations are moved into the database itself, while SQL offers anative means to create and adjust application-specific ad-hoc views.

8. CONCLUSIONWe present a novel SDN design, Ravel, based on a standard SQL

database. With the simple and familiar SQL query, constraints, andtriggers, non-experts can rapidly launch, modify, and switch be-tween abstractions that best fit their needs. The database runtime,enhanced with view mechanisms and a data mediating protocol, al-lows multiple disparate applications — collaborative or competi-tive — to collectively drive the network in a user-defined mean-ingful way. A prototype built on the PostgreSQL database exhibitspromising performance even for large scale networks.

9. ACKNOWLEDGMENTSThis work was supported by an NSA Science of Security grant,

and NSF grant CNS 1513906.

10. REFERENCES[1] Route views project. http://www.routeviews.org.[2] BANCILHON, F., AND SPYRATOS, N. Update semantics of

relational views. ACM Trans. Database Syst. 6, 4 (Dec.1981), 557–575.

[3] BERDE, P., GEROLA, M., HART, J., HIGUCHI, Y.,KOBAYASHI, M., KOIDE, T., LANTZ, B., O’CONNOR, B.,RADOSLAVOV, P., SNOW, W., AND PARULKAR, G. Onos:Towards an open, distributed sdn os. In Proceedings of theThird Workshop on Hot Topics in Software DefinedNetworking (New York, NY, USA, 2014), HotSDN ’14,ACM, pp. 1–6.

[4] BOHANNON, A., PIERCE, B. C., AND VAUGHAN, J. A.Relational lenses: A language for updatable views. InProceedings of the Twenty-fifth ACMSIGMOD-SIGACT-SIGART Symposium on Principles ofDatabase Systems (New York, NY, USA, 2006), PODS ’06,ACM, pp. 338–347.

profile end to end delay (normalized per-rule, 30 rounds) for route insertion and deletion

dele

tion

(ms)

inse

rtio

n(m

s) compute pathlookup portswrite to tabletrigger/rule

evaluation

text text text

text

text

12

Rocketfuel ISP topologyAS# nodes links4755 142 2583356 1772 136407018 25382 11292

�������� ������� �������

��

������������������� ������������������������Figure 3: Sources of Ravel delay (ms) for route insertion and deletion.

Figure 4: CDF of orchestration delay: normalized per-rule orches-tration delay (ms) on various network sizes.

Figure 5: (a) CDF of querying (ms) on a view and its materializedequivalent. (b,c) CDF of maintenance delay (ms).

lb+acl+rt is bound by rt, and x@t is almost identical to thatof x.

Optimizing application viewsRavel optimizes application views by translating them into equiv-

alent materialized tables that offer faster access with small over-head. Figure 5 (a) compares the performance (query delay) on aload balancer view (v) and its materialized version (o) for threepolicy sizes (10,100,1000). Queries on optimized views (blueshade) are an order of magnitude faster (.1ms vs 1-2ms). As pol-icy size grows (from 10 to 1000), the performance gain is moreobvious. Figure 5 (b,c) shows the overhead of view maintenance,measured on three fat-tree topologies (k=16,32,64) and two sce-narios: updates (deletion and insertion) to lb_tb and rm. In allcases, view maintenance incurs small delay (single-digit ms) thatscales well to large network size.

7. RELATED WORKDeclarative networking. In the pre-SDN era, declarative network-ing [17, 16, 19] — a combined effort of deductive database (recur-sive datalog) and distributed system (distributed query optimiza-tion) research — uses a distributed recursive query engine as anextensible and efficient routing infrastructure. This allows rapid im-plementation and deployment of new distributed protocols, makingit an alternative design point that strikes a balance among its peerslike overlay [18] and active networks [11]. Ravel differs in everyaspect. We build on relational database research, making novel use

of SQL views and contributing new data mediation techniques, withtarget usage — mediating applications with higher-level user sup-port in a centralized setting — better described in network OS andSDN programming APIs.

Database usage in network controllers. The use of database andthe notion of network-wide views are not unfamiliar. Advanceddistributed controllers such as Onix [15] and ONOS [3] provideconsistent network-wide views over distributed network elementsand multiple controller instance. Unlike Ravel, these systems usethe database as a mere transactional repository to “outsource” statemanagement for distributed and replicated network states, and treatthe database as a passive recipient that only executes queries andtransactions. Furthermore, the network-wide views are often pre-defined by the system (e.g., Onix’s NIB APIs with fixed schemas forall control applications), making little use of user-centered databaseviews. In Ravel, the database is the reactive controller with user-centered database views: control applications and the dynamic or-chestrations are moved into the database itself, while SQL offers anative means to create and adjust application-specific ad-hoc views.

8. CONCLUSIONWe present a novel SDN design, Ravel, based on a standard SQL

database. With the simple and familiar SQL query, constraints, andtriggers, non-experts can rapidly launch, modify, and switch be-tween abstractions that best fit their needs. The database runtime,enhanced with view mechanisms and a data mediating protocol, al-lows multiple disparate applications — collaborative or competi-tive — to collectively drive the network in a user-defined mean-ingful way. A prototype built on the PostgreSQL database exhibitspromising performance even for large scale networks.

9. ACKNOWLEDGMENTSThis work was supported by an NSA Science of Security grant,

and NSF grant CNS 1513906.

10. REFERENCES[1] Route views project. http://www.routeviews.org.[2] BANCILHON, F., AND SPYRATOS, N. Update semantics of

relational views. ACM Trans. Database Syst. 6, 4 (Dec.1981), 557–575.

[3] BERDE, P., GEROLA, M., HART, J., HIGUCHI, Y.,KOBAYASHI, M., KOIDE, T., LANTZ, B., O’CONNOR, B.,RADOSLAVOV, P., SNOW, W., AND PARULKAR, G. Onos:Towards an open, distributed sdn os. In Proceedings of theThird Workshop on Hot Topics in Software DefinedNetworking (New York, NY, USA, 2014), HotSDN ’14,ACM, pp. 1–6.

[4] BOHANNON, A., PIERCE, B. C., AND VAUGHAN, J. A.Relational lenses: A language for updatable views. InProceedings of the Twenty-fifth ACMSIGMOD-SIGACT-SIGART Symposium on Principles ofDatabase Systems (New York, NY, USA, 2006), PODS ’06,ACM, pp. 338–347.

profile end to end delay (normalized per-rule, 30 rounds) for route insertion and deletion

dele

tion

(ms)

inse

rtio

n(m

s) compute pathlookup portswrite to tabletrigger/rule

Rocketfuel ISP AS# nodes links4755 142 2583356 1772 136407018 25382 1129210

4

evaluation

text text text

text

text

12

Rocketfuel ISP topologyAS# nodes links4755 142 2583356 1772 136407018 25382 11292

�������� ������� �������

��

������������������� ������������������������Figure 3: Sources of Ravel delay (ms) for route insertion and deletion.

Figure 4: CDF of orchestration delay: normalized per-rule orches-tration delay (ms) on various network sizes.

Figure 5: (a) CDF of querying (ms) on a view and its materializedequivalent. (b,c) CDF of maintenance delay (ms).

lb+acl+rt is bound by rt, and x@t is almost identical to thatof x.

Optimizing application viewsRavel optimizes application views by translating them into equiv-

alent materialized tables that offer faster access with small over-head. Figure 5 (a) compares the performance (query delay) on aload balancer view (v) and its materialized version (o) for threepolicy sizes (10,100,1000). Queries on optimized views (blueshade) are an order of magnitude faster (.1ms vs 1-2ms). As pol-icy size grows (from 10 to 1000), the performance gain is moreobvious. Figure 5 (b,c) shows the overhead of view maintenance,measured on three fat-tree topologies (k=16,32,64) and two sce-narios: updates (deletion and insertion) to lb_tb and rm. In allcases, view maintenance incurs small delay (single-digit ms) thatscales well to large network size.

7. RELATED WORKDeclarative networking. In the pre-SDN era, declarative network-ing [17, 16, 19] — a combined effort of deductive database (recur-sive datalog) and distributed system (distributed query optimiza-tion) research — uses a distributed recursive query engine as anextensible and efficient routing infrastructure. This allows rapid im-plementation and deployment of new distributed protocols, makingit an alternative design point that strikes a balance among its peerslike overlay [18] and active networks [11]. Ravel differs in everyaspect. We build on relational database research, making novel use

of SQL views and contributing new data mediation techniques, withtarget usage — mediating applications with higher-level user sup-port in a centralized setting — better described in network OS andSDN programming APIs.

Database usage in network controllers. The use of database andthe notion of network-wide views are not unfamiliar. Advanceddistributed controllers such as Onix [15] and ONOS [3] provideconsistent network-wide views over distributed network elementsand multiple controller instance. Unlike Ravel, these systems usethe database as a mere transactional repository to “outsource” statemanagement for distributed and replicated network states, and treatthe database as a passive recipient that only executes queries andtransactions. Furthermore, the network-wide views are often pre-defined by the system (e.g., Onix’s NIB APIs with fixed schemas forall control applications), making little use of user-centered databaseviews. In Ravel, the database is the reactive controller with user-centered database views: control applications and the dynamic or-chestrations are moved into the database itself, while SQL offers anative means to create and adjust application-specific ad-hoc views.

8. CONCLUSIONWe present a novel SDN design, Ravel, based on a standard SQL

database. With the simple and familiar SQL query, constraints, andtriggers, non-experts can rapidly launch, modify, and switch be-tween abstractions that best fit their needs. The database runtime,enhanced with view mechanisms and a data mediating protocol, al-lows multiple disparate applications — collaborative or competi-tive — to collectively drive the network in a user-defined mean-ingful way. A prototype built on the PostgreSQL database exhibitspromising performance even for large scale networks.

9. ACKNOWLEDGMENTSThis work was supported by an NSA Science of Security grant,

and NSF grant CNS 1513906.

10. REFERENCES[1] Route views project. http://www.routeviews.org.[2] BANCILHON, F., AND SPYRATOS, N. Update semantics of

relational views. ACM Trans. Database Syst. 6, 4 (Dec.1981), 557–575.

[3] BERDE, P., GEROLA, M., HART, J., HIGUCHI, Y.,KOBAYASHI, M., KOIDE, T., LANTZ, B., O’CONNOR, B.,RADOSLAVOV, P., SNOW, W., AND PARULKAR, G. Onos:Towards an open, distributed sdn os. In Proceedings of theThird Workshop on Hot Topics in Software DefinedNetworking (New York, NY, USA, 2014), HotSDN ’14,ACM, pp. 1–6.

[4] BOHANNON, A., PIERCE, B. C., AND VAUGHAN, J. A.Relational lenses: A language for updatable views. InProceedings of the Twenty-fifth ACMSIGMOD-SIGACT-SIGART Symposium on Principles ofDatabase Systems (New York, NY, USA, 2006), PODS ’06,ACM, pp. 338–347.

profile end to end delay (normalized per-rule, 30 rounds) for route insertion and deletion

dele

tion

(ms)

inse

rtio

n(m

s) compute pathlookup portswrite to tabletrigger/rule

evaluation

text text text

text

text

12

Rocketfuel ISP topologyAS# nodes links4755 142 2583356 1772 136407018 25382 11292

�������� ������� �������

��

������������������� ������������������������Figure 3: Sources of Ravel delay (ms) for route insertion and deletion.

Figure 4: CDF of orchestration delay: normalized per-rule orches-tration delay (ms) on various network sizes.

Figure 5: (a) CDF of querying (ms) on a view and its materializedequivalent. (b,c) CDF of maintenance delay (ms).

lb+acl+rt is bound by rt, and x@t is almost identical to thatof x.

Optimizing application viewsRavel optimizes application views by translating them into equiv-

alent materialized tables that offer faster access with small over-head. Figure 5 (a) compares the performance (query delay) on aload balancer view (v) and its materialized version (o) for threepolicy sizes (10,100,1000). Queries on optimized views (blueshade) are an order of magnitude faster (.1ms vs 1-2ms). As pol-icy size grows (from 10 to 1000), the performance gain is moreobvious. Figure 5 (b,c) shows the overhead of view maintenance,measured on three fat-tree topologies (k=16,32,64) and two sce-narios: updates (deletion and insertion) to lb_tb and rm. In allcases, view maintenance incurs small delay (single-digit ms) thatscales well to large network size.

7. RELATED WORKDeclarative networking. In the pre-SDN era, declarative network-ing [17, 16, 19] — a combined effort of deductive database (recur-sive datalog) and distributed system (distributed query optimiza-tion) research — uses a distributed recursive query engine as anextensible and efficient routing infrastructure. This allows rapid im-plementation and deployment of new distributed protocols, makingit an alternative design point that strikes a balance among its peerslike overlay [18] and active networks [11]. Ravel differs in everyaspect. We build on relational database research, making novel use

of SQL views and contributing new data mediation techniques, withtarget usage — mediating applications with higher-level user sup-port in a centralized setting — better described in network OS andSDN programming APIs.

Database usage in network controllers. The use of database andthe notion of network-wide views are not unfamiliar. Advanceddistributed controllers such as Onix [15] and ONOS [3] provideconsistent network-wide views over distributed network elementsand multiple controller instance. Unlike Ravel, these systems usethe database as a mere transactional repository to “outsource” statemanagement for distributed and replicated network states, and treatthe database as a passive recipient that only executes queries andtransactions. Furthermore, the network-wide views are often pre-defined by the system (e.g., Onix’s NIB APIs with fixed schemas forall control applications), making little use of user-centered databaseviews. In Ravel, the database is the reactive controller with user-centered database views: control applications and the dynamic or-chestrations are moved into the database itself, while SQL offers anative means to create and adjust application-specific ad-hoc views.

8. CONCLUSIONWe present a novel SDN design, Ravel, based on a standard SQL

database. With the simple and familiar SQL query, constraints, andtriggers, non-experts can rapidly launch, modify, and switch be-tween abstractions that best fit their needs. The database runtime,enhanced with view mechanisms and a data mediating protocol, al-lows multiple disparate applications — collaborative or competi-tive — to collectively drive the network in a user-defined mean-ingful way. A prototype built on the PostgreSQL database exhibitspromising performance even for large scale networks.

9. ACKNOWLEDGMENTSThis work was supported by an NSA Science of Security grant,

and NSF grant CNS 1513906.

10. REFERENCES[1] Route views project. http://www.routeviews.org.[2] BANCILHON, F., AND SPYRATOS, N. Update semantics of

relational views. ACM Trans. Database Syst. 6, 4 (Dec.1981), 557–575.

[3] BERDE, P., GEROLA, M., HART, J., HIGUCHI, Y.,KOBAYASHI, M., KOIDE, T., LANTZ, B., O’CONNOR, B.,RADOSLAVOV, P., SNOW, W., AND PARULKAR, G. Onos:Towards an open, distributed sdn os. In Proceedings of theThird Workshop on Hot Topics in Software DefinedNetworking (New York, NY, USA, 2014), HotSDN ’14,ACM, pp. 1–6.

[4] BOHANNON, A., PIERCE, B. C., AND VAUGHAN, J. A.Relational lenses: A language for updatable views. InProceedings of the Twenty-fifth ACMSIGMOD-SIGACT-SIGART Symposium on Principles ofDatabase Systems (New York, NY, USA, 2006), PODS ’06,ACM, pp. 338–347.

profile end to end delay (normalized per-rule, 30 rounds) for route insertion and deletion

dele

tion

(ms)

inse

rtio

n(m

s)

similar profile on fat-tree topology (fewer nodes, more links)- total delay < 30ms for fat-tree with 5120 switches and 196608 links

compute pathlookup portswrite to tabletrigger/rule

evaluation Figure 3: Sources of Ravel delay (ms) for route insertion and deletion.

��������������������

���� �� ��� ����

�������

���� �� ��� ����

�������

���� �� ��� ���� �����

������� ������������

���������

������������ ������������ ������������

��

Figure 4: CDF of orchestration delay: normalized per-ruleorchestration delay (ms) on various network sizes.

Figure 5: (a) CDF of querying (ms) on a view and its mate-rialized equivalent. (b,c) CDF of maintenance delay (ms).

We find that Ravel adds a small delay for orchestration,around 1ms for most scenarios. Delay is dominated by rtbecause of its semantics. rt must compute the path and re-configure the switches. In contrast, acl imposes a negligibledelay (¡1ms) since it only needs to read from its blacklist,i.e., a fast key-value lookup. lb sits between these two ap-plications and handles the extra path computation to directtraffic to a less loaded server. In particular, lb+acl+rt isbound by rt, and x@t is almost identical to that of x.

Optimizing application viewsRavel optimizes application views by translating them into

equivalent materialized tables that offers faster access withsmall overhead. Figure 5 (a) compares the performance(query delay) on a load balancer view (v) and its materializedversion (o) for three policy sizes (10,100,1000). Querieson optimized view (blue shade) are one magnitude faster(.1ms vs 1-2ms). As policy size grows (from 10 to 1000),the performance gain is more obvious.Figure 5 (b,c) showsthe overhead of view maintenance, measured on three fat-tree topologies (k=16,32,64) and two scenarios: updates(deletion and insertion) to lb tb and rm. In all cases, viewmaintenance incurs small delay (single digit ms) that scales

well to large network size.

7. RELATED WORKDeclarative networking. In the pre-SDN era, declarativenetworking [17, 16, 19] — a combined effort of deduc-tive database (recursive datalog) and distributed system (dis-tributed query optimization) research — uses a distributedrecursive query engine as an extensible and efficient rout-ing infrastructure. This allows rapid implementation and de-ployment of new distributed protocols, making it an alterna-tive design point that strikes a balance among its peers likeoverlay [18] and active networks [11]. Ravel differs in ev-ery aspect. We build on relational database research, makingnovel use of SQL views and contributing new data mediationtechniques, with target usage — mediating applications withhigher-level user support in a centralized setting — betterdescribed in network OS and SDN programming APIs.

Database usage in network controllers. The use ofdatabase and the notion of network-wide views are not un-familiar. Advanced distributed controllers such as Onix [15]and ONOS [3] provide consistent network-wide views overdistributed network elements and multiple controller in-stance. Unlike Ravel, these systems use the database as amere transactional repository to “outsources” state manage-ment for distributed and replicated network states, and treatthe database as a passive recipient that only executes queriesand transactions. Besides, the network-wide views are of-ten pre-defined by the system (e.g., Onix’s NIB APIs withfixed schemas for all control applications), making little useof user-centered database views. In Ravel, the database is thereactive controller with user-centered database views: con-trol applications and the dynamic orchestrations are movedinto the database itself, while SQL offers a natvie means tocreate and adjust application-specific ad-hoc views.

8. CONCLUSIONWe present a novel SDN design, Ravel, based on a stan-

dard SQL database. With the simple and familiar SQL query,constraints, and triggers, non-experts can rapidly launch,modify, and switch between abstractions that best fit thierneeds. The database runtime, enhanced with view mecha-nisms and a data mediating protocol, allows multiple dis-parate applications — collaborative or competitive — to col-lectively drive the network in a user-defined meaningful way.A prototype built on the Postgres database exhibits promis-ing performance even for large scale networks.

6

13

CD

F

orchestration delay (ms) normalized per-rule for 3 scenarios: access control and routing (acl+rt), load balancing and routing (lb+rt), access control, load balancing, and routing (acl+lb+rt)

evaluation Figure 3: Sources of Ravel delay (ms) for route insertion and deletion.

��������������������

���� �� ��� ����

�������

���� �� ��� ����

�������

���� �� ��� ���� �����

������� ������������

���������

������������ ������������ ������������

��

Figure 4: CDF of orchestration delay: normalized per-ruleorchestration delay (ms) on various network sizes.

Figure 5: (a) CDF of querying (ms) on a view and its mate-rialized equivalent. (b,c) CDF of maintenance delay (ms).

We find that Ravel adds a small delay for orchestration,around 1ms for most scenarios. Delay is dominated by rtbecause of its semantics. rt must compute the path and re-configure the switches. In contrast, acl imposes a negligibledelay (¡1ms) since it only needs to read from its blacklist,i.e., a fast key-value lookup. lb sits between these two ap-plications and handles the extra path computation to directtraffic to a less loaded server. In particular, lb+acl+rt isbound by rt, and x@t is almost identical to that of x.

Optimizing application viewsRavel optimizes application views by translating them into

equivalent materialized tables that offers faster access withsmall overhead. Figure 5 (a) compares the performance(query delay) on a load balancer view (v) and its materializedversion (o) for three policy sizes (10,100,1000). Querieson optimized view (blue shade) are one magnitude faster(.1ms vs 1-2ms). As policy size grows (from 10 to 1000),the performance gain is more obvious.Figure 5 (b,c) showsthe overhead of view maintenance, measured on three fat-tree topologies (k=16,32,64) and two scenarios: updates(deletion and insertion) to lb tb and rm. In all cases, viewmaintenance incurs small delay (single digit ms) that scales

well to large network size.

7. RELATED WORKDeclarative networking. In the pre-SDN era, declarativenetworking [17, 16, 19] — a combined effort of deduc-tive database (recursive datalog) and distributed system (dis-tributed query optimization) research — uses a distributedrecursive query engine as an extensible and efficient rout-ing infrastructure. This allows rapid implementation and de-ployment of new distributed protocols, making it an alterna-tive design point that strikes a balance among its peers likeoverlay [18] and active networks [11]. Ravel differs in ev-ery aspect. We build on relational database research, makingnovel use of SQL views and contributing new data mediationtechniques, with target usage — mediating applications withhigher-level user support in a centralized setting — betterdescribed in network OS and SDN programming APIs.

Database usage in network controllers. The use ofdatabase and the notion of network-wide views are not un-familiar. Advanced distributed controllers such as Onix [15]and ONOS [3] provide consistent network-wide views overdistributed network elements and multiple controller in-stance. Unlike Ravel, these systems use the database as amere transactional repository to “outsources” state manage-ment for distributed and replicated network states, and treatthe database as a passive recipient that only executes queriesand transactions. Besides, the network-wide views are of-ten pre-defined by the system (e.g., Onix’s NIB APIs withfixed schemas for all control applications), making little useof user-centered database views. In Ravel, the database is thereactive controller with user-centered database views: con-trol applications and the dynamic orchestrations are movedinto the database itself, while SQL offers a natvie means tocreate and adjust application-specific ad-hoc views.

8. CONCLUSIONWe present a novel SDN design, Ravel, based on a stan-

dard SQL database. With the simple and familiar SQL query,constraints, and triggers, non-experts can rapidly launch,modify, and switch between abstractions that best fit thierneeds. The database runtime, enhanced with view mecha-nisms and a data mediating protocol, allows multiple dis-parate applications — collaborative or competitive — to col-lectively drive the network in a user-defined meaningful way.A prototype built on the Postgres database exhibits promis-ing performance even for large scale networks.

6

10

13

CD

F

orchestration delay (ms) normalized per-rule for 3 scenarios: access control and routing (acl+rt), load balancing and routing (lb+rt), access control, load balancing, and routing (acl+lb+rt)

evaluation Figure 3: Sources of Ravel delay (ms) for route insertion and deletion.

��������������������

���� �� ��� ����

�������

���� �� ��� ����

�������

���� �� ��� ���� �����

������� ������������

���������

������������ ������������ ������������

��

Figure 4: CDF of orchestration delay: normalized per-ruleorchestration delay (ms) on various network sizes.

Figure 5: (a) CDF of querying (ms) on a view and its mate-rialized equivalent. (b,c) CDF of maintenance delay (ms).

We find that Ravel adds a small delay for orchestration,around 1ms for most scenarios. Delay is dominated by rtbecause of its semantics. rt must compute the path and re-configure the switches. In contrast, acl imposes a negligibledelay (¡1ms) since it only needs to read from its blacklist,i.e., a fast key-value lookup. lb sits between these two ap-plications and handles the extra path computation to directtraffic to a less loaded server. In particular, lb+acl+rt isbound by rt, and x@t is almost identical to that of x.

Optimizing application viewsRavel optimizes application views by translating them into

equivalent materialized tables that offers faster access withsmall overhead. Figure 5 (a) compares the performance(query delay) on a load balancer view (v) and its materializedversion (o) for three policy sizes (10,100,1000). Querieson optimized view (blue shade) are one magnitude faster(.1ms vs 1-2ms). As policy size grows (from 10 to 1000),the performance gain is more obvious.Figure 5 (b,c) showsthe overhead of view maintenance, measured on three fat-tree topologies (k=16,32,64) and two scenarios: updates(deletion and insertion) to lb tb and rm. In all cases, viewmaintenance incurs small delay (single digit ms) that scales

well to large network size.

7. RELATED WORKDeclarative networking. In the pre-SDN era, declarativenetworking [17, 16, 19] — a combined effort of deduc-tive database (recursive datalog) and distributed system (dis-tributed query optimization) research — uses a distributedrecursive query engine as an extensible and efficient rout-ing infrastructure. This allows rapid implementation and de-ployment of new distributed protocols, making it an alterna-tive design point that strikes a balance among its peers likeoverlay [18] and active networks [11]. Ravel differs in ev-ery aspect. We build on relational database research, makingnovel use of SQL views and contributing new data mediationtechniques, with target usage — mediating applications withhigher-level user support in a centralized setting — betterdescribed in network OS and SDN programming APIs.

Database usage in network controllers. The use ofdatabase and the notion of network-wide views are not un-familiar. Advanced distributed controllers such as Onix [15]and ONOS [3] provide consistent network-wide views overdistributed network elements and multiple controller in-stance. Unlike Ravel, these systems use the database as amere transactional repository to “outsources” state manage-ment for distributed and replicated network states, and treatthe database as a passive recipient that only executes queriesand transactions. Besides, the network-wide views are of-ten pre-defined by the system (e.g., Onix’s NIB APIs withfixed schemas for all control applications), making little useof user-centered database views. In Ravel, the database is thereactive controller with user-centered database views: con-trol applications and the dynamic orchestrations are movedinto the database itself, while SQL offers a natvie means tocreate and adjust application-specific ad-hoc views.

8. CONCLUSIONWe present a novel SDN design, Ravel, based on a stan-

dard SQL database. With the simple and familiar SQL query,constraints, and triggers, non-experts can rapidly launch,modify, and switch between abstractions that best fit thierneeds. The database runtime, enhanced with view mecha-nisms and a data mediating protocol, allows multiple dis-parate applications — collaborative or competitive — to col-lectively drive the network in a user-defined meaningful way.A prototype built on the Postgres database exhibits promis-ing performance even for large scale networks.

6

10

13

CD

F

orchestration delay (ms) normalized per-rule for 3 scenarios: access control and routing (acl+rt), load balancing and routing (lb+rt), access control, load balancing, and routing (acl+lb+rt)

orchestration also scales gracefully on fat-tree- < 30ms for fat-tree with 5120 switches and 196608 links

dem

o

15

dem

o

15

towards a secure Ravelimproper modification of data-unauthorized modification-one-directional information flow

14

towards a secure Ravelexpectation of data qualityimproper medication of data-unauthorized modification — access control (ACL)-one-directional information flow

14

ACL in Ravel

orchestration

OpenFlow manager

view viewview

notification

even

tsco

ntro

l

view view

operation viaSQL interface

SQL trigger

view

mai

nten

ance

view

upd

ate

Post

greS

QL

Rav

el r

untim

e

network

tabletabletable

optimizer

15

ACL in Ravel

orchestration

OpenFlow manager

view viewview

notification

even

tsco

ntro

l

view view

operation viaSQL interface

SQL trigger

view

mai

nten

ance

view

upd

ate

Post

greS

QL

Rav

el r

untim

e

network

tabletabletable

optimizer

15

ACL in Ravel

orchestration

OpenFlow manager

view viewview

view view

SQL trigger

network

tabletabletable

optimizer

alice bob carolPo

stgr

eSQ

L

Rav

el r

untim

e

???

15

example scenarioa SDN network and multiple tenants -admin can see/modify all resources, see/modify the network-tenants can only see the resources they pay-tenants can only manage their portions of network under

contractSLA (service level agreement)

tenant switches rate limit connectivity

alice {1,2,3,4} 20 {alice}

bob {51,52,53,…} 50 {bob, alice}

carol {100,101,…} 10 {carol, alice}

16

explicit access control list (ACL)<principal, subject, operation>

-very low-level-update ACL as tenant contract evolves

ACL on topology

users switches privilege

alice 1 read

alice 2 read

alice … read

bob … read

carol … read

admin … read,write

… … …

ACL on configuration

usersflows (source,

destination, rate) privilege

alice (1,2,<20) read,write

alice (2,3,<20) read,write

alice … …

bob … …

… … …

17

ACL in Ravel

orchestration

OpenFlow manager

view viewview

view view

SQL trigger

network

tabletabletable

optimizer

alice bob carol

authorization views

Post

greS

QL

Rav

el r

untim

e

higher-levelfiner-grainedauthorization

via SQL

18

authenticate at database login

ACL in Ravel

orchestration

OpenFlow manager

viewview

view

SQL trigger

network

tabletabletable

optimizer

authorization views

secu

re P

ostg

reSQ

L

Rav

el r

untim

e

18

authorization views: a strawman solution

associate each table with an ACL-<principal, allowed operation>

create a separate view-if only a portion of a table is granted to a principal-benefit: dynamic, content-based

19

authorization views: a strawman solution

-- admin policy GRANT SELECT, UPDATE, INSERT, DELETE ON topology TO admin; GRANT SELECT, UPDATE, INSERT, DELETE ON configuration TO admin;

-- alice policy CREATE OR REPLACE VIEW topology_alice AS ( SELECT sid, nid FROM topology WHERE (topology.sid = 1 OR topology.sid = 2 OR …);

CREATE OR REPLACE VIEW configuration_alice AS ( SELECT fid, sid, nid FROM configuration WHERE ((topology.sid = 1 AND topology.nid = 2) OR (topology.sid = 1 AND topology.nid = 2) OR …) AND rate < 20);

GRANT SELECT ON topology_alice TO alice; GRANT SELECT, INSERT, DELETE, UPDATE ON configuration_alice TO alice;

-- bob policy, carol policy ...

20

limitationsmany tenants-for each tenant, create a separate view?

dynamic tenant membership -add/remove views?

SLAs evolving-update tenant views?

more examples:-tenants can only access the resources the pay-raise tenant rate limit to100

21

finer-grained, higher-level ACLcapture the intent rather than extentdynamic, context-based

a network table of arity np(_,_,…,_)

access control view of n+1 arityp_acl (principal, _,_,…,_)

SQL query over data in p and other parts of the network database

22

- a tenant can only access the leased network topology- admin can access the whole topology

CREATE VIEW topology_acl AS ( -- admin policy (SELECT 'admin' as principal, sid, nid FROM topology) UNION

-- tenant policy (SELECT tenant as principal, sid, nid FROM topology, SLA WHERE topology.sid IN SLA.switches AND topology.nid IN SLA.switches));

CREATE VIEW topology_public AS ( SELECT sid, nid FROM topology_acl WHERE principal = ‘current_user')

GRANT SELECT ON topology_public TO public;

finer-grained, higher-level ACL

23

looking forwarddata integration as a networking service

view

tabletabletable

viewview view

view view

viewview

view

view view

view

table table

integrator (orchestration, optimization)

authorization viewsapp views

coherent network states processing traffic

view view

24

looking forwarddata integration as a networking service

view

power

tabletabletable

view

viewview load balancer

view view

viewview

view

view view

view

table table

conflict (cyclic update dependency) by formal analysis

authorization viewsapp views

coherent network states processing traffic

24

looking forwarddata integration as a networking service

server

view

tabletabletable

back-up

viewview view

view view

viewview

view

view view

view

table table

cross-layer independent failure by multiple-view constraint

authorization viewsapp views

coherent network states processing traffic

24

looking forwarddata integration as a networking service

view

tabletabletable

viewview view

untrustedview view

viewview

view

view view

view

table table

automatic security enforcement by query rewrite

authorization viewsapp views

coherent network states processing traffic

view view

24

conclusionthis talk: via SQL- orchestratable abstraction- finer-grained access control

looking forward- data integration as a networking

service

25

orchestration

OpenFlow manager

viewview

view

SQL trigger

network

tabletabletable

optimizer

authorization views

secu

re P

ostg

reSQ

L

Rav

el r

untim

e

playtimedownload Ravel

ravel-net.org/download

start playing: tutorials, add your own appravel-net.org

explore moregithub.com/ravel-net

26