SDN + NFV

The Necessary Network

Virtualization Equation

Diego R. Lopez
Telefonica I+D
July 2014
 Enter the Software Era

Telco players Internet players

• Very intensive in • Very intensive in
hardware software
• Capital intensive
• Software is not at
x • Can have global impact
with not too much capital
the core • Hardware is a support, and
is located in the network
periphery

- +
SOFTWARE
HARDWARE
+ -

Network Virtualization takes the “Software-defined” as a key tool for

transforming the industry
 The Network Dystopia…

Segmented management: High OPEX, often with low utilization of resources, high complexity, and slow time-to-
market for deploying any kind of network service…
 …Makes IT Nonsense

Mapping to computers how networks have evolved…

 The Key Role of Virtualization

A layered model virtualizing devices and resources

 Scale and Virtualization in the Timeline

Early twentieth century Mid-twentieth century

• Manual Switching • Electromechanical

• Very intensive in
human tesources
x •
Switching
Less intensive in
• Era dominated by human resources
hardware • Era dominated by
complex hardware
Virtualization technologies enables
overcoming physical constraints and
generating multiplexing gains…
• Digital Switching • Internet connectivity

x
• Much less intensive in
human resources x opens the door to the
development of OTT
• Era dominated by services (without
complex and specific operator)
hardware. Software • Software becomes a
appears and is important differentiation asset
• Services defined by telco
Second half of the twentieth century Early twenty-first century
 Network Virtualization = SDN + NFV

• Provide a general interface to

network resources
 Abstracting actual
infrastructure details
• Decouple the planes conforming
the network
 Relying on software
mechanisms to support
functionality

SDN NFV
• Decouple the control and data planes • Separate functionality from capacity
 Gain programmability  Increase network elasticity
 Simplify data plane elements  Reduce heterogeneity

Software in the network The network in software

 Software Defined Networking

SDN

Network equipment as Open interfaces (OpenFlow) for

Black boxes instructing the boxes what to do

FEATURE FEATURE
OPERATING SYSTEM

SPECIALIZED PACKET
FEATURE FEATURE FORWARDING HARDWARE FEATURE FEATURE
OPERATING SYSTEM OPERATING SYSTEM

SPECIALIZED PACKET SPECIALIZED PACKET

FORWARDING HARDWARE FEATURE FEATURE FORWARDING HARDWARE

OPERATING SYSTEM

SPECIALIZED PACKET
FORWARDING HARDWARE
SDN
Boxes with autonomous
behaviour Decisions are taken out of the box

FEATURE FEATURE

FEATURE FEATURE
OPERATING SYSTEM

SPECIALIZED PACKET
OPERATING SYSTEM

SPECIALIZED PACKET
FORWARDING HARDWARE FEATURE FEATURE
OPERATING SYSTEM

SPECIALIZED PACKET
SDN
FORWARDING HARDWARE FEATURE FEATURE FORWARDING HARDWARE

OPERATING SYSTEM

SPECIALIZED PACKET
FORWARDING HARDWARE

Simpler OSS to manage the

Adapting OSS to manage black boxes
SDN controller
 Make the Network *A* Computer

• We can apply software SDN Controller

development techniques and

tools
• Software development and
operation being multifaceted
 Different tools for different
tasks SDN
• Static and dynamic verification Forwarder

• Translation: assemblers,
compilers, interpreters, linkers
• Testing and debugging
OVS OVS

• Version and configuration control

• Dynamic composition and linking
• Development flows OVS OVS

• And any other abstraction

capability
 Network Brokering

• Applications use SDN to learn

DC Orchestrator
about the network
• And then talk to the network to

CDN

BoD

OSS

…
optimize performance
• SDN acts in a similar way to an ESB
(or CORBA, for the old-timers)
 An adaptor to go from protocols to
APIs and vice versa ALTO
 A translator, which summarizes OFC ...
Server
network properties
 A security/policy gateway that
enforces which application is
allowed to learn what and change
what, and who gets priority Network Elements
 Network OS

• Providing a consistent interface to

control, data and management plane
 A layered model
 The first take could follow an analogy
with existing OS
• The kernel is realized by control plane
mechanisms
• Data plane is associated with the file
system
• The management plane is mapped to
the system tools
 Remember the shell
• Specific services to enforce policy and
security
• And the APIs
 The Road to a Network IDE

• The natural consequence of

applying concepts and tools
related to software
development
• Supporting a complete design
flow
 High-level definition and
manipulation
 Validation from simulation
to actual debugging
 Beta versions by slicing
 Phased deployment
 Integrate virtualized and non-
virtualized functional elements
 Aligned with parallel IT
development
Putting It All Together: The NetOS Architecture

NFV
IDE SDN App
Orchestrator
User Space (/usr)
Northbound Interface

Topology

vRouter
vSwitch

SDN Apps
TE

…
Libraries
Services
App Execution Environment(s)

Virtual Network Layer Kernel (/kernel)

Common Representation Model
Security /
Security and Ancillary Services
Dist IF

Distributed OS / Accounting /
State Consistency Namespaces Namespaces and Module Management

Network Abstraction Layer (NAL) Devices and Drivers (/dev)

Southbound Interface
OpenFlow VNF NetConf I2RS NAL
Drivers

Network Elements
 Network Functions Virtualisation

A means to make the network more flexible and simple by minimising

dependence on HW constraints

Traditional Network Model: Virtualised Network Model:

APPLIANCE APPROACH v v
VIRTUAL APPLIANCE APPROACH

DPI CG-NAT GGSN/ VIRTUAL

BRAS SGSN
DPI APPLIANCES
Firewall PE Router
BRAS
GGSN/SGSN
ORCHESTRATED, AUTOMATIC
& REMOTE INSTALL
PE Router
Session Border STANDARD
Firewall CG-NAT Controller HIGH VOLUME
SERVERS

 Network Functions are based on specific HW&SW  Network Functions are SW-based over well-known HW
 One physical node per role  Multiple roles over same HW
 The NFV Concept

Network functions are fully defined by SW, minimising dependence

on HW constraints

DPI CG-NAT GGSN/ VIRTUAL NETWORK

BRAS SGSN FUNCTION
FUNCTIONS
Firewall PE Router

COMMON HW
CAPACITY
(Servers & Switches)
 The ETSI NFV ISG

• Global operators-led Industry Specification Group (ISG) under the auspices of

ETSI
• >200 member organisations
• Open membership
• ETSI members sign the “Member Agreement”
• Non-ETSI members sign the “Participant Agreement”
• Opening up to academia
• Operates by consensus
• Formal voting only when required
• Deliverables: Specifications addressing challenges and operator requirements
• As inputs to SDOs
• Currently, four WGs and two EGs
• Infrastructure
• Software Architecture
• Management & Orchestration
• Reliability & Availability
• Performance & Portability
• Security
 The NFV ISG in Numbers

• Growing membership and activitiy

 207 Member companies, (85 ETSI Members, 128
Participant Members)
 1095 people subscribed to the principal NFV mailing list
 15 active Work Items
• And results
 Published 4 framework documents - Use Cases,
Requirements, E2E Architecture and Terminology
 4 stable drafts available on the Open area
 Created easy to navigate websites for access to public
material
 18 accepted PoCs
• Planning a second phase

© ETSI 2014. All rights reserved

17
 Service-Oriented Use Cases

• Mobile core network and IMS

 Elastic, scalable, more resilient EPC
 Specially suitable for a phased approach
• Mobile base stations
 Evolved Cloud-RAN
 Enabler for SON
• Home environment
 L2 visibility to the home network
 Smooth introduction of residential
services
• CDNs
 Better adaptability to traffic surges
 New collaborative service models
• Fixed access network
 Offload computational intensive
optimization
 Enable on-demand access services
The NFV Framework

E2E Network Service

End End
Point Network Service Point
Logical Abstractions
VNF VNF

VNF VNF VNF

Logical Links

VNF Instances
SW Instances
VNF VNF VNF VNF
VNF : Virtualized Network Function

NFV Infrastructure

Virtual Resources Virtual Virtual Virtual

Compute Storage Network
Virtualization SW Virtualization Layer
HW Resources Compute Storage Network
The NFV Reference Architecture

Os-Ma
OSS/BSS Orchestrator
Se-Ma
Service, VNF and Infrastructure
Description
Or-Vnfm

EMS 1 EMS 2 EMS 3 Ve-Vnfm

VNF
Manager(s)

VNF 1 VNF 2 VNF 3 Or-Vi

Vn-Nf Vi-Vnfm
NFVI
Virtual Virtual Virtual
Computing Storage Network
Nf-Vi Virtualized
Virtualization Layer Infrastructure
Vl-Ha Manager(s)
Hardware resources
Computing Storage Network
Hardware Hardware Hardware

Execution reference points Other reference points Main NFV reference points
 Architectural Use Cases

• Network Functions Virtualisation

Infrastructure as a Service
 Network functions go to the cloud
• Virtual Network Function as a
Service
 Ubiquitous, delocalized network
functions
• Virtual Network Platform as a
Service
 Applying multi-tenancy at the VNF
level
• VNF Forwarding Graphs
 Building E2E services by
composition
 The New Roles - XaaS for Network Services

User
NSP
VNF Forwarding Graph
VNF Admin
VNF VNF User
VNPaaS
Admin VNF VNF
User
VNFaaS
Hosting Service Provider
VNF VNF VNF
VNF VNF VNF
VNF VNF VNF

VNF Tenants
NFVIaaS

NFVI
Provider
IaaS NaaS NaaS PaaS PaaS SaaS
It Ain’t Cloud Applied to Carriers

The network differs from the computing environment in

2 key factors…
1
Data plane workloads HIGH PRESSURE ON
(which are huge!) PERFORMANCE

2
Network requires shape GLOBAL NETWORK VIEW IS
(+ E2E interconnection) REQUIRED FOR
MANAGEMENT

…which are big challenges for vanilla cloud computing.

AN ADAPTED VIRTUALIZATION ENVIRONMENT IS NEEDED

TO OBTAIN CARRIER-CLASS BEHAVIOUR
 A Proper Balance between NFV & SDN

Service-layer SDN
Simplify management, closing the gap between business logic and operation

NFV
 Separation of HW and SW
 No vertical integration
Pool - HW vendor ≠ SW vendor ≠ Mgmt vendor
admin  Once network elements are SW-based,
Session
UPnP HW can be managed as a pool of
mgmt
IPv4 / NAT resources
IPv6
NAT
TR-069 DHCP ctrl.

Infrastructural SDN
Virtual backplane
 Separation of control and data plane
 Easy orchestration with SW domain
 An Evolutionary Approach

• NFV and SDN imply a significant change for

current network infrastructures
 No zero-day approach is feasible
 Avoiding disruptions
• Identify relevant use cases
 Emerging services
 Reuse of equipment still in amortization Soft-Node
 Leverage on new planned elements in
architecture
• Plan for phased deployments
 Interworking with existing infrastructure
 Not breaking current operational practice
• Take advantage of virtualization advantages
 Flexibility
DS vCPE
 Extensibility
 Reusability
 Current Targets: Virtual Residential CPE

Shifting network functions deployed in home

Telco Network
environment to the network…
environment

Home environment
STB
Virtual FW
UPnP
CPE
Access Point Switch Módem IPv4/IPv6
TR-069
DHCP NAT

• Simple, stable along the time and cheaper • Service evolution and operation is supported inside
customer premises equipment telco network
• Monetize cloud and video services (virtual set top
• Quick and transparent migration to IPv6 box)
• Monetize security and digital identity features

Live trial today MATURITY LEVEL

Commercial before end 2014 EXPLORE PoC TRIAL DEPLOY
Current Targets: Elastic DPI
CENTRALISED INTELLIGENCE
Other data

Deeper Network Big

Data
RELEVANT REAL-TIME
Metadata interface
ANALYSIS
INFO
xDRs NFV
Security domain
Copy Alarms
OpenFlow
RAW USER TRAFFIC POLICY
DECISIONS
RAW USER TRAFFIC MITIGATION
OF Controller SDN
OF Switch
domain

• >80 Gbps line rate per server • Flexible data analysis and signature
upgrade
• Stable signatures
• Forensic analysis feasible.

MATURITY LEVEL

EXPLORE PoC TRIAL DEPLOY

Current Targets: Enhanced Virtual Router

Leverage on open source routing project (Quagga) as rich and widely

tested protocol suite while assuring data plane performance

OPEN-SOURCE CONTROL • Common routing protocols supported and

PLANE extended by open source project.
(Quagga + Linux) • Well-known router command line.

OPTIMIZED • High-performance line-rate data plane.

DATA PLANE • Running as separate process, does not lead to
(DPDK-based) licensing issues.

MATURITY LEVEL

EXPLORE PoC TRIAL DEPLOY

Counting a Few

• Orchestration has the key

 Pieces at all infrastructure layers
 Need to go beyond just fitting them together
 Big data in the loop
 Seize the opportunity to simplify systems and processes
• Identify interstitial security threats
 Topologies
 Trusted boot
 Several identity layers and accounting
• Design patterns
 Big multi-user VMs vs small single-user ones
 Componentization
 Building services by composition
• Dealing with topology layers
 Up to three: infrastructural, virtualized, and service
 Mapping to current practices and protocols