ONAP & ETSI NFV converged architecture Jamil Chawki, Bruno Chatras, Eric Debeau & Olivier Le Grand Orange Gil Bullard, Vimal Begwani AT&T Stephen Terrill Ericsson Anatoly Andrianov, Denes Nemeth Nokia

Alignment: Motivation and Meaning Alignment Motivation: Increase industry adoption of Automation through defragmentation and focus. Alignment Meaning: Alignment is when ONAP can call a realizations of ETSI-MANO functions (scenario 1) or ONAP can be considered (for the relevant scope) a realization of ETSI-MANO and exposes its external interfaces (scenario 2). Alignment Scenarios Scenario -1: ETSI components “Plug in to” ONAP Plug in the ETSI NFVO into the ONAP architecture Plug in the ETSI VNFM into the ONAP architecture Takeaway: There are different definitions of “alignment,” each of which has valid business scenario from some perspective. We must be clear what aspect we are discussing in order to communicate effectively. Scenario-2: Realize ETSI functionality external MANO interfaces via ONAP. Realize the ETSI NFVO functionality via ONAP Realize ETSI VNFM functionality via ONAP Both are valid approaches and valid business scenarios to address

ETSI NFV MANO architecture: interfaces & operations SOL005 NSD Management NS Lifecycle Management NS Performance Management NS Fault Management VNF Package Management NSD/VNFD: SOL001 VNF Package: SOL004 Os-Ma-nfvo OSS/BSS NFVO SOL003 VNF Lifecycle Operation Granting VNF Package Management Virtualised Resources Quota Available Notification SOL002 VNF Lifecycle Management VNF Performance Management VNF Fault Management Or-Vnfm SOL002 VNF Indicator SOL003 VNF Lifecycle Management VNF Performance Management VNF Fault Management VNF Indicator VNFM EM Ve-Vnfm-em VNF Ve-Vnfm-vnf SOL002 VNF Indicator VNF Configuration SOL002 VNF Lifecycle Management VNF Performance Management VNF Fault Management © ETSI 2017. All rights reserved

ETSI NFV Reference Point decomposition Stage 2 Stage 3 Stage 2 Stage 3 Os-Ma IFA 013 SOL 005 Or-VNFM IFA 007 SOL 003 VNF Lifecycle operation grant Virt Resource Quota Avail Not VNF Performance Management NS Performance Management VNF Lifecycle Management VNF Package Management NS Lifecycle Management VNF Fault Management NS Fault Management NSD Management VNF Management VNF Indicator Takeaway: The SOL005 and SOL003 Reference Points are not monolithic and can be functionally decomposed into a set of protocols. Each functional subset can be hosted by a separate functional sub-component. NFVO VNFM NSD Mgt VNFP Mgt NS PM NS FM NS LCM VNF LCM VNF Indicator VNF PM VNF FM Note: Same applies to SOL002

Example of an ONAP implementation Takeaway: The ONAP functional components (SO, DCAE, SDNC, etc) will be evolved over time to be collections of microservices that communicate with each other via the Data Movement/Microservices bus. Thus, ONAP support for a SOL005 API (for example) implies that there exist microservices that expose that SOL005 API functionality. Because SOL005 can be functionally decomposed, it is quite acceptable that a given ONAP microservice exposes only one of the decomposed “sub-function” (APIs) of SOL005, as long as collectively there exist a set of microservices that together provide the full SOL005 functionality. From the perspective of realizing the SOL005 APIs, it is not necessary that this collection of microservices all exist within what ONAP considers to be a single ONAP functional component (e.g., Orchestration).

Gen NFC microservice interacting with Adaptor Approaches Gen NFC microservice interacting with Adaptor Could be a collection of microservices across multiple ONAP components (SO, DCAE, etc) supporting the (perhaps evolved) SOL005 API SO function ONAP SOL002 ETSI-Compliant VNF SOL005 Realize (Scenario 2) But ONAP may not need to implement the formal SOL003 APIs ONAP Realizing an NFVO ONAP Realizing a VNFM SOL003 functional equivalent Adaptor External VNFM Plug In (Scenario 1) ETSI-Compliant VNF SOL002 EM propriety VNFM Adaptor SOL003 ONAP Calling a VNFM Takeaway: This slide uses animation. A useful though abbreviated “Realization” of an ETSI implementation would have ONAP “realize” the equivalent functionality of an NFVO+VNFM implementation, exposing the external collective APIs of each. Specifically, ONAP would need to expose SOL005 as a northbound API and SOL002 as a southbound. In such a scenario, ONAP would implement equivalent functionality of an NFVO via a collection of microservices (shown in purple) which would expose a SOL005 APIs. ONAP would also implement equivalent functionality of a VNFM via a collection of microservices (shown in blue) which would expose a SOL002 APIs. But ONAP may not need to implement the formal SOL003 APIs as an internal interface, though presumably there would be a collection of microservice to microservice interactions that could functionally be mapped to SOL003 equivalent functionality. A “plug in” of a VNFM into ONAP would rely on a VNFM Adaptor that would itself “plug in” along this “functional equivalent” boundary, and which would handle any peculiarities of the SOL003 interactions (e.g., handling the “Grant” request interactions). The implementation of such an approach would likely involve SOL005-supporting microservices across multiple ONAP components (SO, SDC, DCAE), SOL002-supporting microservices in the Gen NFC leveraging an Ansible playbook, and other functionality, and an SO orchestration function implementing the VNFM Adaptor itself.

Instantiate Example: Scenario 1, VNFM Plug In Takeaway: Implement a “Plug In” of a VNFM such that ONAP can perform that functionality that is outside of the scope of the VNFM. For example: For a “plugged in” VNFM, ONAP OOF will perform homing, SDNC make assignments, and Gen NFC apply application level configuration. Leverage ONAP telemetry collection (DCAE) and analytics (Policy) to determine the need to scale and the scale increments, and disable in the VNFM the “auto- scale” capability. (VNFM will support “Scale” and “ScaleToLevel”.) ONAP would delegate the appropriate functionality to the entity (a black box) on the other side of the VNFM Adaptor. The SDC model would indicate whether a particular Service/VNF should have some of its management functionality delegated via this API, in this example the interactions with the VIM to create the cloud resources.

Example of converged architecture Scenario-2: Realize ETSI functionalities & external MANO interfaces via ONAP Example of converged architecture NFVI VIM Network Application Controller* E2E Orchestrator* DCAE Other OSS functions Inventory Service Catalog (NSD & VNF Package) Physical Infrastructure Functional Block L1-2-3 PNFs L1-2-3 VNFs L4-L7 PNFs L4-L7 VNFs SBA * Further study is required on how to rationalize the ONAP SO and Controller functions with the ETSI NFVO and VNFM functions, and on their decomposition Takeaway: ONAP and ETSI-MANO alignment is a two way activity. Some ETSI-NFV members are considering creating a SBA work-item in ETSI-NFV which could be an opportunity further alignment with ONAP from the ETSI-NFV perspective as well. This can consider reviewing and decomposing the existing functional entities in ETSI-NFV more aligned with ONAP. In figure provided is just an example and more work is required. Reviewing the functionality and architecture in both ETSI-NFV and ONAP is required. Some ETSI-NFV members are considering creating a SBA work-item Opportunity for further alignment by reviewing Functional blocks

Next Steps Scenario-1: Plug-in Scenario-2: Realizing Evolve details on the interface between ONAP and plugged in VNFM, and implications on the adapter Evolve the details on the interface between ONAP and the plugged in NFVO and implications on the adapter Plan for ONAP Rel-C. Scenario-2: Realizing Work to define the set of ONAP Microservices that would support the ETSI- NFV external APIs Plan for ONAP Rel-C/D. Create a joint expert group between ONAP and ETSI NFV to progress the work

Thank You

Scope of ETSI Relative to Scope of ONAP ONAP and ETSI have differing scopes, with ETSI scope being a proper subset of ONAP scope ONAP Functional Scope BSS/OSS NFV Orchestrator (NFVO) EM VNF NFVI Virtualised Infrastructure Manager (VIM) NFV Service Catalog VNF Catalog NFV Instances NFVI Resources VNF Manager (VNFM) Os-Ma-nfvo Ve-Vnfm-em Ve-Vnfm-vnf Nf-Vi Vn-Nf Vi-Vnfm Or-Vnfm Or-Vi ETSI Functional Scope Intersecting Scope

ETSI NFV Architecture: point to point representation Dedicated interface & protocol between Functional Blocks SOL 005 Network Service Management Manage combinations of connected VNFs, PNFs and nested NSs OSS/BSS Os-Ma-nfvo NFV Orchestrator (NFVO) SOL 003 NS Catalog VNF Catalog NFV Instances NFVI Resources Or-Vnfm SOL 002 Ve-Vnfm-em EM VNF Manager (VNFM) VNF Management  Manage individual VNFs Ve-Vnfm-vnf SOL 002 VNF Vi-Vnfm Vn-Nf Virtual Resource Management  Manage the use of NFVI resources Virtualised Infrastructure Manager (VIM) Or-Vi NFVI Nf-Vi NFV-MANO

OSS/BSS NFVO VIMs VNF VNFM NSD Mgt VNFP Mgt NS FM NS PM VNF LCM VNF PM SOL005 NS & PNF Instances repository NFVI resources view OSS/BSS VN & NFP Mgt NS LCM Resource Reservation NSD Mgt LCM Granting Resource Capacity Management VNFP Mgt NS FM Software Image Management NS PM Quota Mgt NFVO SOL003 VNF VIMs VNF LCM VNF Instances repository VNF PM VNF FM VNF Indicator SOL API VNFM VNF Configuration Producer Consumer OpenStack SOL002

Evolving ETSI NFV to Service-Base Architetcure NFVO & VNFM can be further decomposed as show in previous slide, The SBA approach is intended to facilitate  communication between elementary functions irrespective of the software implementation/packaging SBA SBA Service-Based Architecture RDF Registration and Discovery function

ETS NFV Functional sub blocks

FM/PM The NFVO can: The VNFM can: Gather VNF-level FM/PM information from VNFMs and VL-level FM/PM information from the VIMs. Correlate FM/PM information with NS instances Provide NS-level FM/PM information to the OSS/BSS Trigger LCM actions on receipt of FM/PM information The VNFM can: Gather resource-level FM/PM information from the VIMs Correlate FM/PM information with VNF instances Provides VNF-level FMP/PM information to the NFVO and VNF/EM instances

NSD and VNF Package management The NFVO can: On-board NSDs, PNFDs and VNF Package upon request of the OSS/BSS Distribute software images extracted from VNF Packages to the VIMs Create and manage Compute Flavours in the NFVI, via the VIM. The VNFM (LCM) can: Retrieve the VNFD and other VNF package elements from the NFVO

NS LCM The NFVO can: The VNFM can: Manage the LC of the virtualised resources for NS instances Delegate the LCM of virtualized resources for VNF instances to VNFMs while retaining control through the Granting procedure Request VIMs to create virtual networks for interconnecting VNF instances The VNFM can: Manage the LC of the virtualised resources for VNF a instance Request permission (Grant) from the NFVO before performing an LCM operation

Focus on Granting The Grant response contains: The list of resources approved to be added/modified/removed Information about the VIM(s) to use for allocating resources to a VNF instance The NFVI Zone(s)/ ZoneGroup(s) where to allocate resources Reservation identifiers (of resources have been reserved) List of compute flavours and software images to use. List of external VLs to connect the VNF instance (incl. Connection Points address configuration). (*) List of VNFs internals VLs not managed by the VNFM (*) (*) can also be provided in LCM operation request