OpenStack vs IFA005006 Gaps

Introduction

There is an ongoing in ETSI NFV's TST WG to find the gaps between the ETSI NFV IaaS API (IFA005 and IFA006) and the API-s of OpenStack projecs with tc:approved-release flag in Ocata. In this work the following experts are contributing beside the members of TST WG: Giacomo Bernini (Nextworks), Dmitriy Andrushko (Mirantis) and Elian Kraja (Nextworks). The following list are the gaps discovered so far.

Gaps

[GAP-01] Affinity resource list scope

Description: Allocate Virtualised Compute Resource contains AffinityOrAntiAffinityConstraint which offers two alternative ways to define affinity rules: affinityAntiAffinityResourceList and affinityAntiAffinityResourceGroup.
It is not mandatory to support both and OpenStack supports only affinityAntiAffinityResourceGroup type of method.

[GAP-03] Resource reservation for calendar time

Description: Virtualised Compute Resources Capacity Management Interface (7.4.4), Virtualised Network Resources Capacity Management Interface (7.3.4), Virtualised Storage Resources Capacity Management Interface (7.5.4) assumes that it is possible to reserve resources for a given time period, while this is not possible in OpenStack.
OPNFV Promise plans to cover this functionality by with the usage of Blazar.

[GAP-04] Capacity query for a time period

Description: Query Compute Capacity operation (7.3.4.2) contains a timePeriod to define a time period when the capacity is queried. As in OpenStack it is not possible to reserve resources for a given time period it is also not possible to query the capacity for a time period.

[GAP-05] Publish subscribe to resource changes

Description: Virtualised Compute Resources Capacity Management Interface (7.3.4), Virtualised Network Resources Capacity Management Interface (7.4.4) and Virtualised Storage Resources Capacity Management Interface (7.5.4) define a publish subscribe mechanism where it is possible to subscibe to changes of the different resources. OpenStack does not support publish subscribe, long polling nor a websocket based mechanism to watch the changes of different resources. OpenStack Compute and Storage API-s support simple query and return with the actual state of the resource. Ceilometer is capable to send events to an external service, but subscription to these events are not exposed to the API. Using a publish subscribe mechanism would need a bidirectional communication which in case of http based protocols assumes a web server on both sides. Long polling does not need bidirectional communication, but the connection can be interrupted by intermediate network devices. A websocket based publish notify solution would be ideal from connectivity perspective (websocket uses only one TCP connection what is already open, so there is no need to open new connection), but it is a solution beyond the capabilities of the plain http based REST API-s. Also in case of websockets the protocol is not defined and the OpenStack would become statefull what negatively affects the scalability and reliability.

[GAP-06] Bandwidth per Network Interface

Description: Virtualised Compute Resources Management Interface (7.3.1), in Allocate Virtualised Compute Resource operation output (7.3.1.2.3), defines VirtualCompute (8.4.3.2) as main output, where bandwidth parameter is mandatory under virtualNetworkInterface. However, in OpenStack bandwidth information is not available per port, while it can be set and retrieved (as optional attribute) per network via Neutron Networks QoS (neutron-qos). The same applies to: i) Query Virtualised Compute Resource operation (7.3.1.3.3), that still returns a VirtualCompute; ii) and to Update Virtualised Compute Resource operation (7.3.1.4), that defines bandwidth under networkInterfaceNew and networkInterfaceUpdate.
The functionality exist in OpenStack, but it is not visible in the API documentation of the port operations.

[GAP-07] Acceleration Capability in Update Compute

Description: Virtualised Compute Resources Management Interface (7.3.1), in the Update Virtualised Compute Resource operation (7.3.1.4), defines the option to set or update accelerationCapability under networkInterfaceNew and networkInterfaceUpdate, which are used to attach new ports/network-interfaces or update existing ones to a compute resource (i.e. an OpenStack Server). These operations are mapped into OpenStack with Nova Server update (POST ​/servers/{server_id}/os-interface) or Neutron Port create (POST /ports). OpenStack (both in Nova Server update and Neutron Port create) does not allow to directly set acceleration capabilities over a Port. Acceleration capabilities can be managed as part of the Nova Compute Flavor operations (nova-flavors), in particular by means of specific network-related extra-specs (extra-specs).

[GAP-08] Minimum Bandwidth per Network

Description: Virtualised Network Resources Management Interface (7.4.1), in the Allocate Virtualised Network Resource operation (7.4.1.2), when considering the allocation of a virtual network, defines a mandatory bandwidth attribute in the VirtualNetworkData IE (8.4.4.2). This bandwidth parameter is defined as the minimum guaranteed bandwidth for the network to be created. The same applies to VirtualNetwork IE (8.4.5.2), that is returned in the Allocate Virtualised Network Resource response. This operation is mapped into OpenStack with the creation of a Neutron QoS policy (qos) to be then associated with the Neutron network. However, with Neutron QoS policies is not possibile to define a minimum guaranteed bandwidth per network, but only bandwidth limits.

[GAP-09] Subnet Operational State

Description: Virtualised Network Resources Management Interface (7.4.1), in the Allocate Virtualised Network Resource operation (7.4.1.2), when considering the allocation of a subnet, defines a mandatory operationalState parameter in the NetworkSubnet IE (8.4.5.3), that is returned Allocate Virtualised Network Resource response. This operationalState parameter is defined as an Enum {enabled,disabled}. This operation is mapped into OpenStack with the creation of a Neutron Subnet (Subnets). Neutron does not include any operational State for the Subnet.

[GAP-10] Virtualised Network Resources Capacity Management Interface

Description: Virtualised Network Resources Capacity Management Interface (7.4.4) specifies number of operations related to network capacity and usage reporting. As of Ocata release OpenStack is missing capacity management for networking resources. There is a general user story focused on a capacity management at OpenStack, but at this moment no appropriate blueprints and implementation roadmap. Additionally IFA005 spec doesn't specify which network resources are subject for "Capacity Management" operations, i.e. Network Bandwidth, QoS parameters, Ports, IPs etc. Depending on a definition of the "Network Resources", some of the existing existing OpenStack features might be used, for ex. Quota interface to get information about allocated/used networks, subnets, FIPs, etc.

[GAP-11] Change Network Forwarding Path (NFP) State operation

Description: In Network Forwarding Path Management Interface (7.4.5), Change NFP State operation (7.4.5.5) should be used to request changing the state (enable or disable) of an NFP. Assuming that Neutron Service Functions Chaining (SFC) is logically equal implementation of the NFP entity defined in section 7.4.5, OpenStack implementation is missing operation which is capable to enable/disable SFC. At the moment of review only full create/delete operations for port-pairs, port-groups and port-chains required to enable or disable SFC at the OpenStack.

ETSI NFV meets OpenStack workshop materials

• [etherpad https://etherpad.openstack.org/p/etsi-nfv-openstack-gathering-denver]