Consistent Updates in Software-De!ned Networks

43

Transcript of Consistent Updates in Software-De!ned Networks

Page 3: Consistent Updates in Software-De!ned Networks

Consistent Updates in Software-De!ned Networks

Nate Foster Mark Reitblatt

Cole SchlesingerJennifer Rexford

David Walker

Page 4: Consistent Updates in Software-De!ned Networks

Network Updates

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Network Updates• Routine maintenance• Unexpected failures• Traffic engineering• Updated ACL

Page 5: Consistent Updates in Software-De!ned Networks

Network Updates

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Desired Invariants• No lost packets• No broken connections • No forwarding loops• No security holes

Network Updates• Routine maintenance• Unexpected failures• Traffic engineering• Updated ACL

Page 6: Consistent Updates in Software-De!ned Networks

At 12:47 AM PDT on April 21st, a network change was performed as part of our normal scaling activities...

During the change, one of the steps is to shift traffic off of one of the redundant routers...

The traffic shift was executed incorrectly and the traffic was routed onto the lower capacity redundant network.

This led to a “re-mirroring storm”...

During this re-mirroring storm, the volume of connection attempts was extremely high and nodes began to fail, resulting in more volumes left needing to re-mirror. This added more requests to the re-mirroring storm...

The trigger for this event was a network configuration change.

Page 7: Consistent Updates in Software-De!ned Networks

At 12:47 AM PDT on April 21st, a network change was performed as part of our normal scaling activities...

During the change, one of the steps is to shift traffic off of one of the redundant routers...

The traffic shift was executed incorrectly and the traffic was routed onto the lower capacity redundant network.

This led to a “re-mirroring storm”...

During this re-mirroring storm, the volume of connection attempts was extremely high and nodes began to fail, resulting in more volumes left needing to re-mirror. This added more requests to the re-mirroring storm...

The trigger for this event was a network configuration change.

Page 8: Consistent Updates in Software-De!ned Networks

Prior Work

Page 9: Consistent Updates in Software-De!ned Networks

Prior Work

Page 10: Consistent Updates in Software-De!ned Networks

Prior Work

Page 11: Consistent Updates in Software-De!ned Networks

Prior Work

Page 12: Consistent Updates in Software-De!ned Networks

Prior Work

Page 13: Consistent Updates in Software-De!ned Networks

Prior Work

Page 14: Consistent Updates in Software-De!ned Networks

Prior Work

Page 15: Consistent Updates in Software-De!ned Networks

Prior Work

Page 16: Consistent Updates in Software-De!ned Networks

Prior Work

Page 17: Consistent Updates in Software-De!ned Networks

Prior Work

Page 18: Consistent Updates in Software-De!ned Networks

Controller

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Software Abstractions

Page 19: Consistent Updates in Software-De!ned Networks

Controller

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Software Abstractions

PL Abstractions

By designing the right software abstractions, we can solve the network update problem once and for all!

Page 20: Consistent Updates in Software-De!ned Networks

Controller

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Software Abstractions

PL Abstractions

Discovery

Monitoring

Routing

By designing the right software abstractions, we can solve the network update problem once and for all!

Page 21: Consistent Updates in Software-De!ned Networks

OpenFlow Switch

Example: Distributed Access Control

Controller

Application

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

F2

F3

Src Traffic ActionWeb Allow

Non-web DropAny Allow

Security Policy

F1

I

Traffic

Page 22: Consistent Updates in Software-De!ned Networks

OpenFlow Switch

Example: Distributed Access Control

Controller

Application

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

F2

F3

Src Traffic ActionWeb Allow

Non-web DropAny Allow

Security Policy

Con"guration AProcess black-hat traffic on F1

Process white-hat traffic on {F2,F3}

F1

I

Traffic

Page 23: Consistent Updates in Software-De!ned Networks

OpenFlow Switch

Example: Distributed Access Control

Controller

Application

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

F2

F3

Src Traffic ActionWeb Allow

Non-web DropAny Allow

Security Policy

Con"guration AProcess black-hat traffic on F1

Process white-hat traffic on {F2,F3}

F1

I

Traffic

Page 24: Consistent Updates in Software-De!ned Networks

OpenFlow Switch

Example: Distributed Access Control

Controller

Application

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

F2

F3

Src Traffic ActionWeb Allow

Non-web DropAny Allow

Security Policy

Con"guration AProcess black-hat traffic on F1

Process white-hat traffic on {F2,F3}

Con"guration BProcess black-hat traffic on {F1,F2}

Process white-hat traffic on F3

?

F1

I

Traffic

Page 25: Consistent Updates in Software-De!ned Networks

Abstractions for Network Update

Challenge•The network is a distributed system•Can only update one element at a time

Our Approach•Provide programmers with constructs for

updating the entire network at once

•Design semantics to ensure “reasonable” behavior •Engineer efficient implementation mechanisms

- Compiler constructs low-level update protocols- Automatically applies optimizations

update(config,  topo)

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Page 26: Consistent Updates in Software-De!ned Networks

Consistent Updates in Action

#  Configuration  AI_configA  =  [Rule({IN_PORT:1},[forward(5)]),                          Rule({IN_PORT:2},[forward(5)]),                          Rule({IN_PORT:3},[forward(6)]),                          Rule({IN_PORT:4},[forward(7)])])F1_configA  =  [Rule({TP_DST:80},  [forward(2)]),                            Rule({TP_DST:22},  [])])F2_configA  =  [Rule({},[forward(2)])]F3_configA  =  [Rule({},[forward(2)])]configA  =  {I:SwitchConfiguration(I_configA),                      F1:SwitchConfiguration(F1_configA),                      F2:SwitchConfiguration(F2_configA),                      F3:SwitchConfiguration(F3_configA)}

#  Configuration  BI_configB  =  [Rule({IN_PORT:1},[forward(5)]),                          Rule({IN_PORT:2},[forward(6)]),                          Rule({IN_PORT:3},[forward(7)]),                          Rule({IN_PORT:4},[forward(7)])])F1_configB  =  [Rule({TP_DST:80},  [forward(2)]),                            Rule({TP_DST:22},  [])])F2_configB  =  [Rule({TP_DST:80},  [forward(2)]),                            Rule({TP_DST:22},  [])])F3_configB  =  [Rule({},[forward(2)])]configB  =  {I:SwitchConfiguration(I_configB),                      F1:SwitchConfiguration(F1_configB),                      F2:SwitchConfiguration(F2_configB),                      F3:SwitchConfiguration(F3_configB)}

#  Main  Functiontopo  =  Topo(...)update(configA,  topo)...wait  for  traffic  load  to  shift...update(configB,  topo)

Src Traffic ActionWeb Allow

Non-web DropAny Allow

Security Policy

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Page 27: Consistent Updates in Software-De!ned Networks

Semantics of Network Updates

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Atomic Updates• Seem sensible...• but costly to implement• and difficult to reason about effects on

packets already in-#ight

Page 28: Consistent Updates in Software-De!ned Networks

Semantics of Network Updates

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Atomic Updates• Seem sensible...• but costly to implement• and difficult to reason about effects on

packets already in-#ight

Per-Packet Consistent UpdatesEvery packet processed with old or new con$guration, but not a mixture of the two

Page 29: Consistent Updates in Software-De!ned Networks

Implementation Mechanisms

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

NOX Controller

Frenetic Run-Time System

Frenetic Application

update(con"g,topo)

Calculate rules,generate messsages

Raw OpenFlowcontrol messages

Two-phase commit• Construct versioned internal and edge

con$gurations• Phase 1: Install internal con$guration• Phase 2: Install edge con$guration

Pure Extension• Update strictly adds paths

Pure Retraction • Update strictly removes paths

Slice Update• Update affects a small number of switches

Page 30: Consistent Updates in Software-De!ned Networks

(Ask me for a demo!)

Page 31: Consistent Updates in Software-De!ned Networks

(Ask me for a demo!)

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Page 32: Consistent Updates in Software-De!ned Networks

(Ask me for a demo!)

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Page 33: Consistent Updates in Software-De!ned Networks

Formal Veri!cation

GlobalCon"g

Packet Queue

Update

hC,Qi u�! hC 0, Q0i

Page 34: Consistent Updates in Software-De!ned Networks

Theorem

An update u C1 to C2 is per-packet consistent if and only if it preserves all properties satis$ed by C1 and C2.

Formal Veri!cation

GlobalCon"g

Packet Queue

Update

hC,Qi u�! hC 0, Q0i

Page 35: Consistent Updates in Software-De!ned Networks

Theorem

An update u C1 to C2 is per-packet consistent if and only if it preserves all properties satis$ed by C1 and C2.

Formal Veri!cation

GlobalCon"g

Packet Queue

Update

hC,Qi u�! hC 0, Q0i

Veri"ed

Page 36: Consistent Updates in Software-De!ned Networks

Formal Veri!cation

CorollaryTo verify that a property is invariant, simply check that the old and new con$gurations satisfy it

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Page 37: Consistent Updates in Software-De!ned Networks

Formal Veri!cation

CorollaryTo verify that a property is invariant, simply check that the old and new con$gurations satisfy it

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Kripke Structure

Page 38: Consistent Updates in Software-De!ned Networks

Formal Veri!cation

CorollaryTo verify that a property is invariant, simply check that the old and new con$gurations satisfy it

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Model Checker

Kripke Structure

CTL Property

Page 39: Consistent Updates in Software-De!ned Networks

Formal Veri!cation

CorollaryTo verify that a property is invariant, simply check that the old and new con$gurations satisfy it

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Model Checker ✓

Kripke Structure

CTL Property✘

Page 40: Consistent Updates in Software-De!ned Networks

Formal Veri!cation

CorollaryTo verify that a property is invariant, simply check that the old and new con$gurations satisfy it

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Model Checker ✓

Kripke Structure

CTL Property

Properties• Connectivity• Loop freedom• Blackhole freedom• Access control• Waypointing• Totality

Page 41: Consistent Updates in Software-De!ned Networks

Per-Flow Consistency

Use Cases• Load balancer• Flow affinity• In-order delivery

Per-#ow consistent updatesEvery set of related packets processed with old or new con$guration, but not a mixture of the two.

Implementation mechanisms• Need to identify active #ows• Rules with soft timeouts• DevoFlow wildcard cloning• End-host feedback

OpenFlow Switch

OpenFlow Switch

Page 42: Consistent Updates in Software-De!ned Networks

Ongoing Work

Other abstractions• Loop-freedom• Affinity preserving

Update Synthesis• Programmer speci$es an invariant• Compiler constructs an update protocol

Enhanced fault tolerance• Rapid response when failures occur• Compiler “hardens” con$gurations• Pre-loads backup policy

Leverage end hosts • Help identify active #ows

Page 43: Consistent Updates in Software-De!ned Networks

Thank You!

CollaboratorsShrutarshi Basu (Cornell)Mike Freedman (Princeton)Rob Harrison (West Point)Chris Monsanto (Princeton)Mark Reitblatt (Cornell)Gün Sirer (Cornell)Cole Schlesinger (Princeton)Alec Story (Cornell)Jen Rexford (Princeton)Dave Walker (Princeton)

Funding

http://frenetic-lang.org