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

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

3. 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:
Roberto to send further suggestion on item 2.1.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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

10. Possible deployments

11. 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

12. 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

13. 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

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

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