1. Zhipeng (Howard) Huang huangzhipeng@huawei.com
DPACC encounters OpenStack
Zhipeng (Howard) Huang
v1.1

2. ETSI NFV/OPNFV The Initial scope of OPNFV is VIM + NFVI
According to GS NFV MANO, VIM:
Orchestrating the allocation/upgrade/release/reclamation of NFVI resources, and managing the association of the virtualized resources to the physical compute, storage, networking resources. Therefore, the VIM keeps an inventory of the allocation of virtual resources to physical resources.
Managing in a repository inventory related information of NFVI hardware resources and software resources, and discovery of the capabilities and features of such resources.
Management of catalogues of virtualized resources that can be consumed from the NFVI.

3. OPNFV DPACC-MAN VNFs VIM According to GS NFV IFA 004 0.1.1
the type of NFV Acceleration deployment varies from an integrated deployment (i.e. a deployment where the NFV Accelerators are packaged within a specific VNF, or physically integrated within a specific host), to a disaggregated deployment (i.e., a deployment where the NFV Accelerator is either physically decoupled from a specific host, and shared between two or more NFVI compute or networking resources, or pluggable software which could be shared between VNFs), the management aspect of the NFV Acceleration focus on the latter one in the current release of the document.
Therefore in DPACC when dealing with VIM, it means:
Orchestrating virtual acceleration resource that is within the realm of NFVI, which is represented via a common acceleration API that accesses both hardware and software accelerators.
Managing a repository inventory with regard to both hardware and software accelerators.
Managing a catalogue of virtualized acceleration resources can be consumed from NFVI.
VIM
NFVI
Acceleration HW
Acceleration SW
Acceleration API
Virtual Acceleration
VNFs
Out of Scope of DPACC mgmt concern:
Accelerators embedded within VNF
What and How should NFVO/VNFM do to manage acceleration resource based on NSD/VNFD

4. From DPACC-MAN to OpenStack – General Concerns
OpenStack is a VM centric IaaS platform that provides an abstraction of underlying heterogeneous hardware and software infrastructure components, from management point of view. (= VIM)
In order to implement requirements from DPACC- MAN to OpenStack:
Nova needs to be aware of the acceleration resources, and correlate them to VMs (VNFs).
Cinder needs to have a driver that could talk to the acceleration-api on storage side (not a priority right now).
Neutron needs to have a plugin that could talk to the acceleration-api on networking side.
Keystone needs to be aware of the tenant info correlation
Would that be all?

5. More caveats: Problem #1: Multi-tenancy
As shown in the figure on the right, which is from GS NFV IFA , although we would define a common acceleration API, there are a lot of types of accelerators and vendor specific solutions to that certain type underlay that API.
While multi-tenancy is common in cloud, when we deal with accelerations, we specifically want to make sure that certain VNF’s operation on the shared acceleration resource (one or more accelerators from different vendors), won’t affect other VNFs that are also using it.
In another word, the operations on the acceleration resource need to be atomic. VIM needs to support these atomic operations (not necessarily carry out these operations).

6. More caveats: Problem #2: Distributed State Mgmt
Although we could solve problem #1 with a typical DB that stores the states and the operations of a transaction that involves VNF and Acceleration Resource in NFVI, we still need to take into account that in reality we might have multiple VNFs that belongs to the same network service, running on different servers, with different accelerators associated.
Therefore we need a distributed state datastore that would provide a unified view on the acceleration resource pool, which may be consisted of different accelerators from different locations. (Eventual consistency would be enough)
Then it could support scenarios like VM migration, where states of acceleration resources relate to certain VNFs are synced properly to make migration work.
This will require a sub/pub mechanism to work.

7. From DPACC-MAN to OpenStack – High Level DB Architecture
Acc DB
Inventory DB
Catalogue DB
Nova
Cinder
Neutron
Keystone
Acc DB
Acc DB
Acc DB
Inventory DB : the state datastore that maintains overall acceleration resource state
Catalogue DB : the config datastore that stores information such as version, performance, capability, compatibility and so forth.
RabbitMQ

8. From DPACC-MAN to OpenStack – Work Proposal Overview
Baby Steps first:
Nova : be aware of the acceleration resources, and correlate them to VMs (VNFs).
Neutron : have a plug-in that could talk to the acceleration-api on networking side.
Integrate Catalogue DB into Nova DB and Neutron DB
Improve Nova-schedular to handle acceleration.
Develop catalogue and inventory of accelerator resources to ensure alignment with NSD/VNFD definition
Baby grows bigger:
Inventory DB and the MSG queue implementation
Other features.

9. From DPACC-MAN to OpenStack – Concrete Work Plan
Two fronts:
OpenStack L Release: Nova enhancements on scheduler and etc to reflect a simple awareness of the acceleration pool
OpenStack M Release: Propose a top level project Rocket as an individual acceleration management project, which could serve as the direct upstream project for DPACC to fulfill any mgmt related requirements.

10. From DPACC-MAN to OpenStack – Concrete Work Plan - Rocket
Nova
Cinder
Neutron
Cat DB
Cat DB
Cat DB
Rocket
Inv DB
Keystone
Rocket
Inv DB
Rocket
Inv DB
Rocket
Inv DB

11. Thank You