Building a Platform Optimized for the Network Edge

MPLS + SDN + NFV WORLD 2018

Nicolas Bouthors, Enea Innovation

The Enea Edge

Software Virtualization - Key Requirements

Leveraging DPDK

Multi-Function VNFs at the edge

The Key Role of NETCONF

Adding Service Function Chaining (SFC)

Summary

Agenda

Summary

Edge software platforms will help shape the uCPE Market

Building edge software platforms requires expertise

High performance leads to optimized cost

Architectural guidelines:Open Source

Multi-Function VNFs first

NETCONF based management and orchestration

Network Intelligence (DPI) at the heart of many use cases

3

Typical uCPE Deployment Architecture

4

VNF VNF

NFV Core

VNF VNF VNF

NFV Platforms

Orchestration

Data Center (DC)

Cloud

Edge Data Center

Central Office (CO)

Point of Presence (PoP)

Customer Premise

AND / OR

uCPE

pCPE

NFV Access

VNF VNF

NFV Core

VNF VNF

Cloud Platform

VNF VNF VNF

uCPE manager

SFC and

Network Intelligence

Software Virtualization Platform – Key Requirements

▶Open-source based and hardware independent

Able to work with any white box, VNF and orchestration vendor

to meet end-customer requirements

▶Multi-architecture NFV platform

Choice of Arm or Intel for both uCPE and Edge Datacenters

▶Optimized for high performance

Low memory footprint, minimum boot time and high networking

performance

▶Built-in network intelligence

DPI, traffic classification and Service Function Chaining (SFC)

capabilities

5

The Enea Edge

Software Virtualization - Key Requirements

Leveraging DPDK

Multi-Function VNFs at the edge

The Key Role of NETCONF

Adding Service Function Chaining (SFC)

Summary

Agenda

Reminder about Intel DPDK

More than 20 key open source projects build on DPDK libraries, including MoonGen, mTCP, Ostinato, Lagopus, Fast Data (FD.io), Open vSwitch, OPNFV, and OpenStack.

Key principles Move work to user space

Avoid data copies

Bypass the kernel: work at packet level

Pool mode

Enables high performance networking up to VM and containers

7

Intel DPDK Optimization: Lessons Learned

DPDK is sensitive to optimization /

tuning

CPU Allocation

Packet buffering scheme

High performance but costly

(CPU, RAM)

CPU dedicated to Polling

Need to minimize the number of

DPDK applications

https://software.intel.com/en-us/articles/low-latency-

nfv-infrastructure-for-performance-critical-applications

8

The Enea Edge

Software Virtualization - Key Requirements

Leveraging DPDK

Multi-Function VNFs at the edge

The Key Role of NETCONF

Adding Service Function Chaining (SFC)

Summary

Agenda

Multi Function VNFs are Taking over the Edge

Multi-zone Firewall

CG NAT

SD WAN

URL Filtering

Antivirus

vRouter

High performance VNF infrastructure

Low latency

High throughput

Security

Management

Extensible

Stateful

Multi Function VNF Features

Fat

VNF

10

Requirements

An “Ideally” Multi Function VNF at the Edge

A DPDK vRouter / vSwitch

Shared Flow table (DPI)

Multi Function VNF avoid unnecessary context switches and data copies

User space

DPDK / SRIOV

Migrate Multi Function VNF functionality in the infrastructure

Kernel

VNF2

Multi Function vRouter/DPI

PHY

NIC

PHY

VNF1

Flow Action

Tuple 1 Port A

Mgt Agent

PHY

NIC

KVM/Docker

Fat

VNF

11

How to build a Fat VNF for the Edge

Components of a complete VNF SDK

VPP NS Plugins

- L7 Flow table

- Security

Groups

• VPP is a great VNF Framework

• Managed by NETCONF

• Extensible plugin library

• Open source

VM2

PHY

VM1

NICPHY

NIC

VM3

12

vRouter/DPI/L7 Classifier

The Enea Edge

Software Virtualization - Key Requirements

Leveraging DPDK

Multi-Function VNFs at the edge

The Key Role of NETCONF

Adding Service Function Chaining (SFC)

Summary

Agenda

The Right Tools for the Job:MANO and Network Management Working Together

MANO is about NFV management and contains 3 components: Virtualized Infrastructure Manager (VIM)

VNF Manager (VNFM)

NFV Orchestrator (VNFO)

Carrier grade deployment need HA and FCAPS management capabilities

MANO and NMS/SMS interact to enable orchestration and configuration

NETCONF provides a proper abstraction model to control Network and Infrastructure components

SOAP REST

Device

Modules

NETCO

NFSNMP

XML-

RPC

Other

Other

Meta data

Data

models

Request manager

GUI

OSS/BSS

Service

ManagementService

module

s

System

Manag

ers

System core

14

+

Key Role of NETCONF

The NETCONF protocol was designed to address the shortcomings of existing practices and protocols for configuration management including:

Distinction between configuration and state data

Multiple configuration data stores (candidate, running, startup)

Configuration change transactions

Configuration testing and validation support

Selective data retrieval with filtering

Streaming and playback of event notifications

Extensible procedure call mechanism

NETCONF provides the proper abstraction environment to manage thousands of complex devices in parallel!

15

NETCONF at the Heart of Orchestration Interfaces

Centralized VNF Management and Service Function Chaining Docker API

Container virtualization

Services packaging and delivery

OpenStack API

Container and VM virtualization

Full NFV integration

Networking API

NETCONF/REST API for automation

Integration points

1. Orchestration

2. VIM (Carrier Edge NFV platform)

Enea NFV Access

VNFVNF VNF

NFV Platform

Orchestration

Carrier Edge

PoP/COCustomer Premise

1

2

Zero lock-in with open standard APIs

16

The Big Picture: Toward Multi-Domain

This model is already implemented in cascading OpenStack projects such as Tricircle to scale up OpenStack deployments

Allows tenant networks (slices) to spread over several cascaded OpenStack

Rely on flavors and specialized OpenStack instances to secure particular properties (scheduling, partitioning, NFV accelerations)

Traffic will run through service chains

VNFs will be spread over multiple domains

Layer 3 forwarding will be required to move across domains

Domains network configuration must be independent of service chains

17

The Enea Edge

Software Virtualization - Key Requirements

Leveraging DPDK

Multi-Function VNFs at the edge

The Key Role of NETCONF

Adding Service Function Chaining (SFC)

Summary

Agenda

SFC: Leveraging OpenStack networking-sfc API

If a service function has a pair of ports, the first port in the port-pair is the ingress port of the service function, and the second port is the egress port of the service function.

A Port Chain is a directional service chain. The first port of the first port-pair is the head of the service chain. The second port of the last port-pair is the tail of the service chain.

For example, [{'p1': 'p2'}, {'p3': 'p4'}, {'p5': 'p6'}]

SF2 has ports p3 and p4,

SF3 has ports p5 and p6

Where P1 is the head of the Port Chain and P6 is the tail of the Port Chain,

SF1 SF2 SF3

p1 p2 p3 p4 p5 p6SC

Clear and simple NFVI northbound APIs are required for management automation

19

End to End SFC with IPv6 Source Routing

DPDK

VM

OVS

Service

ClassifierContainer

A

Service

Term.

Encode

IP6 SR

Options

Remove

IP6 SR

Options

Source Routing

SFC Agent

vSwitch

SFC

UI/ CLI

Lists available

Service

Functions per

Tenant

Source Routing Header:

IPv6 SR is supported by VPP FD.io

IPv6 routing performances: over 20Gbps/core

IPv6 routing with 0.5M /128 routes, IPv6 header validations,

IPv6 lookup per packet, L2 Ethernet header rewrite per packet

https://fd.io/wp-content/uploads/sites/34/2017/07/FDioVPPwhitepaperJuly2017.pdf

20

The Enea Edge

Software Virtualization - Key Requirements

Leveraging DPDK

Multi-Function VNFs at the edge

The Key Role of NETCONF

Adding Service Function Chaining (SFC)

Summary

Agenda

Target Edge Software Platform Characteristics

Characteristics Enea uCPE benchmark Common uCPE solutions

Platform RAM Footprint < 1 GB 4-12 GB

Platform Disk Footprint < 1 GB 4-12 GB

Platform CPU Utilization Down to single core Down to 2-4 cores

Platform Boot Speed (excl. BIOS) < 3 seconds 10-30 seconds

Virtualized Network Throughput over vSwitch 10 Gb IMIX Line Rate 1 Gb IMIX Line Rate

Virtualized Network Latency over vSwitch Average 10-15 µs Average 25-75 µs

22

Takeaways

Edge software platforms will help shape the uCPE Market

Building edge software platforms requires expertise

High performance leads to optimized cost

Architectural guidelines:Open Source

Multi-Function VNFs first

NETCONF based management and orchestration

Network Intelligence (DPI) at the heart of many use cases

23

THANK YOU

www.enea.com

The Enea Edge

Extensibility

Design Choice Enea NFV Access Common uCPE solutions Comment

Platform

foundation

Bottoms up approach with optimizations and footprint

reduction in every layer of the platform based on Open

Source software

Top down adapting either

Common Linux Distributions such as Centos or

Ubuntu

Preexisting CPE or Data Center platforms

Enea NFV Access optimize for small CPU, RAM

and Disk footprint and fast boot speed to drastically

reduce the Hardware BOM

Feature set Minimal extensible feature set Large feature set induced by OpenStack services

presence

Start with a small feature set and grow it according

to needs for minimized platform footprint and

optimal uCPE characteristics

VIM architectureDelocalized VIM using NETCONF for management

protocolsLocalized VIM using OpenStack with OpenStack

internal management protocols

Delocalized VIM reduce uCPE CPU utilization,

RAM and Disk footprint

Platform Feature

Extensibility

Platform SDK enabling :

Building custom kernel modules and

configuration in host and VMs

Native platform extensions

VM and containers platform extensions

Professional Services for custom configurations and

extensions and VM based extensions

Extend the platform to adapt specifically to

customers specific use cases

Management

Extensibility

SDK for NETCONF and YANG modelling support, for

FCAPS and for customized Platform Management NETCONF protocol support for FCAPS

Use NETCONF for standardized and extendible

platform management beyond FCAPS

VIM Feature

Extensibility

Enea uCPE Manager is a customizable and model

based VIM with REST northbound and NETCONF

southbound APIs

N/A

Customizing OpenStack is hard, complex and

costly. Enea uCPE manager is designed to be

extensible

25