ARC: Definitions and requirements for SO/APP-C/VF-C discussion including call notes Chris Donley July 5, 2017

Agenda Review of ONAP Architecture Principles Definitions Goals/discussion questions Possible Deployments Vimal

Proposed ONAP Architecture Principles (For Review – from May Developer meeting) Support Complete Life Cycle Management of Software Defined Network Functions / Services From VNF On-Boarding, Service Definition, VNF/Service Instantiation, Monitoring, Upgrade, to retirement High Level of Automation at Every Phase of Life Cycle Management – e.g. Onboard, Design, Deployment, Instantiation, Upgrade, Monitoring, Management, to end of life cycle: Rich, User Friendly Design Studio to Capture Full Life Cycle Management (Recipes, Policy, Analytics, etc.) Common Approach to Manage Various Network Functions from Different Vendors Standard templates for instantiations Standard language for configuration Standard Telemetry for monitoring and management ONAP Platform is NF / Services / Product Agnostic (each service provider / integrator to use ONAP to manage their specific environment with artifacts created via Design Studio) Standard Interfaces for Integrating with External OSS / BSS / VNFM/ EMS systems Standard interfaces / abstraction layer to support multiple infrastructure and network controllers Maintain ONAP Platform Integrity while Evolving it to Target End State Vision Maintain Platform Backward Compatibility with Every New Release Call note: Jason also drew our attention to: https://wiki.onap.org/display/DW/Draft+Architecture+Principles Roberto to send further suggestion on item 2.1.

Definitions Orchestration - Wikipedia Service Orchestrator - Mulesoft Aligning business request with applications, data, and infrastructure Service Orchestrator - Mulesoft The coordination and arrangement of multiple services exposed as a single aggregate service NFV Orchestrator (NFV-O) - Mehmet Ersue (ETSI NFV MANO Co-Chair at IETF 88)  coordinates, authorizes, releases and engages NFVI resources on-boarding of new Network Service (NS), VNF-FG and VNF Packages NS lifecycle management (including instantiation, scale-out/in, performance measurements, event correlation, termination) global resource management, validation and authorization of NFVI resource requests policy management for NS instances VNF Manager (VNFM) – Mehmet Ersue lifecycle management of VNF instances (including instantiation, scale-out/in, termination, etc.) overall coordination and adaptation role for configuration and event reporting between NFVI and the E/NMS Controller - Margaret Rouse, Techtarget configure network devices and choose the optimal network path for application traffic Notes from the call: We acknowledged language difficulties crossing between domains (particularly vis. Controller/manager). We agreed to use ‘controller’ for both ‘controller’ and ‘manager’ for now, but could revisit if we need to in the future.

Goals and Questions Questions (Goals? Non-goals?) Goals Flexibility for operator deployment Minimize impact to different components (e.g. DCAE, A&AI) Some impacts to SO and possible SDC Minimize impact to VNF vendors VNFSDK will publish unified VNF specification format and adapt as needed to work with ONAP components We expect the architecture to evolve over time, and this may impact VNF vendors Align with ONAP charter Capable of delivering for R1 Microservices-based Questions (Goals? Non-goals?) Avoid replication of functionality? ETSI MANO alignment? Feature parity between APP-C/VF-C? Modular? Well-defined interfaces? Notes from the call: We agreed that modular, well-defined interfaces are a key requirement. We might not get there in R1, but This needs to be our target for R2. We do generally want feature parity, but it will not be a blocking issue if there is some divergence. We generally want ETSI alignment, but it will not be blocking. We want to minimize replication of functionality (long-term); some will be acceptable as it allows innovation. Since R1 timelines are short, we might accept more initially as we work through the integration.

Functional Definitions Note: the following definitions apply to functions, not ONAP modules. Modules will be referred to by their acronyms for clarity (e.g., SO, APPC, VFC) Service Orchestrator is responsible for decomposing a complex network service into its constituent parts. Decompose service template into connectivity and application components Call controllers/managers to configure the network and instantiate VNFs Notes from the call: we did not proceed beyond here, as we ran out of time. Please review these (and the mapping to be sent by Vimal) for discussion next time.

Functional Definitions (2) NFV orchestrator (including Resource Orchestrator) Management of Network Services deployment templates and VNF Packages (e.g. on-boarding new Network Services and VNF Packages). During on-boarding of NS and VNF, a validation step is required. To support subsequent instantiation of a NS, respectively a VNF, the validation procedure needs to verify the integrity and authenticity of the provided deployment template, and that all mandatory information is present and consistent. In addition, during the on-boarding of VNFs, software images provided in the VNF Package for the different VNF components are catalogued in one or more NFVI-PoPs, using the support of VIM. Network Service instantiation and Network Service instance lifecycle management, e.g. update, query, scaling, collecting performance measurement results, event collection and correlation, termination. Management of the instantiation of VNF Managers where applicable. Management of the instantiation of VNFs, in coordination with VNF Managers. Validation and authorization of NFVI resource requests from VNF Managers, as those may impact Network Services (granting of the requested operation needs to be governed by policies). Management of the integrity and visibility of the Network Service instances through their lifecycle, and the relationship between the Network Service instances and the VNF instances, using the NFV Instances repository. Management of the Network Service instances topology (e.g. create, update, query, delete VNF Forwarding Graphs). Network Service instances automation management (e.g. trigger automatic operational management of NS instances and VNF instances, according to triggers and actions captured in the on-boarded NS and VNF deployment templates and governed by policies applicable to those NS and VNF instances). Policy management and evaluation for the Network Service instances and VNF instances (e.g. policies related with affinity/anti-affinity, scaling, fault and performance, geography, regulatory rules, NS topology, etc.). Validation and authorization of NFVI resource requests from VNF Manager(s), as those may impact the way the requested resources are allocated within one NFVI-PoP or across multiple NFVI-PoPs (granting of the requested resources is governed by policies, and may require prior reservation). NFVI resource management across operator's Infrastructure Domains including the distribution, reservation and allocation of NFVI resources to Network Service instances and VNF instances by using an NFVI resources repository, as well as locating and/or accessing one or more VIMs as needed and providing the location of the appropriate VIM to the VNFM, when required. Supporting the management of the relationship between the VNF instances and the NFVI resources allocated to those VNF instances by using NFVI Resources repository and information received from the VIMs. Policy management and enforcement for the Network Service instances and VNF instances (e.g. NFVI resources access control, reservation and/or allocation policies, placement optimization based on affinity and/or anti-affinity rules as well as geography and/or regulatory rules, resource usage, etc.). Collect usage information of NFVI resources by VNF instances or groups of VNF instances, for example, by collecting information about the quantity of NFVI resources consumed via NFVI interfaces and then correlating NFVI usage records to VNF instances.

Functional Definitions (3) VNFM VNF instantiation, including VNF configuration if required by the VNF deployment template (e.g. VNF initial configuration with IP addresses before completion of the VNF instantiation operation). VNF instantiation feasibility checking, if required. VNF instance software update/upgrade. VNF instance modification. VNF instance scaling out/in and up/down. VNF instance-related collection of NFVI performance measurement results and faults/events information, and correlation to VNF instance-related events/faults. VNF instance assisted or automated healing. VNF instance termination. VNF lifecycle management change notification. Management of the integrity of the VNF instance through its lifecycle. Overall coordination and adaptation role for configuration and event reporting between the VIM and the EM.

Module mappings SO: APPC VFC DCAE Policy Service Orchestrator a&b NFV Orchestrator a, c, d, j, k, l APPC NFV Orchestrator b, g, h VNFM a-k VFC NFV Orchestrator a-n VNFM a-k (optional – using OPEN-O G-VNFM; other gVNFM or sVNFM possible) DCAE NFV Orchestrator b, n VNFM f Policy NFV Orchestrator i, m

Possible deployments

ONAP Controller – Option A (ONS starting point) Service Orchestrator New Current APP-C NBI Os-Nfvo APP-C VF-C Or-Vnfm OpenStack/MultiVIM API VNFs

ONAP Controller – Option B (Jamil) Service Orchestrator New Os-Nfvo VF-C Or-Vnfm APP-C New APP-C as VNFM OpenStack/MultiVIM API VNFs

ONAP Controller – Option C (Vimal Option 2) Service Orchestrator Current APP-C NBI APP-C New Os-Nfvo VF-C Or-Vnfm OpenStack/MultiVIM API VNFs

ONAP Controller – Option A1 (runtime selection) Service Orchestrator APP-C VF-C VNFs

ONAP Controller – Option A2 (runtime selection) Service Orchestrator APP-C VF-C VNFs