Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

NFV Open Source projects


Published on

more and more NFV Open Source projects ... too many ??

Published in: Software

NFV Open Source projects

  1. 1. NFV-SDN Opensource MP Odini/HPE – ETSI NFV Vice Chair Dec, 2015
  2. 2. F Many Opensource projects on NFV-SDN … 2 SDN Controller VIM DPDK NFVI NFVO Non exhaustive list … Federator used as part of testing
  3. 3. MANO OpenSource Initiatives OpenSource Link Status NEW !! ETSI OSG ‘OSM’ : OpenSource MANO new NEW – OPNFV expanding scope Expending Scope to MANO stack Tacker (OpenStack) – Apache2 Renaming of an opensource project called ServiceVM (spin-off from Neutron) Openmano (Telefonica) - Apache2 Launched beginning 2015 – issued from Telefonica test team OpenBaton (Fraunhofer) Oct 2015 – issued from OpenSDN FK project Cloudify support from Orange and Metaswitch Open-O (China Mobile) (not available yet) Presented at OPNFV Summit 2015 Gohan (NTT Data) – Apache2 Presented at OpenStack Summit Tokyo TCS Telco Cloud (Tata) TelcoCloud/OpenVNFManager
  4. 4. Backup MANO OpenSource 4
  5. 5. Overview MANO opensource has emerged this past 1-2 years from 3 main sources : • Cloud Opensource projects : ie Tacker in OpenStack, coming from neutron-ServiceVM project • Operator labs => who opensourced their orchestration/test tool : Telefonica openmano, NTT Gohan, China Mobile Open-O • New small projects => generally led by vendors, small community, or University : ie Cloudify, OpenBaton,
  6. 6. ETSI OSG ‘OSM’ : Open Source MANO 6 Jan’16: New proposal led by Telefonica , currently being reviewed by ETSI Board, and submitted to ETSI Director General Approval Scope: Develop an opensource reference implementation of ETSI MANO stack Quote: “This ISG defines a framework to facilitate the software development of a reference implementation of ETSI MANO. ISG OSM complements the work of ISG NFV. The code (reference implementation) developed by ISG OSM shall be non-normative. Any potential standardization work identified by ISG OSM will be submitted to ISG NFV for further consideration and eventual inclusion in the ISG NFV Group Specifications.”  BT PLC  Intel Corporation (UK) Ltd  Telefonica S.A.  Telekom Austria AG  Telenor ASA  Inc  Canonical Group Ltd (applicant member)  Mirantis (applicant member) Founding members
  7. 7. OPNFV Chairman: Prodip Sen, HPE 7 The scope of projects chosen by the OPNFV TSC can focus on any of the ETSI NFV architecture functional blocks and reference points, along with supporting tools and infrastructure. These functional blocks include: * Virtualised Infrastructure Manager (VIM) * Network Functions Virtualisation Infrastructure (NFVI) * Virtual Network Function Managers * Orchestrator * Virtual Network Functions and associated Element Management Systems * Service, VNF, and Infrastructure Description Operations Support System / Business Support System The associated reference points are (ETSI NFV): * Vi-Ha: The reference point between hardware resources and the Virtualisation Layer * Vn-Nf: The reference point between NFVI and a Virtualised Network Function (VNF) * Or-VNFM: The reference point between the Orchestrator and VNF Manager * Vi-Vnfm: The reference point between a VNF Manager (VNFM) and the VIM * Or-Vi: The reference point between the Orchestrator and the VIM * Nf-Vi: The reference point between the VIM and the NFVI * Os-Ma: The reference point between the OSS/BSS and Management and Orchestration * Ve-Vnfm: The reference point between the VNF/EMS and VNF Manager * Se-MA: The reference point between the Serice, VNF, and Infrastructure Description and the NFV Management and Orchestration NEW Jan’16: OPNFV expanding its scope to all ETSI NFV Functional Blocks, incl MANO
  8. 8. Tacker 8 VNFM 1.VNF Catalog 2.Basic life-cycle of VNF (define/start/stop/undefine) 3.Performance and Health monitoring of deployed VNFs 4.Auto Healing VNFs based on Policy 5.Facilitate initial configuration of VNF NFVO 1.Templatized end-to-end Network Service deployment using decomposed VNFs 2.VNF placement policy – ensure efficient placement of VNFs 3.VNFs connected using a SFC - described in a VNF Forwarding Graph Descriptor 4.VIM Resource Checks and Resource Allocation 5.Ability to orchestrate VNFs across Multiple VIMs Tacker uses TOSCA for VNF meda-data definition
  9. 9. Data Model initial draft from June 2014 (??old) 9 This project introduces a new service to organize and manage devices capable of hosting cloud services. Such devices may take a virtual form factor (like virtual machines or containers) or physical form` factors like hardware devices. The responsibility of the new services is to: 1.act as a data store for such devices 2.act as a data store for physical topology information 3.offer life cycle management for compatible device types 4.offer capacity allocation control in such devices class DeviceTemplate(model_base.BASE, models_v1.HasId, models_v1.HasTenant): name = sa.Column(sa.String(255)) description = sa.Column(sa.String(255)) infra_driver = sa.Column(sa.String(255)) attributes = orm.relationship('DeviceTemplateAttribute', backref='template') class DeviceTemplateAttribute(model_base.BASE, models_v1.HasId): template_id = sa.Column(sa.String(36), sa.ForeignKey(''),nullable=False) key = sa.Column(sa.String(255), nullable=False) value = sa.Column(sa.String(255), nullable=True) class Device(model_base.BASE, models_v1.HasId, models_v1.HasTenant): template_id = sa.Column(sa.String(36), sa.ForeignKey('')) template = orm.relationship('DeviceTemplate') instance_id = sa.Column(sa.String(255), nullable=True) mgmt_url = sa.Column(sa.String(255), nullable=True) status = sa.Column(sa.String(255), nullable=False) flavor = sa.Column(sa.String(255)) class DeviceArg(model_base.BASE, models_v1.HasId): device_id = sa.Column(sa.String(36), sa.ForeignKey(''), nullable=False) device = orm.relationship('Device', backref='kwargs') key = sa.Column(sa.String(255), nullable=False) value = sa.Column(sa.String(4096), nullable=True)
  10. 10. TOSCA – latest specs in progress 10 Current latest (as of Oct 2015) is:
  11. 11. Tacker sample VNFD template (YAML) 11
  12. 12. Tacker presentations 12 2015/summit-videos/presentation/tacker-virtual-network- function-life-cycle-management-for-openstack 2015/videos/presentation/brocade-nfv-orchestration- demo-with-openstack-tacker
  13. 13. OpenMANO follows an NFVO-centric approach, with a simplified VNF instance lifecycle management at the NFVO (VNF instantiation and termination) Openmano – released by Telefonica lab
  14. 14. • FRIENDLY FOR NETWORK ENGINEERS • NETWORK SCENARIOS & SNAPSHOTS • Provides NFVO & VIM (+ GUI and CLI) • FULL SUPPORT OF NFV PER001 GS • EPA-awareness for I/O-intensive workloads • REST-BASED APIs, OpenStack-friendly • OpenStack support also coming! • MULTI-VENDOR by design • No formal integration needed • Assures optimal VNF deployment and IXC • >30 VNFs tested • OpenMANO code @ GitHub: o Python-based o 40k code lines o Released under Apache 2 license o 30 forks OpenMANO‘s main features
  15. 15. OpenMANO automates network creation process SCENARIOS & SNAPSHOTS MAKE NETWORK DESIGN SIMPLE AVOIDS CLASH WITH LEGACY OSS (PURE RESOURCE ORCHESTRATION) EPA SUPPORT (NFVO & VIM) PROPER VARIETY OF L2 CONNECTIVITIES VNF ON-BOARDING DOES NOT REQUIRE FORMAL INTEGRATION • Hide complexity to network engineer • Scenario snapshots allow  Saving  Cloning  Re-deployment • Allows to deploy for high performance • Passthrough, SR-IOV, Virtio • E-Line & E-LAN • Descriptor-based (openly available) VNF VNF VNF VNF VNF VNF E-Line E-LAN
  16. 16. 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) OpenMANO works with abstractions of VNFs and Network Scenarios via descriptors...
  17. 17. x100 Line rate with 192 bytes frame size x100 With the right exposure of HW resources to the VNFs (as described at NFV PER001 GS), carrier-grade performance can be achieved Enhanced Platform Awareness (EPA) natively to the VNF when required…
  18. 18. Support of L2 networks with passthrough, SR- IOV or virtio interfaces: • E-Line • E-LAN Traditional E-LAN based on virtual bridges/switches is still supported VNF VNF VNF VNF VNF VNF comprehensive set of connectivities available
  19. 19. hiding complexity to network engineers
  20. 20. 1 2New VNF: virtual Router New scenario 3 Deployment 4 Test with traffic vRouter C VNFD - Deployment requirements NSD VM Image(s) OpenMANO demo
  21. 21. Openbaton 21 •the Network Function Virtualisation Orchestrator (NFVO), always required for creating a composition of different Virtual Network Function Descriptors generic-VNFM, needed only when the VNFP approach is used. Using the generic-VNFM implies also the usage of the EMS which is automatically installed on the VDUs where VNF are to be installed.
  22. 22. openbaton – OpenBaton is easily extensible. It integrates with OpenStack, and provides a plugin mechanism for supporting additional VIM types. It supports Network Service management either using a generic VNFM or interoperating with VNF-specific VNFM. It uses different mechanisms (REST or PUB/SUB) for interoperating with the VNFMs. Its initial focus was to provide the main functionalities for provisioning and managing Network Services, however in its future releases new additional features will provide mechanisms for increasing the automation in NS management. Those new features will include autoscaling, fault management, TOSCA, etc. 22
  23. 23. Openbaton code 23 files language blank comment code 159 Javascript 5958 5059 26409 348 Java 5732 8782 22917 71 HTML 5670 460 14484 23 CSS 627 318 11789 27 JSON 12 0 1791 18 LESS 102 58 1640 15 SASS 36 26 1399 66 Groovy 276 665 1055 6 Bourne Shell 85 28 394 2 Bourne Again Shell 49 35 248 1 XML 50 0 108 1 DOS Batch 24 2 64 2 PHP 7 3 45 3 YAML 1 0 31 1 Mustache 0 0 4 1 SQL 2 4 2 Total 18631 15440 82380 The LOC is about 83K, the core Java code is about 23K
  24. 24. Cloudify 24 Cloudify is an open source TOSCA based cloud orchestration software platform (like Amazon’s OpsWorks). It automates the process of installation, deployment and also post-deployment such as monitoring, remediation, and auto-scaling of your application stack.
  25. 25. Cloudify 25 Application Orchestration Your application in its entirety (Infrastructure, Middleware, Application Code, Scripts, Tool Configuration, Metrics and Logs) can be desribed in what we call a blueprint. Ex: OpenStack blueprint => cosmo/cloudify-nodecellar-example/blob/master/openstack- blueprint.yaml Written in a human readable YAML format, a blueprint allows for potentially high granularity of configuration of your application. By defining the complete lifecycle of each part of your application in a blueprint, and by utilizing the different IaaS APIs and the plugin abstractions of different tools, Cloudify can deploy and manage your application automatically. Cloudify will launch the compute instances, and configure network and security in order to manifest your infrastructure. Then, it will execute scripts (remotely via SSH or locally on the machines) or configuration management tools to configure your servers and deploy your middleware and code. Application Maintenance Cloudify’s ability to run custom workflows will grant you the ability to manually or automatically change your application’s structure, deploy code to your servers, heal or scale your system. Cloudify will use metrics collectors (and soon, log collectors) to stream application (and Cloudify specific) data to Cloudify so that you’re able to monitor and analyze your system. Data aggregation and visualization within Cloudify will allow you to execute the different workflows so that either you or Cloudify itself can make smart, actionable decisions based on business/application KPIs. Those decisions can either manually or automatically trigger workflows (such as scaling or healing) on the tactical front; or as application behavior analysis on the strategic front.
  26. 26. Cloudify 26
  27. 27. Orange Cloudify project in opensource with Clearwater vIMS 27
  28. 28. Clearwater vIMS 28
  29. 29. TOSCA like YAML description 29
  30. 30. Gohan – NTT opensource SDN/NFV Orchestration 30
  31. 31. Gohan architecture 31
  32. 32. Gohan Policy 32 Policy You can configure API access policy using this resource. Policy has following properties. •id : Identitfy of the policy •principal : Keystone Role •action: one of create, read, update, delete for CRUD operations on resource or any custom actions defined by schema performed on a resource or * for all actions •effect : Allow api access or not •resource : target resource you can specify target resource using “path” and “properties” •condition : addtional condition (see below) •tenant_id : regexp matching the tenant, defaults to
  33. 33. TATA TCS Open VNF Manager 33
  34. 34. Tata TCS Open VNF Manager - github 34 Basic VNF manager On top of OpenStack Using Heat 8 commits Last Aug 2014
  35. 35. YangForge YangForge provides runtime JavaScript execution based on YANG schema modeling language – IETF (RFC 6020). Basically, the framework enables YANG schema language to become a programming language. It utilizes YAML with custom tags to construct a portable module with embedded code. It is written primarily using CoffeeScript and runs on Node.js and the web browser (yes, it's isomorphic). 35
  36. 36. What is it? • A Model-driven Architecture (MDA) software framework for building schema defined software modules Why was it created? • To serve as a rapid prototyping framework for model driven software architecture • To support OPNFV Promise implementation for abstracting ResourceElement(s) of the virtualized infrastructure for state management of capacity and reservations for future usage How does it work? • It uses Metaprogramming techniques to process YANG schema (RFC 6020) files as a software language • It uses Creational Patterns to dynamically construct hierarchy of runtime class objects based on YANG data models What’s the current status? • It’s early stage with working compilers and generators Stormforge
  37. 37. stormforge framework 37 Schema • provides definitions for generating the data models Model/View/Controller • decouples logic layers Data Store • handles record instances of data models Events/Messages • enable reactive control logic integration Interface Layer • auto-generates data model derived interfaces Import/Export • facilitates exchange of data models
  38. 38. stormforge core components 38 meta-class • The core base class that houses the meta-data and enables Class definitions to be mutable yang-compiler • Parses YANG schema text and produces runtime JS class object hierarchy (composed of meta- class) • Implemented based on YANG version 1.0 specifications (RFC 6020) • Provides compile, generate, import, and export facilities (can be used as a server-side API service) storm-compiler • Extensions beyond YANG version 1.0 to introduce complex-types (RFC 6095) • Enhanced resolvers to infuse with data-storm objects providing type validators and model relationships yang-storm • Defines a collection of common data models • Serves as a DataStore for housing schemas, modules, models, controllers, views, and instantiated records
  39. 39. stormforge compiler features 39 Parser parse YANG schema files and generate runtime JavaScript meta-class semantic tree hierarchy Map/Reduce traversal of the parser output to dynamically resolve YANG statement extensions and transform nodes in the tree as well as collapsing them into a final output module Import/Export capabilities to load modules using customizable importers based on regular expressions and custom import routines. Ability to serialize module meta data into JSON format that is portable across systems. Also exports serialized JS functions as part of export meta data. Runtime Generation allows compiler to directly create a live JS class object definition so that it can be instantiated via new keyword and used immediately Dynamic Extensions enable compiler to be configured with alternative resolver functions to change the behavior of produced output
  40. 40. stormforge usage examples 40 Prototyping a new module 1. Write a new YANG schema definition file, such as hello-world.yang 2. stormforge run -p 5000 hello-world 3. curl http://localhost:5000 Validating an external module • stormforge validate • stormforge validate • stormforge run -p 5000 Building/Signing/Publishing a new module 1. stormforge build hello-world 2. stormforge sign -k <keyfile> hello-world 3. stormforge publish --registry=<url> hello-world The steps above can apply for external sources as well
  41. 41. TOSCA vs Yang 41 Defining TOSCA TOSCA is Topology and Orchestration Specification for Cloud Applications. TOSCA’s mission is to facilitate the creation cloud applications and services. TOSCA provides mechanisms to control workflow, describe relationships and reflect dependencies between resources. Defining YANG YANG is a data modeling language used to describe configuration and state information. YANG has been used to model networking devices and services – i.e., an object and its attributes. YANG defines the data models that are then manipulated through the NETCONF protocol. YANG is a modeling "language." YANG provides a way for describing "what a service is." However, YANG is not an orchestration language. YANG does NOT provide a mechanism for describing "what to do." In other words, YANG is not effective for describing how a service should be implemented, the topology of underlying resources, or how resources may be related or dependent upon each other.
  42. 42. XML, Yang, HOT, TOSCA XML, YAML and Yang = languages XML: Extensible Markup Language (XML) is a simple, very flexible text format YAML: “YAML Ain't Markup Language” – inspired by XML but simplified, more readable - data-oriented, rather than document markup. Ex; Sample VNFD Yaml (Tacker example): es/sample-vnfd.yaml YANG: data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (IETF) • XML Templates: HOT and TOSCA HOT: Heat Orchestration Template • Declarative • YAML TOSCA : Topology & Orchestration Standard for Cloud Application (OASIS) TOSCA NFV is refining TOSCA for NFV: https://www.oasis- rev03.doc • Declarative & Imperative • XML and now YAML Ex: Sample TOSCA template in YAML (Cloudify example) clearwater/blob/master/openstack-blueprint.yaml 42
  43. 43. TOSCA principles 43 TOSCA is made of following metadata: - TOSCA Templates: Node, relationship (between node) and Topology - Node Types with Capabilities and requirements - Relationship Types with interfaces and properties - Policies A TOSCA Definitions document MUST define at least one of the elements : ServiceTemplate, NodeType, NodeTypeImplementation, RelationshipType, RelationshipTypeImplementation, RequirementType, CapabilityType, ArtifactType, ArtifactTemplate, PolicyType, or PolicyTemplate Simple example of a Node ‘Compute’ Template
  44. 44. TOSCA data model for a VNF 44 TOSCA for NFV is a new initiative in OASIS That is refining the TOSCA model to map to ETSI NFV model Baseline: TOSCA-Simple-Profile-YAML TOSCA Simple Profile in YAML Version 1.0 ETSI NFV VNF model: (source MANO)
  45. 45. TOSCA VNFD Template 45 Extract/simplified view of the Template: tosca_definitions _version: tosca_simple_profile_for_nfv_1_0_0 topology_template: inputs: subsititution_mappings: node_type: tosca.nodes.nfv.VNF.VNF2 requirements: virtualLink1: [CP21, virtualLink] capabilities: forwarder1: [CP21, Forwarder] VNF2 above has : 3 VDU (VDU1,2,3) = VNFCs 4 CP : 3 (CP22,23,24) for internal VL (inter-VNFV communication) and 1-CP21 to external VL2 CP21: #endpoints of VNF2 type: tosca.nodes.nfv.CP properties: type: requirements: virtualbinding: VDU1 capabilities: Forwarder node_templates: VDU1: type: tosca.nodes.nfv.VDU properties: requirements: - host: node_filter: capabilities: # for selecting “host” (Container Capability) - host properties: - num_cpus: { in_range: [ 1, 4 ] } - mem_size: { greater_or_equal: 2 GB } # for selecting “os” (OperatingSystem Capability) - os: properties: - architecture: { equal: x86_64 } - type: linux - distribution: ubuntu Interfaces: # omitted here for brevity artifacts: VM_image:vdu1.image #the VM image of VDU1 Interface: Standard: configure: implementation: internal_VL type: tosca.nodes.nfv.VL.ELAN Same for VDU1,2,3 CP22 type: tosca.nodes.nfv.CP properties: type: requirements: virtualbinding: VDU1 virtualLink: internal_VL Same for CP23,24 But with VDU2
  46. 46. Parsers & Yang 46 Parser URL Comment Yang to TOSCA (? exists somewhere) TOSCA to Yang Cloudify plug in at least , I think it is also in OpenStack (tbc) TOSCA to HOT (Heat) (OPNFV Parser) enstack/heat- translator Contributed by HPE to OpenStack/OPNFV Parser - Heat-Translator project takes a non-Heat template (e.g. TOSCA flat YAML template or template embedded in TOSCA Cloud Service Archive (CSAR) format) as an input, calls an appropriate Parser (e.g. TOSCA Parser) per the type of input template to parse it and create an in-memory graph, maps it to Heat resources and then produces a Heat Orchestration Template (HOT) as an output. YangForge (OPNFV Promise) nfv/yangforge YangForge provides runtime JavaScript execution based on YANG schema modeling language – IETF (RFC 6020). StormForge mstack/stormforge Contributed by ClearPath – used in promise to model VIM NBI in Yang Yang plug-in for HPE HPSA (HP only) etconfYang Developed by HPE Portugal
  47. 47. Some high level conclusions Fragmented …many opensource pop up with lots of overlap and no dominant Few committers in each, less than 10, less than 5 really active in general but this is not unusual for a small project, still new topic All reference ETSI NFV and MANO (which was still high level though) Most if not all use TOSCA, (check if any use Yang?) Most if not all use Apache 2 licence Most if not all on github Most if not all use Python Most if not all use YAML All support OpenStack 47
  48. 48. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. Thankyou