Beyond the future: a practical approach of Telco changes

Beyond the future: a practical approach of Telco
changes
Walter Cerroni, Chiara Contoli, Francesco Foresta
Alma Mater Studiorum - University of Bologna
Department of Electrical, Electronic and Information Engineering
G. Marconi
Mail: francesco.foresta@unibo.it
May 29, 2015
Research Fellow: Francesco Foresta (DEI) The Telco future: a pratical approach May 29, 2015 1 / 20

Part 3 Overview
1 Why are SDN and NFV so important?
NFV, in detail
Pros and Cons
Prospectives
2 Cloud Management Platforms
Introduction
The OpenStack case
Introduction
Components and abstractions
3 Case study: Dynamic Service Chaining
L2 topology & VNI
Proof-of-concept
4 Live Demo
Web Dashboard & CLI
5 Conclusions

Why are SDN and NFV so important? NFV, in detail
NFV
The application of cloud computing into the edge networks brings to
the birth of NFV paradigm
It happened because the old paradigm based on IP forwarding has been
modiﬁed through the years
packets are processed in intermediate nodes called middle-boxes which
implements supplementary functions (as NAT, Firewall, Load
Balancers. . . )

NFV
Balancers. . . )
Middle-boxes are hardware, expensive, non-reprogrammable and
non-open devices
Vendor lock-in problem: clients are dependant from providers
Internet ossiﬁcation: it is diﬃcult to create new services

NFV
Balancers. . . )
Middle-boxes are hardware, expensive, non-reprogrammable and
non-open devices
Vendor lock-in problem: clients are dependant from providers
Internet ossification: it is difficult to create new services
In order to resolve these problems, an ETSI commission wrote down
the basics on NFV approach: middle-boxes need to be simplified,
virtualizing network functions on a general purpose hardware
In this scenario, SDN gives the needed high level of dinamicity

Why are SDN and NFV so important? Pros and Cons
Other reasons behind this combined approach
From many years to now computer scientist are able to implement
complex systems without the need of managing every single device
involved in the project neither using machine language
Possible thanks to the introduction of Open interfaces and
abstractions layers in the architecture

Other reasons behind this combined approach
From many years to now computer scientist are able to implement
complex systems without the need of managing every single device
involved in the project neither using machine language
Possible thanks to the introduction of Open interfaces and
abstractions layers in the architecture
SDN and NFV are providing a similar evolution chance as it happened
for computing
They can revolutionise the Telecommunications world, both
provider-side and user-side eradicating the well-known problems
(vendor lock-in, Internet ossiﬁcation. . . )
Their co-operation with cloud computing services created a new way of
thinking in the Telco area

SDN and NFV co-operation

Advantages & Disadvantages of NFV and SDN
+ Network cost reductions in hardware

+ New business opportunities

+ Removed vendor lock-in problem

+ Multi tenancy (more users isolated on the same hardware resources)

+ Added ﬂexibility in network functions and dynamism

+ High scalability

+ High scalability
− Possible loss of performance as the hardware moves from specialized
to homogeneous
+ Likely only short term because of expected high innovation in software

Cloud Management Platforms Introduction
What are Cloud Managing Platforms?
The cloud computing paradigm points out that network resources,
storage and computing are oﬀered from a provider to a client as a
service
As it already is for water, gas, electricity, telephone. . .

service
A cloud platform is a cluster of physical machines which contains
some servers that will be oﬀered as a service to a client, in according
to the IaaS (Infrastructure-as-a-Service) paradigm
It has to be managed ⇒ Cloud management platform

service
A cloud platform is a cluster of physical machines which contains
some servers that will be oﬀered as a service to a client, in according
to the IaaS (Infrastructure-as-a-Service) paradigm
It has to be managed ⇒ Cloud management platform
This is an integrated product that provide for the management of
public, private and hybrid cloud environments
Many platforms have been developed during these years, e.g. Amazon
Web Services, Google Cloud Platform, HP Cloud, Microsoft Azure,
Nebula, Rackspace Cloud, OpenStack. . .

Cloud Management Platforms The OpenStack case
OpenStack
It’s an Open Source joint project of Rackspace Cloud and NASA,
assisted by more than 200 companies from the IT industry

OpenStack
It’s an Open Source joint project of Rackspace Cloud and NASA,
assisted by more than 200 companies from the IT industry
Once installed on a distributed system, users can create a virtual
network infrastructure (VNI) composed of instances (e.g.
implemented as virtual machines) and networks appliances (routers,
ﬁrewalls, etc) in a simple and eﬃcient way, taking advantages of
multi-tenancy

OpenStack Components
OpenStack is composed of various components: each of them works
in a speciﬁc area
Nova = compute, Neutron = networking, Keystone = credentials,
Glance = image storaging, Horizon = Web dashboard. . .

OpenStack Components
OpenStack is composed of various components: each of them works
in a speciﬁc area
Nova = compute, Neutron = networking, Keystone = credentials,
Glance = image storaging, Horizon = Web dashboard. . .
Neutron deﬁnes some networks abstractions to make possible to work
in the networking area
a Network is an isolated L2 network segment, a Subnet on that
network is an IP address group, a Port is an attachment point to the
network, while a Router is a gateway between subnets. . .

Web Dashboard

OpenStack minimal cluster
Every OpenStack cluster is composed of at least three physical
servers:
A compute node, where the Virtual Machines are stored
A network node, which provides connectivity for them
A controller node, which manages all user requests

servers:
They contain the OpenStack components and communicate between
them with REST API calls
It means HTTP is used to make calls between machines in a very
simple way

servers:
They contain the OpenStack components and communicate between
them with REST API calls
It means HTTP is used to make calls between machines in a very
simple way
These machines are connected by three networks
Management net, used by the admin to access the cluster nodes and
for interservice communications
External net, which provides the Internet access to the VMs
Data net, used for inter-VM communications
Packets on this net will be VLAN tagged or encapsulated (GRE)

Cluster, in detail

Virtualization
When a user “asks” the controller to create an instance, this one
sends a REST API call to the compute node which will provide it,
installing many components in itself: Linux Bridges, OpenVSwitches
(⇒ SDN), TAP interfaces, Veth pair. . .

Virtualization
When a user “asks” the controller to create an instance, this one
sends a REST API call to the compute node which will provide it,
installing many components in itself: Linux Bridges, OpenVSwitches
(⇒ SDN), TAP interfaces, Veth pair. . .
In the OpenStack environment acts a virtualization software
this hypervisor is used to create the virtual environment which
emulates the physical machine’s behaviour ⇒ a virtual host is running
inside a physical host, at the same time!
it uses Libvirt: this is a generic API that supports various virtualization
backends (VirtualBox, VMWare, XEN, QEMU+KVM) and allows the
managing and migration of the VMs ⇒ NFV

Inside the nodes

Case study: Dynamic Service Chaining L2 topology & VNI
Case study: L2 topology & VNI

Case study: Dynamic Service Chaining Proof-of-concept
Results
At the source
1
10
100
1000
0 50 100 150 200 250 300 350 400 450
Throughput(Mbit/s)
Time (s)
DPI-in (p3)
WANA1-in (p4)
WANA1-out (p5)
TC-in (p6)
TC-out (p7)

Case study: Dynamic Service Chaining Proof-of-concept
Results
At the source
1
10
100
1000
0 50 100 150 200 250 300 350 400 450
Throughput(Mbit/s)
Time (s)
DPI-in (p3)
WANA1-in (p4)
WANA1-out (p5)
TC-in (p6)
TC-out (p7)
At the destination

Live Demo Web Dashboard & CLI
Live demo: what we are going to do
First of all, we are seeing how it looks like the dashboard

Here we are going to create a ﬁrst Ubuntu VM called
“francescoforestavm”

After that, we will have a look on the Command Line Interface

Here we are going to create a second Fedora VM called
“waltercerronivm”

Finally, we are entering with ssh into those VMs (these are Linux PCs
at all, but without a dedicated hardware!) and ping each other and
on the outside (e.g. google.com) ⇒ they have connectivity!

Finally, we are entering with ssh into those VMs (these are Linux PCs
at all, but without a dedicated hardware!) and ping each other and
on the outside (e.g. google.com) ⇒ they have connectivity!
Isn’t it cool?
Think about doing the same thing with a entire virtual network and
all the middle-boxes which it brings with!

Conclusions
Next achievements
More context awareness ⇒ we will use an orchestrator to install
more dinamically ﬂows in the OVSs

Conclusions
Next achievements
Experiments with VMs live migration

Conclusions
Next achievements
Generalization of the case study, making the whole thing more
automatic

Conclusions
Next achievements
automatic
Use of new OpenFlow controllers (OpenDayLight, Ryu) carrying new
OpenFlow versions

Conclusions
Next achievements
automatic
OpenFlow versions
Cloud perfomances tests

Conclusions
Next achievements
automatic
OpenFlow versions
Cloud perfomances tests
Application of Virtual Tenant Network: a way to create virtual
networks in a complete automated way, using REST API calls

Conclusions
Questions?
Do you have any questions?
. . . I hope not in this way!

Conclusions
And that is all!
Thanks for your attention!

Beyond the future: a practical approach of Telco changes

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Beyond the future: a practical approach of Telco changes

Similar to Beyond the future: a practical approach of Telco changes (20)

Recently uploaded

Recently uploaded (20)

Beyond the future: a practical approach of Telco changes