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