Openflow-based Multipath Switching in the Wild › event › 236955 › contributions › 503578 ›...

Openflow-based Multipath

Switching in the Wild

Dr. Michael Bredel (Caltech)

LHCone Workshop June 18th, 2013

Outline

• Which problems will OpenFlow solve?

• Brief introduction to OpenFlow

• The OLiMPS project

• Load balancing over link-disjoint multiple paths

• Experiments and results

• Application aware networking

• Yet another testbed

• USLHCnet inter-continental OpenFlow testbed

• The missing link

• Software Defined Network OpenFlow controller

• Summary and Outlook

Outline

June 18th, 2013 [email protected]

Software Defined Network and OpenFlow

• Decouples forwarding and control plane

Introduction to SDN and OpenFlow

by Scott Shenker

[email protected] June 18th, 2013

Evolution of networks over the last decades

• The forwarding plane:

Network Evolution (I)


Evolution of networks over the last decades

• The control plane:

Network Evolution (II)

1990 2013

Telnet SSH

by Rob Sherwood


Management interfaces:

• How to manage a large number of switches and routers?

• How do you guarantee persistency, e.g. in ACL’s?

• How do you guarantee traffic separation?

• How does it scale?

In-band traffic control:

• How to optimize traffic flows globally?

• How to minimize convergence time?

• How to obtain deterministic behavior?

• How to use multiple paths?

• How to get rid of Spanning Tree Protocol?

Problems due to the limited control plane

by Rob Sherwood


The OLiMPS project

OpenFlow Link-layer MultiPath Switching


• Multipath is not new, various techniques exist:

• Layer 3: ECMP – Equal Cost Multi-Path

• Layer 2: LAG - Ethernet Link Aggregation Groups

• Layer 1: VCAT – Virtual conCATenation

• Common drawback: None are particularly flexible

• preconfigured

• static hashing algorithms

• limited to single links

• Often vendor specific implementation

• Work on hop-by-hop basis

• difficult to optimize globally

Multipath: old-style approaches


OLiMPS: Openflow Link-layer MultiPath Switching

• with a centralized, out-of-band control, we can construct a

robust multi-path system without modifications to the Layer

2 frame structure

• Big plus: using Openflow, no need for new HW or feature

support (other than Openflow)

• Addresses the problem of topology limitations in large-scale

layer 2 networks

• Remove the necessity of a tree structure in the topology

achieved though the use of Spanning Tree Protocol

• Allow for per-flow multipath switching

• Non-equal paths

• Multiple wide area links

The Approach in OLiMPS


Load balancing provides the decision how to best use pre-

calculated paths

• Random path selection (ECMP-like)

• A new flow is mapped to a randomly selected path

• Hash-based path selection

• Based on source port hashes

• Round robin path selection

• New flows are simply mapped to the next path

• Number-Of-Flows based path selection

• Selects the path that has the least number of flows

already mapped to it

• Application aware path selection

• Takes file sizes into account

Load Balancing - Algorithms


• Application aware networks vs. network aware applications?

• Direct impact on the network-application Interface

• Network aware applications

• Query the network for information

• Site-selection based on connectivity, capacity, available

bandwidth, etc.

• BUT: network state can change → Hard to do

• Application aware networks

• Applications provide additional information to the network

File size, flow match, transfer rate, etc.

• The network decides what to do with this information

Switching/Routing based on application information

Load balancing → better network utilization

Application Awareness


Experiment Setup

• 5 link-disjoint paths

• Equal link characteristics, i.e. 1 Gbps

• Different path characteristics, i.e. the number of hops, delay

Load Balancing – Experiments & Results (I)


Experiment Setup (cont’d)

• 1 to 10 parallel transfers (over 5 link-disjoint paths)

• A single transfer (with multiple files) takes approx. 90 minutes

• Zipf distributed file sizes between 1 and 40 GByte

• Approx. 500 GByte in total

• Exponentially distributed inter-transfer waiting times

• λ = mean(zipf_distributed_file_sizes)/capacity

Load Balancing – Experiments & Results (II)


Results

• Mean transfer time [in minutes] of all files of a transfer over

number of parallel transfers*

Load Balancing – Experiments & Results (III)


*) Total transfer time is between 1.5 and 33 hours per experiment

Results

• Who is suffering?

• Mean transfer time of small, .i.e. 1 Gbyte, flows vs. big, i.e. 40 Gbyte,

flows

Load Balancing – Experiments & Results (IV)


1 GByte 40 GByte

Lessons learned so far:

• Application aware path selection

• Increases the overall network utilization and efficiency

Big flow can benefit

Small flows may suffer (a bit)

• An API that allows for identifying flows is still challenging

• We need to modify the applications (slightly)

• Given a well known, potentially closed, system, say LHCone

+ PhEDEx

• Traffic differentiation, e.g. TCP reverse flows

• Traffic priority, e.g. data vs. control flows

• Monitoring, e.g. application and transfer performance using

flow statistics

Application Awareness


Now the cool stuff

• Easily implement any load distribution algorithm you can

think of

• Take any of the following parameters into account

• Nominal path capacity

• Link utilization (available bandwidth) along the path

• Number of hops

• Latency

• Number of bits to transfer

• Rebalance and move flows based on real-time feedback:

• Topology changes, e.g. link failures

• Global flow optimization

• Congestion notification (maybe – needs detailed study)

The new cool stuff


USLHCNet OpenFlow Testbed


Permanent inter-continental OpenFlow testbed

• Focus on connectivity and control plane

• Fully meshed on the physical layer

• Various link and path

characteristics

• Software Defined Networks

• It is more about software rather than networks

It is NOT configuring an OpenFlow switch

It is NOT connecting OpenFlow ports

• It is about network management and control

We need a full-featured OpenFlow controller!

• Who should write your controller code?

Cisco, Juniper, HP, <put in you favorite vendor>?

Students?

Researchers? A physicist at CERN maybe?

The missing link …


• Floodlight/OLiMPS Controller as a basis

• Configuration management (CLI, Storage)

• High-Availability features

• Testing

Unit tests

Black-box tests

Performance tests

System and integration tests

• Documentation

• Whoever is interested (and knows at least a bit of Java or

Python hacking) is very welcome to participate!

• Students

• Network engineers

The missing link … call for participation


QUESTIONS?

[email protected]

[email protected]


Openflow-based Multipath Switching in the Wild › event › 236955 › contributions › 503578 ›...

Documents

Transcript of Openflow-based Multipath Switching in the Wild › event › 236955 › contributions › 503578 ›...