sdn(++) and interesting use-cases
DESCRIPTION
SDN(++) and Interesting Use-Cases. Lecture 18 Aditya Akella. Two Parts. SDN for L3-L7 services What is different? Why can’t we use SDN/ OpenFlow as is? New use cases Live Network Migration What else?. Toward Software-Defined Middlebox Networking. - PowerPoint PPT PresentationTRANSCRIPT
1
SDN(++) and Interesting Use-Cases
Lecture 18Aditya Akella
2
Two Parts• SDN for L3-L7 services– What is different?– Why can’t we use SDN/OpenFlow as is?
• New use cases– Live Network Migration– What else?
3
Toward Software-Defined Middlebox NetworkingAaron Gember, Prathmesh Prabhu,
Zainab Ghadiyali, Aditya AkellaUniversity of Wisconsin-Madison
4
Middlebox Deployment Models
• Arbitrary middlebox placement• New forms of middlebox deployment
(VMs, ETTM [NSDI 2011], CoMB [NSDI 2012])
5
• Move between software-defined data centers
• Existing VM and network migration methods– Unsuitable for changing underlying substrate
Live Data Center Migration
Data Center A Data Center B
Programmatic control over middlebox state
6
• Add or remove middlebox VMs based on load
• Clone VM (logic, policy, and internal state)– Unsuitable for scaling down or some scaling up
Middlebox Scaling
Fine-grained control
7
Our Contributions• Classify middlebox state, and discuss what
should be controlled
• Abstractions and interfaces– Representing state– Manipulating where state resides– Announcing state-related events
• Control logic design sketches
8
Controller
Middlebox
App App
Middlebox
SDN-like Middleboxes
IPS
Software-Defined Middlebox Networking
Today
9
Controller
Key Issues
Middlebox
1. How is the logic divided?
2. Where is state manipulated?
3. What interfaces
are exposed?
App App
Middlebox
10
• Configuration input
Middlebox State
State: ESTABSeq #: 3423
Server: BCPU: 50%
Hash: 34225Content: ABCDE
Significant state diversity
+ detailed internal records
Balance Method:Round Robin
Cache size: 100
Src: HostAServer: B
Proto: TCPPort: 22
11
Balance Method:Round Robin
Cache size: 100
Src: HostAServer: B
Proto: TCPPort: 22
Classification of State
State: ESTABSeq #: 3423
Server: BCPU: 50%
Hash: 34225Content: ABCDE
Action Supporting Tuning
Internal & dynamic Many forms
Only affects performance,
not correctness
12
PolicyLanguage
Src: HostAServer: B
Proto: TCPPort: 22
State: ESTABSeq #: 3423
Server: BCPU: 50%
Hash: 34225Content: ABCDE
How to Represent State?
Unknown structure
Significant diversity
May be shared
Per flow
SharedCommonality among middlebox operations
1000101
1101010
0101001
1111000
1010110
13
State Representation
• Key: protocol header field/value pairs identify traffic subsets to which state applies
• Action: transformation function to change parts of packet to new constants
• Supporting: binary blob
Key Action Supporting
Binary Blob
Field1 = Value1…
FieldN = ValueN
Offset1 → Const1…
OffsetN → ConstN
• Only suitable for per-flow state• Not fully vendor independent
14
Controller
Middlebox
How to Manipulate State?
• Today: only control some state– Constrains flexibility and sophistication
• Manipulate all state at controller– Removes too much functionality from middleboxes
15
State Manipulation
• Control over state placement1. Broad operations interface2. Expose state-related events
Controller
IPS 1 IPS 2 Create and update state
Determine wherestate resides
16
Action
*
KeySrcIP = 10.10.0.0/16DPort = 22
KeySrcIP = 10.10.54.41DstIP = 10.20.1.23SPort = 12983DPort = 22
State = ESTAB
Supporting
Operations Interface
get ( , )FilterSrcIP = 10.10.54.41
add ( , )ActionDROP
KeyDstIP = 10.20.1.0/24
Source Destination Proto Other Action
* 10.20.1.0/24 TCP * DROP
remove( , )Filter…
• Need atomic blocks of operations• Potential for invalid manipulations of state
17
Firewall
Events Interface
• Triggers– Created/updated state– Require state to
complete operation• Contents– Key– Copy of packet?– Copy of new state?
Controller
Balance visibility and overhead
18
Conclusion• Need fine-grained, centralized control over
middlebox state to support rich scenarios• Challenges: state diversity, unknown semantics
get/add/remove ( , )…
ActionOffset1 → Const1
…
KeyField1 = Value1
…
Supporting
Binary Blob
19
Open Questions
• Encoding supporting state/other action state?• Preventing invalid state manipulations?• Exposing events with sufficient detail?• Maintaining operation during state changes? • Designing a variety of control logics?• Providing middlebox fault tolerance?
20
Related Work• Simple Middlebox COntrol protocol [RFC 4540]
• Modeling middleboxes [IEEE Network 2008]
• Stratos – middleboxes in clouds [UW-Madison TR]
• ETTM – middleboxes in hypervisors [NSDI 2011]
• COnsolidated MiddleBoxes [NSDI 2012]
• Efficiently migrating virtual middleboxes [SIGCOMM 2012 Poster]
• LIve Migration of Entire network [HotNets 2012]
Live Migration of an Entire Network (and its Hosts)
Eric Keller, Soudeh Ghorbani, Matthew Caesar, Jennifer Rexford
HotNets 2012
23
Widely supported to help:• Consolidate to save energy• Re-locate to improve performance
Virtual Machine Migration
Hypervisor
Apps
OS
Hypervisor
Apps
OS
Apps
OS
Apps
OS
Apps
OS
Apps
OS
24
Many VMs working together
But Applications Look Like This
25
Networks have increasing amounts of state
And Rely on the Network
Configuration Learned Software-Defined
26
Joint (virtual) host and (virtual) network migration
Ensemble Migration
No re-learning,No re-configuring,No re-calculating
Capitalize on redundancy
27
Some Use Cases
28
• Customer driven – for cost, performance, etc.• Provider driven – offload when too full
1. Moving between cloud providers
29
• Reduce energy consumption(turn off servers, reduce cooling)
2. Moving to smaller set of servers
30
• Migrate ensemble to infrastructure dedicated to testing (special equipment)
3. Troubleshooting
31
Automated migration according to some objectiveand easy manual input
Goal: General Management Tool
Monitoring
Objective
Migration
Ensemble Migration
Automation
manual
32
LIve Migration of Ensembles
Migration Primitives
Migration Orchestration
Tenant Control
LIMENetwork Virtualization
API to operator/ automation
Software-defined networkVirtualized servers
Tenant Control
virtual topology Migration is transparent
33
Why Transparent?
34
Separate Out FunctionalityTenant Control
Network Virtualization
Tenant Control
virtual topology
35
Separate Out Functionality
Migration Primitives
Migration Orchestration
Tenant Control
Network Virtualization
Tenant Control
virtual topology
36
Multi-tenancy
Migration Primitives
Migration Orchestration
Tenant Control
Network Virtualization
Tenant Control
virtual topology
InfrastructureOperator
Tenants
37
Can we base it off of VM migration?• Iteratively copy state• Freeze VM• Copy last delta of state• Un-freeze VM on new server
How to Live Migrate an Ensemble
38
Applying to Ensemble
Iterative copy
39
Applying to Ensemble
Freeze and copy
40
Applying to Ensemble
Resume
41
Applying to Ensemble
Resume
Complex to implementDowntime potentially large
42
Applying to Whole Network
Iterative copy
43
Applying to Whole Network
Freeze and copy
44
Applying to Whole Network
Resume
45
Applying to Whole Network
Resume
Lots of packet lossLots of “backhaul” traffic
46
Applying to Each Switch
Iterative copy
47
Applying to Each Switch
Freeze and copy
48
Applying to Each Switch
Resume
49
Applying to Each Switch
Resume
Bursts of packet lossEven more “backhaul” traffic
Long total time
50
• Clone the network• Migrate the VMs individually (or in groups)
A Better Approach
51
Clone the Network
Copystate
52
Clone the Network
Cloned Operation
53
Clone the Network
MigrateVMs
54
Clone the Network
MigrateVMs
55
• Minimizes backhaul traffic• No packet loss associated with the network
(network is always operational)
Clone the Network
56
• Same guarantees as migration-free
• Preserve application semantics
Consistent View of a Switch
Migration Primitives
Migration Orchestration
Network Virtualization
Switch_A_0 Switch_A_1
Switch_A
Application view
Physical reality
57
Sources of Inconsistency
Switch_A_0 Switch_A_1
Apps
OS
Packet 0 Packet 1
R1R2
R1R2
Migration-free: packet 0 and packet 1 traverse same physical switch
VM(end host)
58
1. Local Changes on Switch
Switch_A_0 Switch_A_1
(e.g. delete rule after idle timeout)
Apps
OS
Packet 0 Packet 1
R1R2
R1R2
VM(end host)
59
2. Update from Controller
Switch_A_0 Switch_A_1
Apps
OS
Packet 0 Packet 1
R_newR1R2
R1R2
Install(R_new)
(e.g. rule installed at different times)
VM(end host)
60
3. Events to Controller
Switch_A_0 Switch_A_1
Apps
OS
Packet 0Packet 1
R1R2
R1R2
Packet-in(pkt 0)
Packet-in(pkt 1)(received at controller first)
(e.g. forward and send to controller)
VM(end host)
61
Consistency in LIME
Migration Primitives
Migration Orchestration
Network Virtualization
Switch_A_0 Switch_A_1
Switch_A
*Restrict use of some features* Use a commit protocol
* Emulate HW functions* Combine information
62
• LIME is a general and efficient migration layer• Hope is future SDN is made migration friendly
• Develop models and prove correctness?– end-hosts and network– “Observational equivalence”
• Develop general migration framework– Control over grouping, order, and approach?
Conclusions and Future work