improving flexibility, manageability in intra-compunet/www/docs/gabriele/lospoto-gabriele... · the...

Improving flexibility,

provisioning and

manageability in intra-

domain networks

PhD Dissertation – 20th June 2016

AdvisorProf. Giuseppe Di Battista

PhD Student

Gabriele Lospoto ∘ XXVIII Cycle

Context

In today's computer networks, many network protocols co-exist in order to provide services.

Provisioningproblems

Flexibility problems

Manageabilityproblems

Gabriele Lospoto ∘ PhD Dissertation ∘ 2

Context

Network protocols are typically based on two complementary approaches

Distributed Centralized

Gabriele Lospoto ∘ PhD Dissertation ∘ 3

Distributed Approach

Each network device is equipped with both control and data plane

Control plane

Data plane

Gabriele Lospoto ∘ PhD Dissertation ∘ 4

Centralized Approach

Each network device is equipped with the data plane; control plane is moved in a dedicated

hardware

Control planeData plane

The communication between Controller and Network device is realized using an ad-hoc protocol

Controller

Gabriele Lospoto ∘ PhD Dissertation ∘ 5

Software-Defined Networking

Software-Defined Networking (SDN) is an emerging architecture based on the centralized approach

SDN is very promising and it is collecting the attention of the whole computer networks research community

OpenFlow is the most used protocol enabling SDN in the real worldThe OpenFlow paper has been cited 4304 times (since

2008)!Gabriele Lospoto ∘ PhD Dissertation ∘ 6

OpenFlow vs Traditional Protocols

OpenFlow Traditional

Approach Centralized Distributed

Interaction Coding Configuration

Flexibility High Medium/Low

Provisioning High Low

Manageability High Medium/Low

Gabriele Lospoto ∘ PhD Dissertation ∘ 7

Preliminaries

AutonomousSystem (AS) Interior Gateway

Protocol (IGP)

Exterior Gateway Protocol (EGP)

Gabriele Lospoto ∘ PhD Dissertation ∘ 8

Challenges

Improving

Flexibility

Improving

Provisioning

Improving

Manageability

Gabriele Lospoto ∘ PhD Dissertation ∘ 9

Challenges

Improving

Flexibility

Improving

Provisioning

Improving

Manageability

Centralized

Distributed

Gabriele Lospoto ∘ PhD Dissertation ∘ 10

Challenges

Improving

Flexibility

Improving

Provisioning

Improving

Manageability

Centralized

Distributed

Centralized

Distributed

Gabriele Lospoto ∘ PhD Dissertation ∘ 11

Challenges

Improving

Flexibility

Improving

Provisioning

Improving

Manageability

Centralized

DistributedCentralized

Centralized

Distributed

Gabriele Lospoto ∘ PhD Dissertation ∘ 12

Contributions

Improving

Flexibility

Improving

Provisioning

Improving

Manageability

Centralized

DistributedCentralized

Centralized

Distributed

Four contributions in order to improveFlexibility, Provisioning and Manageability

Gabriele Lospoto ∘ PhD Dissertation ∘ 13

First Contribution

Improving

Flexibility

Improving

Provisioning

Improving

Manageability

Centralized

DistributedCentralized

Centralized

Distributed

A control plane for a new intra-domain routing protocol

Gabriele Lospoto ∘ PhD Dissertation ∘ 14

Second Contribution

Improving

Flexibility

Improving

Provisioning

Improving

Manageability

Centralized

DistributedCentralized

Centralized

Distributed

A new language for the setup of advanced services (e.g., VPNs)

Gabriele Lospoto ∘ PhD Dissertation ∘ 15

Third Contribution

Improving

Flexibility

Improving

Provisioning

Improving

Manageability

Centralized

DistributedCentralized

Centralized

Distributed

A mechanism to guarantee interoperability in the network

Gabriele Lospoto ∘ PhD Dissertation ∘ 16

Fourth Contribution

Improving

Flexibility

Improving

Provisioning

Improving

Manageability

Centralized

DistributedCentralized

Centralized

Distributed

An investigation on the readiness of the real devices for the centralized approaches

Gabriele Lospoto ∘ PhD Dissertation ∘ 17

First contribution

A control plane for a new

intra-domain routing

protocol

Motivations

An Internet Service Provider (ISP) wants● Fine-grained control of paths● Support for routing policies● Simplified network management

○ Also reducing configuration effort

● Fast recovery● Reduced impact of network changes

These goals can be reached using different approaches, like multipath and source routing

Gabriele Lospoto ∘ PhD Dissertation ∘ 19

State of the Art

Addressed issues:● Fault tolerance: Pathlet routing [Godfrey et

al., 2009], Path splicing [Motiwala et al., 2008], NIRA [Yang et al., 2007], BGP Add-paths [Van den Schrieck et al., 2010], Slick packets [Nguyen et al., 2011], YAMR [Ganichev et al., 2010]

● QoS satisfaction: RSVP [Braden et al., 1997], HDP [El-Darieby et al., 2002]

Gabriele Lospoto ∘ PhD Dissertation ∘ 20

State of the Art

Addressed issues:● Support for routing policies: HLP

[Subramanian et al., 2005], MIRO [Xu et al., 2006]

● Scalability: Landmark [Tsuchiya, 1988], ALVA [Behrens et al., 1998], Macro-routing [Dragos et al., 2004]

Gabriele Lospoto ∘ PhD Dissertation ∘ 21

Approaches

The approaches used by those contributions● Multipath, source routing, hierarchical

routing, mixed link state and path vectorrouting

Gabriele Lospoto ∘ PhD Dissertation ∘ 22

Approaches and Challenges

Multipath

Recovery Control

Source Routing

Increase traffic control!!!

Hierarchical Routing and mixed Link-State/Path-Vector

approaches

Gabriele Lospoto ∘ PhD Dissertation ∘ 23

Pathlet Routing

Our control plane is distributed and it relies on Pathlet Routing

Pathlet Routing is source routing and multipath, but there is not a control plane for it

vnode

fid

pathlet

Gabriele Lospoto ∘ PhD Dissertation ∘ 24

Our Control Plane

We made Pathlet suitable for the intra-domain routing, using

● Hierarchical network model○ All network devices are grouped into areas

● Multipath

● Source routing

As result, we improve

Scalability ∘ Resiliency ∘ Control of routing paths

Gabriele Lospoto ∘ PhD Dissertation ∘ 25

Relevant Results

Scalability

Gabriele Lospoto ∘ PhD Dissertation ∘ 26

Relevant Results

Scalability

Gabriele Lospoto ∘ PhD Dissertation ∘ 27

Relevant Results

Performance

Network size: 80 routers

580 Links 680 Links

OSPF 664 ms 699 ms

Our control plane

259 ms 273 ms

Gabriele Lospoto ∘ PhD Dissertation ∘ 28

Second contribution

A new language for the setup

of advanced services

Context

Has a single protocol (OpenFlow) the same power of many protocols?

Starting from a well known and defined service, namely Virtual Private Network (VPN), a

rethinking activity was made, aiming to provide - at least - the same features of that service only using OpenFlow, simplifying the protocol stack

and the configuration effort

Gabriele Lospoto ∘ PhD Dissertation ∘ 30

Virtual Private Networks in briefV

PN

2

VP

N1

ISP’s network

Customer 1

Customer 1

Customer 2

Customer 2

Gabriele Lospoto ∘ PhD Dissertation ∘ 31

VPNs: Problems

Setting up a Virtual Private Network (VPN) is not trivialCoexistence of many protocols

Routing, signaling, traffic engineering, forwarding …

Being flexible is not simpleInteraction with configuration parameters

Configuration managementConfiguration is scattered among all devices in the

network

Troubleshooting is hard, due to protocols used and distributed approach

Gabriele Lospoto ∘ PhD Dissertation ∘ 32

Contribution

Exploiting the centralized approach of SDN, we propose a new configuration language

Setup and management of VPNs are simplifiedConfiguration is now centralizedOnly one protocol is used: OpenFlow

Being able to program the network, flexibility is also improved

Gabriele Lospoto ∘ PhD Dissertation ∘ 33

Today VPNs

VP

N2

VP

N1

Gabriele Lospoto ∘ PhD Dissertation ∘ 34

SDN VPNs

VPNs specification file

SDN Controller

OpenFlow protocol

VP

N2

VP

N1

Gabriele Lospoto ∘ PhD Dissertation ∘ 35

Results

We tested our implementation into a simulation environment

Our VPN SDN-based implementation has the same features of the traditional VPNsOur controller installs all rules in at 0.8 sec

Our controller well react to network dynamicLinks/nodes failures

At most 0.3 sec paths recomputation after a failure

Gabriele Lospoto ∘ PhD Dissertation ∘ 36

Third contribution

A mechanism to guarantee

interoperability in the

network

Context

Studying VPNs, we demonstrated that OpenFlow can replace many protocols

Today networks strongly relies on Address Resolution Protocol (ARP)

A mechanism to guarantee interoperability is needed

Gabriele Lospoto ∘ PhD Dissertation ∘ 38

Motivations

Handling ARP traffic is not so trivial in SDN, because the number of rules on board each

datapath would be unacceptable

We propose an approach for a smart and efficient handling of ARP traffic in the network

Gabriele Lospoto ∘ PhD Dissertation ∘ 39

Scenario

10.10.10.0/24 10.10.20.0/24

Gabriele Lospoto ∘ PhD Dissertation ∘ 40

ARP in Today’s Networks

10.10.10.254 10.10.20.254

H1 H2

10.10.10.1 10.10.20.1

Gabriele Lospoto ∘ PhD Dissertation ∘ 41

ARP in Today’s Networks

10.10.10.254 10.10.20.254

H1 H2

10.10.10.1 10.10.20.1

Gabriele Lospoto ∘ PhD Dissertation ∘ 42

ARP in Today’s Networks

10.10.10.254 10.10.20.254

H1 H2

10.10.10.1 10.10.20.1

Gabriele Lospoto ∘ PhD Dissertation ∘ 43

Contribution

We defined a modular architecture for a controller being able to handle ARP traffic

Interoperability with end-systems is guaranteed

ARP traffic is confined to the edge of the network

Gabriele Lospoto ∘ PhD Dissertation ∘ 44

An Example

10.10.10.254 10.10.20.254

H1 H2

10.10.10.1 10.10.20.1

S1 S2

SDN Controller

Gabriele Lospoto ∘ PhD Dissertation ∘ 45

An Example

10.10.10.254 10.10.20.254

H1 H2

10.10.10.1 10.10.20.1

S1 S2

SDN Controller

Gabriele Lospoto ∘ PhD Dissertation ∘ 46

An Example

10.10.10.254 10.10.20.254

H1 H2

10.10.10.1 10.10.20.1

S1 S2

SDN Controller

Gabriele Lospoto ∘ PhD Dissertation ∘ 47

Results

We tested our controller using three real network devices

Our experiments showed that real devices are able to handle ARP accordingly with our methodology

We also checked that all ARP caches were correctly populated

Gabriele Lospoto ∘ PhD Dissertation ∘ 48

Fourth contribution

An investigation on the

readiness of the real devices

for the centralized

approaches

Motivations

The first OpenFlow (1.0.0) standard was released at the end of 2009

The last OpenFlow standard is 1.5.1, released on April 2015

Which is the network devices’ level of compliance after 6 years?

Is the SDN scientific literature applicable on top of real devices?

Gabriele Lospoto ∘ PhD Dissertation ∘ 50

Contribution

We reviewed the most relevant SDN literature, investigating the applicability of different

proposals using real network devices

We also investigated functionality features of those devices and we measured some

performance parameters

We conducted experiments taking advantage from existing suite test (Ryu suite test) and

writing ad-hoc test classes

Gabriele Lospoto ∘ PhD Dissertation ∘ 51

Results

We tested devices of 7 different vendors, all compliant with OpenFlow 1.3

We observed surprising results, almost unexpected...

Gabriele Lospoto ∘ PhD Dissertation ∘ 52

Results

Gabriele Lospoto ∘ PhD Dissertation ∘ 53

Results

Gabriele Lospoto ∘ PhD Dissertation ∘ 54

Results

Gabriele Lospoto ∘ PhD Dissertation ∘ 55

Observations

Four classes of problems

Constraints on the structure of flow entries

Flow table capacity restrictions

Erroneous and inconsistent behaviors

Unsopported functions

Gabriele Lospoto ∘ PhD Dissertation ∘ 56

Conclusions and future works

Conclusions

Improving flexibility, provisioning and manageability is feasibleBoth centralized and distributed approach can be used

Centralized approach offers more degrees of freedomCoding is better than configuring

However, its adoption is still braked by some real network devices

Gabriele Lospoto ∘ PhD Dissertation ∘ 58

Future Works

Is there some objective criteria for establishing if SDN is better than traditional approach?

Given a set of services (e.g., Traffic Engineering, VPN, firewalling, middleboxing, ... ), different implementations are possible (e.g., traditional

approaches, SDN, or research proposals)

Gabriele Lospoto ∘ PhD Dissertation ∘ 59

Future Works

Is there some objective criteria for establishing if SDN is better than traditional approach?

Given a set of services (e.g., Traffic Engineering, VPN, firewalling, middleboxing, ... ), different implementations are possible (e.g., traditional

approaches, SDN, or research proposals)

Is there an implementation that performs better/worse than the others?

Gabriele Lospoto ∘ PhD Dissertation ∘ 60

Future Works

Is there some objective criteria for establishing if SDN is better than traditional approach?

Given a set of services (e.g., Traffic Engineering, VPN, firewalling, middleboxing, ... ), different implementations are possible (e.g., traditional

approaches, SDN, or research proposals)

Which is the impact of contingent factors, like the specific network topology or the

specific service?

Gabriele Lospoto ∘ PhD Dissertation ∘ 61

Future Works

Is there some objective criteria for establishing if SDN is better than traditional approach?

Given a set of services (e.g., Traffic Engineering, VPN, firewalling, middleboxing, ... ), different implementations are possible (e.g., traditional

approaches, SDN, or research proposals)

Can we even help operators to understand how costly is to implement a

new service while sticking to a given architecture?

Gabriele Lospoto ∘ PhD Dissertation ∘ 62

Future Works

Is there some objective criteria for establishing if SDN is better than traditional approach?

We began to study a methodology that compares different implementation of a service based on a set of metrics (e.g. forwarding table

size, state of the control plane, …)

The goal is to implement a framework that automatically gives back results accordingly to

those metrics

Gabriele Lospoto ∘ PhD Dissertation ∘ 63

Thank you!