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

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.

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

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?

More caveats: Problem #1: Multi-tenancy As shown in the figure on the right, which is from GS NFV IFA 001 0.2.0, 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).

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.

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

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.

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.

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

Thank You