Analysis of ETSI Vs ONAP API (Focus: ETSI Os-Ma-nfvo reference point) Abinash Vishwakarma(Netcracker) 12, 2017
Agenda Objective and Scope of Analysis NSD Management NSD Lifecycle Management NS Performance Management NS Fault Management VNF Package Management
Objective and Scope of Analysis High-level Objective - Study the ways of harmonizing ONAP with relevant Industry Standards for APIs. Scope (ETSI Os-Ma-nfvo) - Difference of Scope covered by ETSI and ONAP - Key differentiator in the ETSI and ONAP - Gaps and suggestions
NSD Management NSD Management enabled through Os-Ma-Nfvo interface NSD is maintained in NS Catalog There is no API implementation for NSD Management currently in ONAP. NS is designed in SDC based on resources and NSD package is created/stored in SDC Catalog A notification is send over ONAP system bus (DMaaP) to runtime components about the added/updated NSD Package which is pulled into local stores for further processing Observations for each implementation. ETSI NSD Management in ETSI scope is limited to making NSD available to NFVO for use. W.r.t end to end requirement, it is assumed the layer above MANO will create the NSD then pass it to NFVO ONAP NSD Management is a design time activity in ONAP. SDC acts as centralized repository for NSD. SDC Catalog API capability for direct NSD onboarding is not clear in the specification as different terminologies are used in ONAP (for e.g. Asset corresponds to both Service and Resource, but Create Resource API supports only the Virtual and Physical resources, not services for types). SDC distributes the NSD to SO for use through notification APIs. Though there is no standard APIs in place in ONAP but its implementation is more aligned wrt the E2E implementation requirement since it provides the centralized repository for NSD. Logically, distributing the NSD to SO through notification actually maps to ETSI NSD Management APIs scope. of SDC to distribute the APIs to SO is more aligned from E2E scope since there could multiple implementations of MANO/Orchestration in live systems`. SDC should implement the ETSI NSD Management API. ONAP Notification API as exists today is the right approach for making the NSD available to MANO/SO for use.
NS Lifecycle Management NS Lifecycle Management is initiated through the Os-Ma interface from OSS. NS Instances and associated NFVI instances are stored in NS Inventory. NS in ETSI is like a infrastructure services in the ONAP. NS Lifecycle Management is initiated through the External API In ONAP this request can originate from VID or a BSS Emulator or Use case UI or real OSS/BSS integrated with NAP ONAP Service instances are associated with customer (Customer service ) Refer Slide 6 definition of ONAP Services. Observation s for each implementation. ETSI Two step process for creating NS, Create NS Identifier then Instantiate NS. Similarly two step process for deleting the instance Terminate NS followed by Delete NS Identifier NSD reference is part of the Create NS Identifier request. NS Instance ID is created by NFVO. Provision to pass NS name which can be used by North bound system (OSS/BSS). ONAP Scale NS, Update NS, Heal NS operation is not exposed by ONAP SO. A part of Update NS in ONAP is indirectly supported by create VNF instance. Two step process as defined by ETSI is good approach. This approach could be used to retain the NS identifier in case it is required to recreate the instance due to some issues. Though ONAP doesn t support Scale NS but can be achieved indirectly by deleting or creating VNF instance which is contained within the NS. ONAP NS does not support PNFD directly and does not have any operations for PNFD onboarding, but enables this through an Allotted Resources which can refer to a PNF instance
NS Performance Management As per ETSI MANO Architecture the NS level Performance is managed by the NFVO VNF level, VM level and NFVI level Performance statistics is consolidated at NS level in NFVO ONAP currently does not support NS level Performance Management. Currently only a VNF level Performance management is supported through DCAE. MultiVIM also does not have capability to collect telemetry data from VIM Network and VNF level telemetry data is expected from Controller FW DCAE collects the events through VES collector and correlated events are forwarded to Policy. Policy verifies the policy associated with the event and sends notification to PEP ( NS level correlation and policy based notification is not supported currently) Not supported currently Observation s for each implementation. ETSI A single job is able to collect the performance of one or more NSs. There is no provision to add/remove NSs in the running job. Threshold is associated with 1 instance. This will mean for each instance threshold need to be managed separately. Better to have a threshold group kind of implementation which can reduce the APIs call. In ETSI there is a recommendation ETSI GR NFV-IFA 023 V3.1.1 (2017-07) which suggests to implement the policy framework within MANO. This might consume the events managed by NS Performance Management engine. ONAP ONAP DCAE implements the performance management but is limited to VNF Performance management. In ETSI the VNF performance management is in the scope of VNFM. Os-Ma-nfvo reference point only implements the performance monitoring for NS. There is no scope to update the list of NSs in the running job. This could be useful to add/remove the instances from the running PM job list. In order to add the newly created NS instance either the integration framework need to have information to automate the addition after creation of NS or can be achieved by enhancing the Insatiate APIs to include the optional parameter of including the PM Job name in the API name itself. PM Configuration at VNF/VIM and NFVI level need to be configured before PMJob can be initiated. This may be carried out through CM task, but with reference to the model that is onboarded for NS and VNF.
NS Fault Management As per ETSI MANO Architecture the VNF level, VM level and NFVI level Performance statistics is consolidated at NS level in NFVO In ONAP NS level fault correlation is not supported yet Currently only VNF level faults are received by the Not supported currently Observation s for each implementation. ETSI Alarms are associated with NS instance. It is possible to specify the filter criteria to identify the instances to be notified corresponding to the alarm. ONAP ONAP DCAE implements the NS Fault Management but is limited to VNF Fault management only based on Alarms conf. Alarm management interface yet not covered completely by ETSI MANO. If not defined by ETSI MANO yet then its future implementation might impact the existing interfaces. Like there must be some kind of association with NS instance and Alarms list.
VNF Package Management VNF Package Management handled by NFVO through Os-Ma interface VNF Package Submitted to VNF SDK where it is validated and certified Certified VNF Package is downloaded to SDC by Service Designer and loaded to Catalog during NS Design During NS Distribution, notification is sent to SO and NS and VNF Packages are downloaded by SO. Other components use the artifacts in NS/VNF Packages VNF Package Submitted by Vendor for Certification Observation s for each implementation. ETSI Scope is limited to make the VNF Packages available to NFVO for use. It is assumed that the application above MANO will manage the centralized repository of VNF Packages from E2E requirement perspective. ONAP SDC component in the ONAP is centralized repository for the VNF Packages. ONAP SDC Catalog API indirectly supports few capabilities w.r.t VNF Package Management. While direct CSAR onboarding to SDC Catalog is not supported, other operations like Query,Fetch operations for VNF Package and associated artifacts are supported. SDC distributes the VNF packages to SO through notification interface for use. SDC need to implement all the APIs of VNF Packages as mentioned by ETSI. From E2E perspective the centralized repository and distribution of VNF packages by SDC in ONAP is good approach.