Introduction to SDNs and NFV

Jorge Bernal Bernabe, PhD.

Department of Information and Communications Engineering,
University of Murcia, Spain

E-mail: [email protected]
Web: https://webs.um.es/jorgebernal
Phone: +34 868884644

1 1
Objectives

• Introduction to main problems of current

Computer Networks
• Introduction to SDN (Software Defined Network)
• Introduction to Network Function Virtualization
(NFV)
• Overview some Southbound Protocols
– OpenFlow, the most extended solution for SDN

2
Problems of Current Networks
• Static Networks
– Not flexible enough, they do not scale properly
• Networks not adapted to current IT trends
– Traffic (Big Data), mobile users, virtualization, Cloud Computing, traffic models :
M2M vs client-server, east-west vs north-south, …
• Vendors dependency
– Based on solutions defined and implemented by device vendors. Lack of open
standards and interfaces
• Complexity → thousands of protocols (more than 5000 RFCs)
– Complex Network Management → difficult to apply access policies, QoS…
• Limit the research → vendors and admins are reluctant to
investigate and develop new paradigms. “If it works, do not touch it”
– It’s complicated to introduce new proposals

3
Planes in Networking

• Data plane: Activities with data plane

– Forwarding
– Fragmentation/Resambling
– Replication
• Control plane: The “brain” that dictates the
data plane activities:
– Forming routing tables
– Setting (e.g. security) policies
– Interacting with other control planes

4
Current Network Devices

• Traditionally, switches , routers already

implement this separation but in the same
chasis.

5
Let’s separate control plane from
data plane

Control Plane (Centralized General Purpose Server)

Data Plane Internet Protocol

6
Centralized Management

Control Plane (Centralized Server)

7
Sowftware Defined Networks

• SDN is a paradigm shift in how to manage a network that

separates traffic switching from the management
• It decouples the network infrastructure from the
applications and services it provides
• The network is seen as a separate logical entity
independent of the applications
• The SDN Controller implements the behavior software of
the network elements
– Controls how packets are switched
– Programmed (not only configured) by the administrator
– It is the brain of the network, it has an overview of the entire infrastructure
– Indicates the rules to be displayed on the data plane
– Not dedicated software needed
8
why “Software Defined”?
• Because the controller can work in a general
purpose (PC) server
– The behaviour of the network can be programmed
• The result of the execution of the program
“enforces” the specific rules that data plane needs
to operate properly
• The controllers and the associated software
developed by the network managers is the brain of
the network
• SDN is NOT OpenFlow but OpenFlow is part of
SDN concept

9
ONF/SDN
Architecture

Northbound API

Southbound API

10
 Advantages of SDN
• Independence of the manufacturer → It is no longer tied to proprietary hardware
and dedicated devices. Combine equipment from different manufacturers
• Simplified and centralized administration
– eliminate multiple decision points
– Reduce configuration errors, bottlenecks, etc ...
– Increase security Managed by the Controller, security failures are reduced in the
configurations of the switches / routers.
• Dynamic, flexible scalable networks
– SDN networks are reconfigured in real-time, avoiding remote configuration of
each equipment
• Agility and speed of deployment of services and resources
• Cost reduction
– Savings in network equipment and operating costs due to increased efficiency in
network management
• More Innovation
– An SDN network is more flexible and configurable, allows you to experiment
with new applications, configurations, etc ...

11
Example of SDNs

Protected traffic
delivered to the
destination
✗

All
✓
Internet

Suspect Traffic sent to the Inspector

12
Idealized Framework for SDNs

13
 Southbound Protocols
• OpenFlow: Most important, de-facto standard. We’ll talk about them in next lesson
• OVDSB (The Open vSwitch Database Management Protocol): It uses JSON for its wire
format and is based on JSON-RPC version 1.0. e OVSDB protocol allows supply
configuration information to the switch database server. (OVS)
• NETCONF (Network Configuration Protocol): It provides mechanisms to install,
manipulate, and delete the configuration of network devices. Its operations are realized on
top of a simple remote procedure call (RPC) layer with XML.
• SNMP (Simple Network Management Protocol): very well-known protocol for managing
network devices.
• PCEP (Path Computation Element Communication Protocol): A protocol to enforce routing
or network path information in MPLS networks.
• XMPP (Extensible Messaging and Presence Protocol): It can be used by the controller to
distribute both control plane and management plane information to the server endpoints
• BGP (Border Gateway Protocol): A protocol to exchange routing information between
controllers.
• I2RS (Interface to the Routing System): These allow information, policies, and operational
parameters to be injected into and retrieved (as read or by notification) from the routing
system
• LISP (The Locator/ID Separation Protocol): protocol that enables separation of IP
addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing
Locators (RLOCs)

14
Matching with OpenFlow

15
Orchestration
• With SDN, the network can be provisioned in an
orchestrated way along with other IT components
like servers, storage and applications.
• So SDN can be automated → SDNs orchestration
tools
• There are tools to automate the creation of network
services.
• The API of the tools represents a subset of the
capabilities provided by the SDN Northbound API.
• For example SDNs can be deployed and managed
in Cloud Computing
– E.g: OpenDayLight plugin for OpenStack Neutron

16
Virtual Networks and Cloud
Computing
• OpenStack: open source solution for Cloud Computing
• OpenStack Networking (Neutron):
– It is a component of Openstack that provides the functionality "Network
as a service" in Cloud Computing
– It manages the virtual network infrastructure and aspects of access
to the physical network
– Allows cloud users to create virtual network topologies including
firewall services, load balancers and VPNs
– It creates abstractions for networks, subnets and routers. The networks
are created by software and connect the VMs managed in the Cloud.
– Neutron is based on plugins. E.g the ML2 plugin is used to build the
virtual networks, which in turn uses the Open vSwitch agent (OVS)

17
OpenStack – Architecture with Neutron

18
Deployment example – OpenStack and Neutron

19
Deployment example – OpenStack and Neutron

• Virtual networking
infrastructure
– Networks
data-
bases – Routers, switches
– Middleboxes:
load balancers,
Front-end Network

web

Back-end Network
External Network

servers firewalls, etc

20
 OpenStack and SDN

e.g. OpenDaylight

21
List of Open Source Controllers

22
Example: OpenDayLight

23
OpenDayLight
• The controller plartform is written in Java
• It implements Open Services Gateway Initiative
(OSGi) to interact with applications.
• It provides a REST API to talk with the controller.
• It adds a Service Abstraction Layer (SAL) : It
determines how to fulfill the requested service
irrespective of the underlying protocol used
between the controller and the network devices.
• Support multiple protocols in the southbound API.
• There is an Eclipse plug-in to program
OpenDayLight

24
Example: OpenStack Neutron and
OpendDayLight

25
Example: Helium Architecture

26
ONOS

• ONOS (Open Network Operating System)

• Open source community (Linux Foundation)
• Operating system for communications service providers that
is designed for scalability, high performance and high
availability
• Carried oriented
• Written in Java
• Provides a distributed SDN applications platform atop
Apache Karaf OSGi container
• Not tied to a specific SouthBound API (openflow, Netconf…)
– Provides high level of abstractions and models
28
ONOS

• network graph abstraction provides information about

the structure and topology of the network
• flow objective is a device-centric abstraction that
allows applications to direct flow of traffic through a
specific device without the need to be aware of the
device table pipeline
• intent is a network-centric abstraction
– to control network by specifying what they wish (policy) to
accomplish rather than how they want to accomplish it
– This simplifies application development
– provides the platform with added degrees of freedom to resolve
conflicting requests

29
ONOS

30
ONOS

Based in Floodlight
31
Inter-SDN communication
East/West Interface

32
 Inter-SDN communication
Sample Business Use Cases
• Bandwidth on Demand
– network resources are distributed among multiple SDN domains, controllers communicate
each other to share network parameters.
– This enables the controller of the source domain to confirm and process the bandwidth
requirement.
• Content Delivery Networks
– If the CDN server or cache nearest to the customer location is experiencing high loads, the
request is sent to a CDN server/ cache that is not loaded. However, this CDN Server/ Cache
may be located in a different SDN domain in the network.
– The source SDN controller communicate (over SDNi) with other SDN controllers within the
network to negotiate a path to the best possible CDN server/ cache that meets the
customer's QoS expectation
• Separate SDN Controllers for Various Networks
– If the customer (retail, enterprise) demands a service that is provided by the data center,
the SDN controllers of access, edge, core networks, and the data center need to
communicate with each other.
– SDN controllers need to pass on parameters like QoS and policy information from the
access network to the core network to the data center.

33
SDN Challenges

• A single controller
– Bottleneck
– Point of failure
• Control logic centralized, but
physically distributed, to increase
scalability, security, reliability
• Challenge: manage scalability
issues to maintain a consistent
view of network status when there
are multiple controllers
34
SDNs Challenges

• SDN allows novel security applications

– But the controllers are the main point of attack

• Challenge
– Intrusion prevention
– Collaboration between controllers to detect and
isolate the attacker
35
Network Function Virtualization
• Nowadays:
– Network Services are implemented as specialized
middleboxes
– Need to be in the datapath between client and server,
which makes the deployment difficult
– Difficult to add and remove services
– Operators’ networks have a large and increasing variety of
proprietary hardware appliances
– For deploying a network service→ space and power
energy, and to design, integrate and operate increasingly
complex hardware (from different vendors)
– Hardware evolution is becoming faster and faster →
problem for revenue earning
36
Network Function Virtualization

• Solution:
– “Network Functions Virtualisation (NFV) aims to address
these problems by leveraging standard IT virtualisation
technology to consolidate many network equipment types onto
industry standard high volume servers, switches and storage,
which could be located in Datacentres, Network Nodes and in
the end user premises.“
– Network services run on virtual machines that can be
easily instantiated, moved and deleted
– Mechanisms are needed to define the sequence of
network functions that a data flow must pass through
(e.g firewall → load balancer)

37
 NFV - Benefits
• On-demand scalability: the elasticity to scale instances up/down
according to the current workload
• Dynamic deployment: virtualized security functions can be deployed
along the forwarding path, avoiding inefficient traffic detouring
• Mobility support: offloading of virtual network and virtual security
functions towards the network edge. Avoiding traffic re-routing and
enabling short response time
– rapidly shift the location and capacities of network functions and achieve
workload mobility
• Security service chains where user’s traffic is appropriately processed
according to security policies
• Vendor Independence: easily deploy a different vendor’s solution without
the heavy costs associated with replacing an existing vendor’s deploymen
• Decoupling network functions from hardware: offloading of tough
tasks from constrained devices
38
Vision of NFV

39
NFV - Architectural Framework

Operational support systems (OSS) 40

Element Management System (EMS)
NFV - Architectural Framework
• The NFVI (Network Functions Virtualisation Infrastructure):
provides the virtual resources required to support the execution of
the Virtualised Network Functions
• The VNF (Virtualised Network Function): is the software
implementation of a network function which is capable of running
over the NFVI
• The NFV M&O (Management and Orchestration): covers the
orchestration and lifecycle management of (physical and/or
software) resources that support the infrastructure virtualisation,
and the lifecycle management of VNFs.
• Set of metada describing the services, VNFs and infraestructure
requirements.
• OSS/BSS (Operational Support Systems/Businness Support
Systems) information systems used by telecommunication
operators
• EMS (Element Management System): It performs the typical
management functionality for one or several VNFs.

41
MANO
• NFV MANagement and Organization (MANO)
• MANO WG in ETSI
• NFV Orchestrator: Responsible for on-boarding of new network
services (NS) and virtual network function (VNF) packages; NS
lifecycle management; global resource management; validation and
authorization of network functions virtualization infrastructure
(NFVI) resource requests
• VNF Manager: Oversees lifecycle management of VNF instances;
coordination and adaptation role for configuration and event
reporting between NFVI and E/NMS (Element/Network
Management System)
• Virtualized Infrastructure Manager (VIM): Controls and manages
the NFVI compute, storage, and network resources

42
OpenMANO

43
NFV - Use cases

44
Virtual Network Security Functions
• Examples of Virtual Network Functions (VNFs)
– vRouter (e.g. OpenVirtualSwitch in OpenWRT)
• Traffic forwarding, traffic mirroring, traffic diversion …
– vDNS
– vIMS ( IP Multimedia Subsystem) voice, video and messaging services.
– vCDN (Content Delivery Networks)
– VoLTE
– vDHCP
• Examples of Virtual Security Functions
– vFirewall (e.g. netfilter Linux iptables)
• Filtering rules
– vChannelProtection
• Level3 encryption IPSec, SSL e.g. openVPN, DTLs
– vIDS (Intrusion Detection System, e.g. Snort)
– vAAA (e.g. Free Radius)
45
 SDN – NFV
Example

SDN-based Security
Orchestrator
configuration of Provisioning of
security (2) Mirroring traffic security (1)
appliances appliance

SDN Controller NFV-MANO

Flow Duplicated
(3) Mirroring Traffic vIDS
Rule (4)

SDN IoT node

Client switch
(OVS)

46
 SDN – NFV
Example
Security Reaction Monitoring
SDN-based Orchestrator Module Module

security Stop (8) (7)

(9) Security Security
Malicious
countermeasures Traffic
Reaction Alert

SDN Controller
(6)

Drop vIDS Agent

(10) Flow
Rule

SDN IoT node

Client switch
(5) Client starts generating
malicious traffic (11) Malicious traffic
stopped at SDN switch

47
NFV - Challenges
• Fixed configurations: hardware-based network
appliances are typically configured with fixed IP address
• Manual management: Automatization will be required
due to the dynamic nature of VNFs
• Rapid growth of IP end points: Due to flexibility and
the reduction of costs the number of network endpoints
will increase faster
• Network End Point mobility: VNFs can be migrated in
separate in different physical servers.
• Elasticity: VNFs are created, adjusted, and destroyed
in real time on demand

48
NFV-SDN integration

• Case 1: the SDN controller is merged with the Virtualised Infrastructure

Manager functionality.
• Case 2: the SDN controller is Virtualised as a VNF.
• Case 3: the SDN controller is part of the NFVI and is not a VNF.
• Case 4: the SDN controller is part of the OSS/BSS. 49
• Case 5: the SDN controller is a PNF.
References

• W. Stallings, “Software-Defined Networks and

OpenFlow”, Vol 16(1), March 2013
• Solution Brief: OpenFlow-enabled SDN and
Network Functions Virtualization (url:
https://www.opennetworking.org/en/solution-brief-openflow-
enabled-sdn-and-network-functions-virtualization)

• Network Functions Virtualisation (NFV) White

papers #1, #2, #3

50
 Introduction to SDNs and NFV

Jorge Bernal Bernabe, PhD.

Department of Information and Communications Engineering,
University of Murcia, Spain

E-mail: [email protected]
Web: https://webs.um.es/jorgebernal
Phone: +34 868884644

51 51