Networks Jennifer Rexford Princeton University With Joshua Reich Chris Monsanto Nate Foster amp David Walker Software Defined Networking SDN 2 Controller Platform Controller Application ID: 658487
Download Presentation The PPT/PDF document "Composing Software Defined" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Composing Software Defined Networks
Jennifer RexfordPrinceton University
With Joshua Reich, Chris Monsanto, Nate Foster, & David WalkerSlide2
Software Defined Networking (SDN)
2
Controller Platform
Controller Application
Network-wide visibility and control
Direct control via open interface
But, how should we write controller applications?Slide3
Combining Many Networking Tasks
3
Controller Platform
Route + Monitor + FW + LB
Monolithic application
Hard to program, test, debug, reuse, port, …Slide4
Modular Controller Applications
4
Controller Platform
LB
Route
Monitor
FW
Easier to program, test, and debug
Greater reusability and portability
A module for each taskSlide5
Beyond Multi-Tenancy
5
Controller Platform
Slice 1
Slice
2
Slice
n
...
Each module controls a
different
portion of the traffic
Relatively easy to partition
rule space
,
link
bandwidth
, and
network events
across modulesSlide6
Modules Affect the Same Traffic
6
Controller Platform
LB
Route
Monitor
FW
How to combine modules into a complete application?
Each module
partially
specifies the handling of the trafficSlide7
Parallel Composition [ICFP’11, POPL’12]
7
Controller Platform
Route on
dest
prefix
Monitor on source IP
+
dstip
= 1.2/16
fwd
(1)
dstip
= 3.4.5/24
fwd
(2
)
s
rcip
= 5.6.7.8
count
s
rcip
= 5.6.7.9 count
s
rcip
= 5.6.7.8,
dstip
= 1.2/16
fwd
(1), count
srcip
= 5.6.7.8,
dstip
= 3.4.5/24
fwd
(2
), count
srcip
=
5.6.7.9,
dstip
= 1.2/16
fwd
(1), count
srcip
=
5.6.7.9,
dstip
= 3.4.5/24
fwd
(2),
countSlide8
Spread client traffic over server replicasPublic IP address for the service
Split traffic based on client IPRewrite the server IP addressThen, route to the replicaExample: Server Load Balancer
clients
1.2.3.4
l
oad balancer
s
erver replicas
10.0.0.1
10.0.0.2
10.0.0.3Slide9
Sequential Composition [new!]
9
Controller Platform
Routing
Load Balancer
>>
dstip
= 10.0.0.1
fwd
(1)
dstip
= 10.0.0.2
fwd
(2
)
s
rcip
= 0*,
dstip
=1.2.3.4
dstip
=10.0.0.1
s
rcip
= 1*,
dstip
=1.2.3.4
dstip
=10.0.0.2
s
rcip
= 0*,
dstip
= 1.2.3.4
dstip
= 10.0.0.1,
fwd
(1)
srcip
= 1*,
dstip
= 1.2.3.4
dstip
= 10.0.0.2,
fwd
(2
)Slide10
Sequential Composition: Gateway
10
Left:
learning switch on MAC addresses
Middle:
ARP on gateway, plus simple repeater
Right:
shortest-path forwarding on IP prefixes
IP Core
Ethernet
IP Core
Gateway
EthernetSlide11
Dividing the Traffic Over Modules
PredicatesSpecify which traffic traverses which modulesBased on input port and packet-header fields11
Routing
Load Balancer
Monitor
Routing
d
stport
!= 80
d
stport
= 80
>>
+Slide12
High-Level Architecture
12
Controller Platform
M1
M2
M3
Composition SpecSlide13
Partially Specifying Functionality
A module should not specify everythingLeave some flexibility to other modulesAvoid tying the module to a specific settingExample: load balancer plus routingLoad balancer spreads traffic over replicas
… without regard to the network paths
13
Load Balancer
Routing
>>Slide14
Avoid Custom Interfaces
Each module generates a partial specWhat it needs to see and controlWhat it can leave unspecifiedUnwieldy solution
New syntax and work for the programmer
Complex interaction between modules
Enforcement of “contract” by the controller
14
Load Balancer
Routing
“I modify
dstip
but don’t need to pick the path”Slide15
Abstract Topology Views
Present abstract topology to the moduleConcise: implicitly encodes the constraints General: can represent a variety of constraintsIntuitive: looks just like a normal networkSafe: prevents the module from overstepping
15
15
Real network
Abstract viewSlide16
Separation of ConcernsHide irrelevant details
Load balancer doesn’t see the internal topology or any routing changes16
Routing view
Load-balancer viewSlide17
High-Level Architecture
17
Controller Platform
View Definitions
M1
M2
M3
Composition SpecSlide18
Implementation Alternatives
Option #1: virtualize the OpenFlow APIMany API calls, few high-level constructsModules map between topology viewsNested virtualization becomes expensiveOption #2: language-based solution
High-level core language for writing modules
High-level specification of network views
Compiler performs syntactic transformations
18Slide19
Supporting Topology Views
Virtual ports(V, 1): [(P1,2)](V, 2): [(P2, 5)]Simple firewall policyin=1 out=2
Virtual headers
Push virtual ports
Route on these ports
From (P1,2) to (P2,5)
19
V
1
2
firewall
routing
P1
P2
1
1
2
2
3
3
4
4
5Slide20
Conclusions
Modularity is crucialEase of writing, testing, and debuggingSeparation of concerns, code reuse, portabilityLanguage abstractionsParallel and sequential composition
Abstract topology views
Virtual packet headers
Ongoing work
Prototype system and more applicationsRicher data-plane models (e.g.,
OpenFlow 1.3)20Slide21
Frenetic Project
http://frenetic-lang.org
Programming languages meets networking
Cornell:
Nate Foster, Gun
Sirer
,
Arjun
Guha, Robert Soule, Shrutarshi Basu, Mark
Reitblatt, Alec StoryPrinceton: Dave Walker, Jen Rexford, Josh Reich, Rob Harrison, Chris Monsanto, Cole Schlesinger, Praveen Katta, Nayden
NedevShort overview at http://www.cs.princeton.edu/~
jrex/papers/frenetic12.pdf