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

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

3. 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 All rights reserved

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

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

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

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

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

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

10. Thank You

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

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

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

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

15. ETS NFV Functional sub blocks

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

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

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

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