Presentación Laboratorio NFV de Telefónica de Antonio Elizondo

Telefónica NFV Reference Lab _

May 2015

Antonio Elizondo – Head of Network Virtualization Strategy & Technology @ Telefónica I+D – Global CTO

DISCOVER, DISRUPT, DELIVER

v

What is the big promise of Network Virtualisation?

It is an opportunity to build mouldable Networks and redefine the Architecture: Makes the infrastructure uniform and versatile Reduces interoperability complexity Improves management of risk in a changing and ambiguous

environment Introduces capacity in an easy and flexible way Fosters competition (new entrants) and innovation Prevents hardware scale from being an entry barrier


AVOID VENDOR LOCK-IN

CARRIER-GRADE PERFORMANCE CLOSE GAPS IN UNDERLYING TECHNOLOGIES (HW, OS/hypervisor & VIM)

AVOID COSTLY INTEGRATION

What is the big debt of Network Virtualization?

Main challenges Our strategy to make it happen:

CONTRIBUTE TO KEY OPEN SOURCE PROJECTS (KVM and OpenStack)

PRE-PRODUCTION REFERENCE IMPLEMENTATION (NFV Reference Lab) INVOLVING ALL INDUSTRY, to minimize integration efforts

MOULDING THE FUTURE REQUIRES GETTING YOUR HANDS DIRTY


In 2014 Telefónica launched the NFV Reference Lab: fostering the ecosystem while minimizing integration and avoiding vendor lock-in

NFVO

Proper HW &

Hypervisor config

VENDOR VALIDATION

HERE: Network Orchestration

on top of Carrier-grade

OpenStack

VNFs

VENDOR CERTIFICATION

HERE: Simplest

integration

NFVI VIM = OpenStack++

OFC++

BASELINE TECHNOLOGIES (commodity, non-proprietary)

ECOSYSTEM

ECOSYSTEM

Others to come New VNFs to be added here

Carrier-grade OpenStack

going to upstream

development

Some players have already accepted to play out of their comfort zone, while others are gradually coming

>45 VNFs >25 vendors


NFV Reference Lab: Current setup

MANAGEMENT & ORCHESTRATION

POOL OF SERVERS

SDN SWITCHES


VNFs validation on NFV Reference Lab

• Validating generic aspects of VNFs as NFV elements

• Lab testing in reference environment

• Open RFI questionnaire since March 2014 • What is covered:

>45 VNFs under validation

• Capacity consumption • Performance • Deployment options • VM interconnection options • Assumptions on VIM • Integration with NFV-O & VNFM elements

>25 Vendors

vRouter vCPE vBRAS vFirewall vDNS vEPC vSTB vIMS vSBC vPCRF virtual Load Balancer vIDS …


The life cycle of a VNF in the lab is now a mature process

Questionnaires filled in by the VNF provider

Elaboration of VNF descriptor (based on the questionnaire)

VNF on-boarding & Network Scenario setup

VNF configuration in the Scenario

Tests

Report & lessons learnt

Snapshot of the Scenario

Redeployment (if needed)

JUST 1 WEEK!


With this life cycle we are also overcoming a number of difficulties

• Early detection of wrong VNF behaviour or deployment issues in our NFVI QUESTIONNAIRES

• VNFs with specific requirements VNF DESCRIPTORS

• Proper interconnection of VNFs and with external network functions (e.g. traffic generators) NETWORK SCENARIOS

• Tests schedule requiring interruptions Re-deployment of running network scenarios through SNAPSHOTS

Most of the initial difficulties came from the lack of a suitable MANO stack ready for the challenge…


Good progress on technology readiness has been achieved so far, being MANO the less mature piece…

Management environment

Execution environment

Commodity Servers & Switches

OS + Hypervisor Virtualised

Infrastructure Manager

Virtual Network Functions

VNF Manager

NFVO

2013

2014

2010 (Bare metal)

? (OpenStack)

(OpenVIM)


Enhanced Platform Awareness (EPA) consists of using server resources more efficiently to assure performance…

CLOUD COMPUTING VIEW

MEMORY I/O device

CPU Core Core Core Core

Core Core Core Core

CPU Core Core

Core Core

CPU Core Core

Core Core

QPI

I/O device

I/O device

I/O device

I/O device

MEM

ORY

MEM

ORY

I/O device

NETWORK VIRTUALISATION VIEW Minimise QPI usage

Max. cache sharing Min. mem. translations

Polling mode drivers Full assigment to process TRAFFIC

I/O device

I/O device

Enable hugepages usage


…while avoiding unintended contention…

CPU QPI

I/O device

I/O device

Core Core Core Core Core


MEM

ORY

I/O device

I/O device

CPU

I/O device

I/O device



I/O device

I/O device

MEM

ORY

• Dedicated resource allocation: • Memory: huge pages • CPUs: not oversubscribed, isolated from host OS • I/O devices: passthrough, SR-IOV

• Modern chipset families can even avoid cache memory contention

Host OS + Hypervisor VNF 1 VNF 2 VNF 3 Not used


…and bypassing critical bottlenecks whenever needed

CLOUD COMPUTING NFV

Hardware

OS + Hypervisor

Virtual HW

SW libs OS

Virtual machine 1

Virtual HW

SW libs OS

Virtual machine N … Virtual Apps

Virtual Network

Functions Virtual Apps

Virtual Network

Functions

Hardware

OS + Hypervisor

Virtual HW

OS

Virtual machine 1 Virtual machine N …

Virtual Apps

Virtual Apps

Virtual HW

OS

UPSTREAM TRAFFIC

DOWNSTREAM TRAFFIC

BYPASSED

DATA PLANE IS MANAGED DIRECTLY

vSwitch TRAFFIC


EPA must be coherent across the NFV elements, including the MANO stack

NFVO

NFVI

Hypervisor Openflow Switches

Servers

VNFs

DPDK

NFVI optimized for NFV (EPA-enabled)

Well designed VNFs - leveraging EPA

VIM

EPA-enabled VIM

Information Models include EPA

requirements

NFV Orchestrator interprets open Info Model and optimally

deploys VNF


EXPERIENCE: 2 identical HW setups, but with different MANO will exhibit very different performance…

TRADITIONAL CLOUD NFV Same: • VNFs • Servers • Switches • Hypervisor • Network Scenario

Servers

Switch

Servers

Switch

•CMS acting as VIM No Enhanced Platform Awareness Networks based on vSwitch

•Descriptors à la cloud

•NFV-ready VIM (EPA enabled) CPU & NUMA pinning, PCI

passthrough, hugepages, etc. Networks based on ToR Openflow

switch

•Descriptors are EPA-enabled

TRADITIONAL CLOUD NFV

THEN WHAT’S THE DIFFERENCE?

VNFs VNFs

vRouter B

vRouter A vRouter C

20Gbps

20Gbps


NFV vs. Cloud

Line rate with 192 bytes frame size

Small frame sizes show real difference between both scenarios

x100 x100

Having x100 times better scalability should be sufficiently appealing!

Line rate with 1518 bytes frame size

Even large frame sizes cannot hide the actual difference between both scenarios


Lesson #1. VNF performance requires platform awareness across the chain, not just a few elements

… and needs to be percolated across the stack to be enforceable

x100 BETTER (same HW and VNFs)

EPA-ready VIM

EPA-ready MANO

NFVI –SW ready for EPA

VNFs leveraging EPA

Information Models with EPA attributes

Enhanced Platform Awareness (EPA) is needed to get proper scalability…

CLASSIC CLOUD CANNOT PROVIDE CARRIER-GRADE PERFORMANCE

PROPER VNF DESCRIPTORS ARE KEY FOR EFFECTIVE ENFORCEMENT


Lesson #2. Basic L2 connectivity is often poorly solved

INTERFACE IDENTIFICATION PER VNF INCONSISTENT … and often tied to MAC addresses!

NO BW GUARANTEES EVEN AT INTERFACE LEVEL

LACK OF PURE POINT-TO-POINT CONNECTIONS HAMPERS SCALABILITY FOR IP EDGE SERVICES LOAD BALANCING BETWEEN SERVERS INEFFICIENTLY SOLVED AT SWITCH LEVEL

VNF A VNF B VNF X VNF A VNF B VNF X

RIGHT DEPLOYMENT WRONG DEPLOYMENT

EDGE VNF

ACCESS & AGGR. NETWORKS

(>10s thousand MACs)

VNF X 10 Gbps? 10 Gbps?

Massive & Unneeded

MAC learning at NFVI

Server 1

Server 2

VNF A

VNF A


Lesson #3. VNF on-boarding is far from being seamless, killing the benefits in terms of OPEX and Time to Market

• HEAVYWEIGHT INTEGRATION (the default option)

• CLOSED ECOSYSTEMS • SUBOPTIMAL DEPLOYMENTS

(inconsistent deployment models) • ENTRY BARRIERS FOR SMALL PLAYERS


Lesson #4. Most approaches for lifecycle, focused on use cases of anecdotic value for network operation…

LITTLE GAIN FROM AUTO-SCALING - Peak periods correlated at PoP level!

AUTONOMOUS ACTIONS AT VNF LEVEL MAY LEAD TO INSTABILITY - VNFs are often middlepoints of an E2E service - Uncertain protection against chain reactions

APPROACHES TO LIFECYCLE OFTEN REQUIRE “EXCEPTIONS” FOR EVOLUTIONARY DEPLOYMENTS

- Resource Orchestration and Service Orchestration often convoluted in NFV - “Legacy” OSS needs clear boundaries between them!

… WHILE ADDING HUGE COMPLEXITY TO COMMON USE CASES - Proposed abstractions, often unfriendly for network engineering

VNF A VNF C VNF B

Service A Service B Service C

= TOTAL


Lesson #5. There are issues to orchestrate evolutionary multi-vendor scenarios, even for simple ‘network creation’

•VNFs seen as PNFs from OSS point of view

•Predictable performance •Scenarios can be saved and re-deployed •Low entry barriers

Vendor- and VNF-agnostic No formal integration

WHAT IS NEEDED TO START…

•No utilities for network design •Low performance

No EPA awareness

•NFVO-OSS coordination is often needed

•Not ready for creating scenario snapshots

•“Sticky” MAC addresses prevent re-deployment

•VNFs still need formal integration with MANO!

High entry barriers in practice

… WHAT IS BEING OFFERED


So we created OpenMANO. Open WHAT?

Open: open source project released in GitHub under Apache 2 license

MANO: practical implementation of Management & Orchestration stack for NFV

https://github.com/nfvlabs/openmano


OpenMANO introduces the notion of network scenario via descriptors, which hides complexity to network engineer…

VNF

VNF VNF

VNF VNF

VM

VM VM

VM

VM

VM VM

VM VM VNF

VNF

VNF

VM

VM VM

VM

VM

VM VM

VM VM

NS (NETWORK SCENARIO)

VNF (SW-BASED NODE)

+

-

Abstraction

VM (DEPLOYMENT UNIT)


…while provides a comprehensive set of connectivity options and assures EPA deployment at low level…

Support of L2 networks with passthrough and SR-IOV interfaces:

• E-Line

• E-LAN

Traditional E-LAN based on virtual bridges/switches is still supported

VNF VNF

VNF VNF

VNF VNF


• Low-end laptops/PCs • Functional tests • Low cost

… and is a friendly environment for developers, minimizing entry barriers & paving the way for DevOps

LOCAL DEVELOPMENT &TESTING

• Real servers and switches • Performance tests (EPA

can be enforced) • Cost-effective shared

pool

SHARED POOL FOR DEVELOPERS

• Production/pre-production environment

• Real network scenarios • Final service configuration

SERVICE PROVIDER

VNFD

VM images

VNFD

VM images

SAME IMAGES AND DESCRIPTORS ACROSS ALL THE CHAIN!


Conclusions

CLASSIC CLOUD CANNOT PROVIDE CARRIER-GRADE PERFORMANCE - Does not have proper view of HW resources - Introduces unintended contention in packet processing

PROPER VNF DESCRIPTORS ARE KEY FOR EFFECTIVE ENFORCEMENT - Need to be well-know by the developer community

ENHANCED PLATFORM AWARENESS ALLOWS TO OBTAIN CARRIER-GRADE PERFORMANCE - Needs to be coherent in all components


What are we doing now?

EPA-ready VIM released as open source in OpenMANO

Keep contributing to OpenStack for enablement of EPA features

VNFD and NSD standardization at ETSI


Want to know more about OpenMANO? Give it a try!

Fresh ideas and enthusiastic contributors are always welcome!

https://github.com/nfvlabs/openmano Available at:

[email protected] Questions/feedback/suggestions: