1. June 20–23, 2016 | Berlin, Germany

2. MANO Modeling: Service, Infrastructure and VNF On-Boarding and Interoperability Uri Elzur, Intel Bryan Sullivan, AT&T Artur Tyloch, Canonical

3. Abstract MANO is one of the critical layers for NFV realization, yet industry direction on it is in danger of diverging. Along with closed implementations, open source projects such as OSM and Open-O are now driving MANO implementation. To help drive broad convergence and ease Service development, VNF on-boarding, and interoperability, we need broad agreement on Information Models and Data models. We will present a proposal to use TOSCA/YANG as a basis for this, and report on efforts in OPNFV to validate and promote convergence in support for model-driven Service and VNF deployment on the OPNFV platform. This talk will be supplemented by a demo of the current work in OPNFV to be presented in the demo theater.

4. Outline MANO snapshot and goals Data Model and VNF on boarding agreement and interoperability Why Model Infrastructure, Services, Network Functions Model Standards and Tools Across the MANO Stack Modeling Topology, Resources, Policy, and Lifecycle OPNFV’s Model-Driven NFV Project Current State of Modeling Support and Interoperability Case Study: JuJu as a Model-Driven VNF Manager Q&A

5. The MANO Situation… A critical component and yet a major NFV deployment obstacle Role: NFV Service instantiation and Provisioning Role: NFV Service instantiation and Provisioning A critical component and yet a major NFV deployment obstacle Role: NFV Service instantiation and Provisioning Role: NFV Service instantiation and Provisioning NFV unmet needs: Automation. Basic Interoperability Service requirement based Resource provisioning. Analytics assisted trouble shooting. VM failure identification / healing. HA & Scaling. Security Network aware placement. NFV unmet needs: Automation. Basic Interoperability Service requirement based Resource provisioning. Analytics assisted trouble shooting. VM failure identification / healing. HA & Scaling. Security Network aware placement. Industry Snapshot Silos, incompatible Info and Data models Proprietary OSS/BSS integration Limited PNF support Emerging Multi VIM Emerging Multi Site Industry Snapshot Silos, incompatible Info and Data models Proprietary OSS/BSS integration Limited PNF support Emerging Multi VIM Emerging Multi Site

6. EPA Telemetry Policy MANO Goals Goal: Telco functional, efficient, exchangeable and interoperable, MANO + VIM Means: DM interop + Stable API Means: augment VIM, evolve VIM Goal: multi VIM, multi Site interoperable MANO Means: Stable VIM API + e2e SDN Goal: most efficient infrastructure with Security, SLA Means: EPA + Policy to Platform Goal: enable successful NFV in an increasingly divergent industry Goal: low barrier to VNF development, on-boarding and SLA assurance Means: achieve industry wide MANO+VIM, TOSCA/YANG DM interop Means: interoperable on-boarding supported by VNF vendors Infra structure

7. Resource Orchestration and Modeling Servers & Hypervisor Resource Orchestration Virtual Network Function VM Infrastructure as a Service VIM Cloud/SDN NFV Resource Orchestrator needs to  Know what infrastructure capabilities are  What is required to optimally / functionally support each VM Requests resources from the relevant VIM, which then allocates logical and physical resources from a managed pool This allows optimal resource utilization, SLA and Service assurance and leads to a lower and competitive cost per VM! REQUIRED: Model of the requested Service, VNF and Infrastructure

8. Priority: Experiment, Interoperate, Standardize Comms Innovation Compliance and Stability Standard Data Model Software 1 1 2 2 Cloud Innovation “Fail Fast”, Low-Cost Iteration Software Data Model Standard 1 1 Cloud-Pace Innovation for Comms Standardized Data Model Data Model Software Standard 1 1 2 2 2 2 Network and Cloud Friendly Data Models Modular Code Clear Layering Descriptor Ownership

9. Standard Information Model Evolution Resolve Architectural ambiguities E.g. VNFC and VDU role / duplicity External and internal connections role in the hierarchy (especially vs a VNFC) Extend ETSI for more infrastructure awareness, SLA and efficiency e.g. Enhanced Platform Awareness (EPA) Network Capability/Availability awareness e.g. vSwitch acceleration options Allow for choice of NFV-O and VNFM role Monolith Separate NFV-O and VNFM Separate NFV-O, Generic VNFM and VIM specific VNFM Allow for Vendor proprietary extensions Information Models, Data Models and languages Broad support for One “canonical” Data Model TOSCA/YANG Data Model Cross Translator as part of the model – enable many Data Models Support TOSCA YAML, YANG, CIM/OVF, SID

10. NFVO Architecture, Interfaces and Modeling JOINT GOAL: make it as easy as possible to Develop, Deploy and Manage VNFs! With Predictable Results, Fault Handling, HA etc. NFVI Resource Orchestration (RO) VNF deployment SDN Controller VNFM AWS VNFM VIM VMware openstack vIMSvSmallCell vPE vEPC vCPE/vB RAS EMS Container Service Orchestration (SO) NSD VNFD VNF FGD VDU API Data Model Agreement Elements ServicesServices InfrastructureInfrastructure VNFVNF API stability especially NB VIM and NB MANO

11. VNF On-Boarding A Major Problem for Operators (Consumer) and VNF Vendors (Providers), today Highly manual – require a combined operator/vendor team to manually configure the platform for VNF to run on Time consuming – takes a long time and requires the entire procedure to be repeated in case of error Lacking way to specify Infrastructure requirements No formal way for a VNF to ask for resources and ensure they can be and will be granted at install and reserved thru operation Limited security, isolation, scalability, self healing – VIM & VNF specific Efficiency: in many cases, no other VNF runs on the same platform Operator, VNF vendor and VIM specific – procedures are specifically tailored to each VIM infrastructure, operator and VNF vendorGOALS 1.Low effort and “standard” VNF package definition processes 2.Automate VNF initial on-boarding processes 3.Automatically ensure capability of required VIM & infrastructure resourcesProposal Industry agreement for VNF on-boarding standardization and InteroperabilityIndustry agreement for VNF on-boarding standardization and Interoperability Support resources required, KPI, basic VNF operations in TOSCA Support resources required, KPI, basic VNF operations in TOSCA Support YANG network devices by translation into TOSCA Support YANG network devices by translation into TOSCA Allows automatic on-boarding and matching of VNF to a VIMAllows automatic on-boarding and matching of VNF to a VIM

12. Why Model Infra, Services, Network Functions Traditional design methods are poorly matched to NFV needs for Agile development and deploymentAgile development and deployment Automation at every levelAutomation at every level Diverse infrastructure targetsDiverse infrastructure targets Optimized use of infrastructureOptimized use of infrastructure Microservice deployment modelMicroservice deployment model Declarative (vs imperative) methods are superior for these needs Imperative methods can be called for functions without declarative supportImperative methods can be called for functions without declarative support Composing complex systems from components and their attributes, relationships, etc promotes reuse and multi-level abstraction Infrastructure modeling can provide similar benefits as gained thru modeling services and their component network functions

13. OPNFV’s Model-Driven NFV Project Inspired by the Multi-SDO Information Modeling Workshop Collaborative touchpoint for OPNFV to the Multi-SDO Workshop and IISOMI Focused on Gathering info on and assessing modeling state-of-the-art/standards Developing TOSCA+YANG based blueprints (NSD, VNFD) for inclusion in FuncTest Testing these blueprints across all available open source NFVO/VNFM products Feeding back issues and priorities to the SDOs So far, the project has Established a wiki home for the project and actively collecting background informationwiki home Provided a forum for collaboration with cross-SDO IM initiatives Started work on simplified blueprint testing based upon the vIMS example Goal for OPNFV Colorado A simple TOSCA-based NSD/VNFD blueprint, tested across existing VNFMs on OPNFV Include those VNFMs that pass the test in OPNFV FuncTest

14. Cross-SDO and Open Source Collaboration Multi-SDO Workshop organized by ETSI NFV (Jan 2106, Louisville) Good information sharing; see ETSI Open Documents Repository ETSI Open Documents Repository Work in progress on some identified issues (e.g. IM touchpoints) Continuing as the adhoc “Information Modeling Expert Group” Informal Inter-SDO Open Model Initiative (IISOMI) Organized by the ONF EAGLE projectONF EAGLE project Informal governance body for maintaining the Open Model profile, guidelines and tools, etc Can be extended to discussion on common Core Models over time 2 initiatives started on Multi-SDO Information Models

15. Model Touchpoints and Key Aspects Topology Defines distribution of functions and connections between them, e.g. based upon relationships or explicit network links Resources Defines compute, storage, network resources needed, including attributes of those resources Policy Defines goals for policy- driven systems, e.g. for resource orchestration (placement, scaling…), performance, security, lifecycle event handling Lifecycle Enables hooks to modeled event handling, or scripted event handling as necessary (e.g. for non- modelable events)

16. Model Standards and Tools Across the MANO Stack IFA007 (Or-Vnfm Reference Point Spec) IFA008 (Ve-Vnfm Reference Point Spec) IFA011 (VNF Packaging Spec) IFA014 (NS Templates Spec) IFA015 (NFV Information Model) IFA016 (Papyrus Guidelines) NFV IFA017 (UML Modeling Guidelines) ONF’s EAGLE Project (Open Model Profile and Tools) OASIS TOSCA Simple Profile for NFV v1.0 ONF Services Area: Information Modeling

17. Generic Modelling VNFs

21. Model Standards and Tools Across the MANO Stack OpenStackOpen-O VIM OSM OpenVIM…. Same VNF on different NFVIs

22. NFV In Action - EPC with Performance Testing OpenAirInterface EPC Ixia IxLoad Wireless Juju gVNF manager Ubuntu OpenStack Model by DataArt Model By:

23. Summary and Call to Action Help drive industry agreement on Data Models Ease and accelerate Service development, VNF on-boarding, and interoperability! Suggest use TOSCA/YANG as the basis Collaborate with the OPNFV Models project Help validate and promote convergence in support for model-driven Service and VNF deployment on the OPNFV platform.