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!