OSM RO VNFFG implementation

Virtual Network Function Forwarding Graph Descriptor (VNFFGD) in OSM

VNFFGD is a well-defined data model from ETSI NFV (http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/014/02.01.01_60/gs_NFV-IFA014v020101p.pdf) which was subsequently adopted by OSM in its own informational model (https://osm.etsi.org/wikipub/images/2/26/OSM_R2_Information_Model.pdf).

So how is VNFFG architected in OSM, specifically RO, and how is that communicated to the VIM layer by making use of standard Service Function Chaining?

All of the changes to enable VNFFG support in OSM have been applied to the RO (Resource Orchestrator) module, the fundamental component that needs such support (since it interacts with VIMs and/or SDN controllers). Additional VNFFG-related changes should be enabled in other projects, such as the Service Orchestrator.

Figure 2 above shows the overall OSM architecture and delineates 4 components that were changed within the RO in order to support VNFFGD to VIM-level SFC.

API Service & Utilities

Best categorized as being part of the API Service & Utilities (changed element #1) in Figure 2, YAML template examples of a Network Service with a VNFFG and a new VNF have been added to the examples folder of the OSM RO:

scenarios/examples/v3_3vnf_2vdu_1vnffg_nsd.yaml

vnfs/examples/v3_2vdu_vnfd.yaml

Figure 3 below outlines the example VNFFG and also, in light green, that it could expand to multiple Rendered Service Paths (RSPs).

The VNFFGD is composed of multiple RSPs (Rendered Service Paths, or Network Forwarding Paths in pure ETSI NFV terminology), and each of those states what VNFs should process the traffic and what actual traffic should be processed (the Classifier). A Classifier is a list of match attributes, and they can be traffic classifications such as HTTP. By definition, a VNF can have multiple VDUs which are, essentially, instances or units of that VNF – mainly used for scaling.

Resource Orchestrator Engine

The database definition and migration present in database_utils/migrate_mano_db.sh have been changed to support the storing of VNFFGD and related models. They are logically part of the Resource Orchestrator Engine, outlined as changed element #2 in the figure above.

Also part of this component is the NFVO engine itself, split between nfvo.py, nfvo_db.py and vim_thread.py. Regarding the first two, changes were made to process the new VNFFG element of a Network Service Descriptor (NSD), provided via YAML file, and store its information in internal database tables, also mapping to existing descriptors such as VNFDs. An HTTP server runs automatically and interacts with the Resource Orchestrator Engine to provide/request data. Regarding vim_thread.py, changes were made so that, when a Network Scenario Instance is created, it is able to process existing NSDs that include a VNFFGD. This module’s role is to call the VIM Plugin component outlined in Figure 2 and, to support VNFFGD, special calls have to be made to the VIM Plugin. Essentially, the upper part of Resource Orchestrator Engine will insert tasks in the VIM thread, so that it can call VIM connector’s normalized interface for the creation of networks, functions, service function chains (the eventual transformation of a VNFFG), etc.

VIM Plugin

Or VIM Connector, aims at providing a unified, abstract interface for the calling of typical VIM operations, such as creating compute units or network functions on a Virtual Infrastructure Manager or Cloud Management System. OSM allows different VIMs to be plugged in, and this is the plug point for those. This component has been changed to provide a unified Service Function Chaining interface, which will be called by the VIM thread after the Resource Orchestrator Engine has translated the VNFFGD into specific tasks to be carried by the VIM thread.

OpenStack VIM Plugin

A specific implementation of the Service Function Chaining interface added to the abstract VIM plugin was developed for OpenStack. This implementation calls the OpenStack Queen's networking-sfc API (https://docs.openstack.org/networking-sfc/queens) which leverages previous endeavours the team has done, namely the NSH dataplane support when using the Neutron Open vSwitch driver, making OSM an NFV Orchestrator able to instantiate NSH-based SFCs via the definition of a VNFFGD. This brings together efforts from ETSI NFV and IETF SFC.

For reference, the VIM Plugin interface for SFC contains the following methods:

def new_classification(self, name, ctype, definition)
def get_classification(self, classification_id)
def get_classification_list(self, filter_dict={})
def delete_classification(self, classification_id)
def new_sfi(self, name, ingress_ports, egress_ports, sfc_encap=True)
def get_sfi(self, sfi_id)
def get_sfi_list(self, filter_dict={})
def delete_sfi(self, sfi_id)
def new_sf(self, name, sfis, sfc_encap=True)
def get_sf(self, sf_id)
def get_sf_list(self, filter_dict={})
def delete_sf(self, sf_id)
def new_sfp(self, name, classifications, sfs, sfc_encap=True, spi=None)
def get_sfp(self, sfp_id)
def get_sfp_list(self, filter_dict={})
def delete_sfp(self, sfp_id)

Which use IETF SFC terminology, given that this is an appropriate level to apply IETF SFC concepts (service plane and SFC domain)