Building a Platform Optimized for the Network Edge MPLS + SDN + NFV WORLD 2018 Nicolas Bouthors, Enea Innovation
Agenda Software Virtualization - Key Requirements Leveraging DPDK Multi-Function VNFs at the edge The Key Role of NETCONF Adding Service Function Chaining (SFC) Summary The Enea Edge
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 Orchestration ucpe manager VNF VNF VNF VNF VNF VNF VNF VNF VNF VNF VNF VNF Cloud Platform NFV Core NFV Core NFV Platforms NFV Access SFC and Network Intelligence ucpe AND / OR pcpe Data Center (DC) Cloud Edge Data Center Central Office (CO) Point of Presence (PoP) Customer Premise 4
Software Virtualization Platform Key Requirements Open-source based and hardware independent Multi-architecture NFV platform Optimized for high performance Built-in network intelligence Able to work with any white box, VNF and orchestration vendor to meet end-customer requirements Choice of Arm or Intel for both ucpe and Edge Datacenters Low memory footprint, minimum boot time and high networking performance DPI, traffic classification and Service Function Chaining (SFC) capabilities 5
Agenda Software Virtualization - Key Requirements Leveraging DPDK Multi-Function VNFs at the edge The Key Role of NETCONF Adding Service Function Chaining (SFC) Summary The Enea Edge
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-latencynfv-infrastructure-for-performance-critical-applications 8
Agenda Software Virtualization - Key Requirements Leveraging DPDK Multi-Function VNFs at the edge The Key Role of NETCONF Adding Service Function Chaining (SFC) Summary The Enea Edge
Multi Function VNFs are Taking over the Edge Multi Function VNF Features Fat VNF High performance VNF infrastructure Multi-zone Firewall CG NAT SD WAN URL Filtering Antivirus vrouter Requirements Low latency High throughput Security Management Extensible Stateful 10
An Ideally Multi Function VNF at the Edge A DPDK vrouter / vswitch Fat VNF Shared Flow table (DPI) Multi Function VNF avoid unnecessary context switches and data copies User space VNF1 VNF2 Mgt Agent KVM/Docker DPDK / SRIOV Migrate Multi Function VNF functionality in the infrastructure Multi Function vrouter/dpi Flow Tuple 1 Action Port A PHY Kernel PHY NIC PHY NIC 11
How to build a Fat VNF for the Edge VPP is a great VNF Framework Managed by NETCONF Extensible plugin library Open source VPP NS Plugins - L7 Flow table - Security Groups VM1 VM2 VM3 vrouter/dpi/l7 Classifier Components of a complete VNF SDK PHY NIC NICPHY 12
Agenda Software Virtualization - Key Requirements Leveraging DPDK Multi-Function VNFs at the edge The Key Role of NETCONF Adding Service Function Chaining (SFC) Summary The Enea Edge
The Right Tools for the Job: MANO and Network Management Working Together OSS/BSS SOAP REST GUI Other Request manager + Meta data Data models System core System Manag ers Service Management Service module s Device Modules NETCO NF SNMP XML- RPC Other 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 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 NFV Platform Carrier Edge PoP/CO Orchestration 2 VNF VNF VNF Enea NFV Access Customer Premise Zero lock-in with open standard APIs 1 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) 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
Agenda Software Virtualization - Key Requirements Leveraging DPDK Multi-Function VNFs at the edge The Key Role of NETCONF Adding Service Function Chaining (SFC) Summary The Enea Edge
SFC: Leveraging OpenStack networking-sfc API Clear and simple NFVI northbound APIs are required for management automation 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 portpair 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'}] SC SF1 SF2 SF3 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, 19
End to End SFC with IPv6 Source Routing 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 Source Routing Header: https://fd.io/wp-content/uploads/sites/34/2017/07/fdiovppwhitepaperjuly2017.pdf SFC UI/ CLI Source Routing SFC Agent Lists available Service Functions per Tenant Encode IP6 SR Options Service Classifier Container A DPDK VM Service Term. Remove IP6 SR Options vswitch OVS 20
Agenda Software Virtualization - Key Requirements Leveraging DPDK Multi-Function VNFs at the edge The Key Role of NETCONF Adding Service Function Chaining (SFC) Summary The Enea Edge
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
The Enea Edge THANK YOU www.enea.com
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 architecture Delocalized VIM using NETCONF for management protocols Localized 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