OPNFV Parser Design Documentation

1. Parser tosca2heat

Tosca2heat is a opnfv sub-project of parser based on openstack two projects: tosca parser and heat translator.

The TOSCA Parser is developed to parse TOSCA Simple Profile in YAML. It reads the TOSCA templates and creates an in-memory graph of TOSCA nodes and their relationship. Heat-Translator is a command line tool which takes non-Heat templates as an input and produces a Heat Orchestration Template (HOT) which can be deployed by Heat.

More details please refer to openstack related sites.

Tosca2heat intends to enhanced NFV features in tosca template parse and translator, such as huge page, dpdk and sriov.

2. Parser yang2tosca

2.1. Problem description

In NFV, various templates are utilized to describe the deployment requirements, the post-instantiation records or other purposes. However in order to make these templates adaptable and feasible for purpose like deployment orchestration/automation, certain tooling mechanism that provides template translation is necessary.When an end user needs a translation from YANG to TOSCA for further deployment this is where the yang2tosca module comes in as part of parser project.

2.2. Design

The following modules are implemented in yang2tosca module.

2.3. PYANG

PYAG module is used to validate YANG templates, if the user input the YAGN template in YAML format we use this module to validate and convert it to XML format of YANG.The “yin” module under PYANG is used for the conversion from YAML to XML. Reference for PYANG: http://www.yang-central.org/twiki/pub/Main/YangTools/pyang.1.html

2.4. LXML

lxml is another python module that we make use in our design, this module is used to parse the xml object, which will be the base for translational. The “etree” module under lxml is used for the translation to TOSCA files. Reference for lxml: http://lxml.de/

2.5. tosca_translator

All the above module come under this tosca_translator function which can be invoked and used for translation purposes.

The user inputs the YANG template in either XML or in YAML format to the yang2tosca module and the output is the TOSCA YAML file. 1.The First step in the module is where the input is checked for the format.

If the format is YAML then a module called pyang converts this into a YANG XML file. If the format is XML then then the conversion process is initiated.

2.The conversion process will be with the help of an XSLT which will be invoked through python scripting.

2.6. Input

The user can input either YANG XML or YANG YAML file which should be present where the scripts/modules are present.

2.7. Output

The user will get the out TOSCA YAML file under the same directory where the scripts/modules are executed with same name as the input file with “_tosca” suffixed to it.

3. Parser polic2tosca

3.1. Problem description

In NFV, various templates are utilized to describe the deployment requirements, the post-instantiation records or other purposes.However in order to make these templates adaptable and feasible for purpose like deployment orchestration/ automation,certain tooling mechanism that provides template translation is necessary.When an end user needs to inject/remove policies from the TOSCA file generated the policy2tosca module comes in as part of parser project.

3.2. Design

The following modules are implemented in policy2tosca module.

3.3. CLIFF

cliff is a framework for building command line programs. It uses plugins to define sub-commands, output formatters, and other extensions.In policy2tosca we use cliff to define the commands to inject or remove policies from TOSCA templates. Reference for PYANG: https://docs.openstack.org/developer/cliff/

3.4. policy2tosca

policy2tosca is a custom module written with the plugins of cliff where we define adding/removing definitions and/or types of policies. Following are the sub modules under policy2tosca

• add_definition.py: To inject a policy definition to the TOSCA template.
• add_type.py: To inject a policy type to the TOSCA template.
• del_definition.py: To remove a policy definition from the TOSCA template.
• del_type.py: To remove a policy type from the TOSCA template.

3.5. Input

The user specifies the input in command line arguments for the policy2tosca custom module with the source TOSCA file to which the policies should be injected/removed.

3.6. Output

The output TOSCA template will be the input TOSCA file with the modification of policies.

4. Parser verigraph

This document provides a description of VeriGraph, a formal verification tool for service graphs.

4.1. Overview

Given a service graph, which can include stateful network functions and their configurations (e.g., filtering rules for firewalls, and blacklists for anti-spamming filters), VeriGraph can accurately and quickly check reachability properties in the graph (e.g. if a particular flow of packets can go from one node of the graph to another node).

VeriGraph exploits Satisfiability Modulo Theories (SMT) and the general-purpose SMT solver Z3. It includes a library of network function models.

4.2. Architecture

VeriGraph exploits two sub-modules:

• Z3, the SMT solver developed by Microsoft
• Neo4J, a Java-based graph-oriented database

The Neo4J database is used for service graph manipulation and to extract from a service graph all the VNF chains that are relevant for checking the reachability properties of that graph.

4.3. How the tool works

VeriGraph accepts JSON service graph descriptions that include endpoints, VNF instances, logical directed links connecting them, and VNF configurations.

When VeriGraph receives a service graph and a reachability property to verify, it saves the graph into Neo4J and it extracts the chains that connect the nodes addressed by the property to be checked. For each one of these chains, VeriGraph builds a set of first order logic formulas that represent a mathematical model of the forwarding behavior of the chain. This model takes into account the forwarding behavior of the links and of the VNFs included in the chain, taking into consideration their configurations. If the formulas that make up the model are satisfiable, this means that it is possible for a packet to traverse the chain from one end to the other. VeriGraph passes this model to Z3 which checks its satisfiability. Based on the satisfiability result of the formulas that model the different paths, VeriGraph finally derives the overall result (reachability property satisfied or not).

5. Parser apigateway

This document provides a description of apigateway, a message relay submodule for the other parser submodules.

5.1. Overview

Provide unified access interfaces for follow independent parser components:

• tosca2heat
• yang2tosca
• policy2tosca
• verigraph
• parser ui

The apigateway will relay message between above submodules throngh gRPC interface, in additon,

apigateway also exposes restful api to provide parser all functions to the 3rd applications.

5.2. Architecture

Apigateway exploits three sub-components:

• APIGW, the main part of apigateway, which is the message center.
• gRPC, provide gRPC client and server for the other parser sub-modules, it can be devided

into defferent pair of client/server according to the function. - CLI, command line tool for apigateway access and management .

Apigateway architecture is shown below: