SDN(++) and Interesting Use-Cases

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


Server: BCPU: 50%


Action Supporting Tuning

Internal & dynamic Many forms

Only affects performance,

not correctness

12

PolicyLanguage

Src: HostAServer: B

Proto: TCPPort: 22


Server: BCPU: 50%


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



Tenant Control


Tenant Control

virtual topology

36

Multi-tenancy



Tenant Control


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


Freeze and copy

40


Resume

41


Resume

Complex to implementDowntime potentially large

42

Applying to Whole Network

Iterative copy

43


Freeze and copy

44


Resume

45


Resume

Lots of packet lossLots of “backhaul” traffic

46

Applying to Each Switch

Iterative copy

47


Freeze and copy

48


Resume

49


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




Switch_A_0 Switch_A_1

Switch_A

Application view

Physical reality

57

Sources of Inconsistency


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


(e.g. delete rule after idle timeout)

Apps

OS

Packet 0 Packet 1

R1R2

R1R2

VM(end host)

59

2. Update from Controller


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


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





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

Documents

SDN(++) and Interesting Use-Cases