SERVICE DEVELOPMENT KIT (SDK)

The SDK end-to-end workflow consists of 6 major steps, plus a coordination one, each of them supported by a set of SDK tools and components.

Coordination

The coordination Workspace and Project Management tools support the developer in preparing the local development environment through the creation of workspaces and project folders. SDK Portal is a GUI portal which is able to quickly and accessibly trigger most of the available SDK tools.

Implementation

The first real step of the development process starts with the implementation of individual VNFs, Specific Managers (SM) and the appropriate tests. The Image Creation tool provides support to convert docker images into VMs, therefore broadening the scope of VIMs on which VNFs can be deployed. The creation and implementation of tests of the SMs is supported by the Specific Managers Creation tool, while the implementation of tests of VNF/NS is supported by the Testing Framework.

Composition

Once the individual components are available, the SDK provides a number of tools to actually compose these components into services described through descriptors. The Schema Repository tool defines the descriptor formats that can be used, while the Descriptor Generator Tool provides usable templates to start from. In addition, the Decision Support Engine provides recommendations on which components can be appropriately combined.

Packaging and Bundling

Given the appropriate descriptors, the entire service and collection of tests can be bundled and packaged using the Packager tool. 

Validation and Testing

The SDK provides three levels of local testing, before the resulting packages are handed over to the V&V Platform and/or deployed in production environments (Service Platform).

The first level, syntactic validation and selected (static) semantic checks of involved descriptors, is supported through the Validation Tool. In addition, ad-hoc functional testing is made possible through the deployment of services (and associated SMs) in a local environment using the emulator. As many of these tests need to be executed after every development iteration (e.g., regression testing), the Testing Framework enables scripting and automated execution of functional tests in a Python-based environment. 

Benchmarking

One way of assessing the performance of a service is producing the appropriate set of measurement data under a wide number of environmental conditions, for example resource restrictions. This can be done through the Benchmarking Tool. 

Analysis

A different option may consist of analysing the produced performance data with the purpose of identifying performance correlations and/or bottlenecks using the Analytics Engine. 

SDK Portal (tng-sdk-portal)

The SDK consists of numerous tools that are useful for different stages in the development workflow. Using them in the correct order may be challenging for novel users. To this end, the SDK provides a graphical portal that allows a seamless and effortless development workflow. The SDK portal can be hosted remotely so local installation by users is required. The SDK Portal front-end is written in Angular 6.0. 

Workspace Tool (tng-workspace) 

The Workspace Tool can be used for creating the local development environment on the developer PC.

Project Management Tool (tng-sdk-project)

The Project Management Tool enables developers to create and manage NFV projects. It keeps track of all involved artifacts in the project using a project manifest. The manifest also contains metadata about the project and the individual files.

When creating a new NFV project, developers can also generate suitable descriptors using the Descriptor Generation Tool integrated within the project management tool. Its simple graphical web-interface speeds up and eases the process of writing all relevant descriptors. 

The Project Management Tool can be used either via its simple CLI or using its exposed REST API when deployed as microservice, which facilitates the integration with the SDK portal and any other web-based tools.

Image Creation Tool (tng-sdk-img)

The Image Creation Tool eases Virtual Machine (VM) image creation for VNF images based on Docker containers. This enables developers to quickly deploy Docker-based VNFs not only on the SDK emulator, but also on the Service Platform. It also allows the generation of images based on a range of configuration formats, such as, software configuration and installation script, click modular router configuration, RUMP kernel configuration, LING kernels (Erlang on Xen). The SDK VNF image conversion and generation functionality aims to overcome existing barriers in VNF image formats.

Specific Managers Creation Tool (tng-sdk-sm)

SONATA allows developers to add Function Specific Managers (FSM) and Service Specific Managers (SSM) to the descriptors of their VNF/NS. This is a distinctive feature of SONATA, as it enables the customisation of the otherwise rigid orchestration and configuration capabilities available in other MANO platforms. The SSM customises orchestration behaviour for NSs life cycle events, the FSM customises the VNF orchestration events. When the SONATA Service Platform needs to execute a network service life cycle event, it first checks whether one or more SSMs are associated with this service and workflow. If that is the case, the Service Platform executes this SSM; a similar behaviour can be expected for Network Function life cycle events and FSMs.

The Specific Managers Creation Tool aids developers with the creation and locally testing of the FSM / SSM associated to their VNF/NS. 

Schema Repository (tng-sdk-schema)

The SONATA Schema Repository defines the formats to be used for the wide number of descriptors supported by SONATA Platform to store important information about services, packages, slices, etc. in a structured way. 

These are the types of descriptors supported by SONATA Service Platform:

• Network Function Descriptors: specifies the Deployment Units (DU) that compose that Network Function, how these DUs are interconnected and what connection points are exposed to the outside world. Different types of Network Function are supported: Virtual Network Functions (VNFs), Cloud Native Network Functions (CNF), Physical Network Functions (PNF) and Hybrid Network Functions (HNF).
• Network Service Descriptors (NSD): specify the involved Network Functions inside the service and define how the VNFs are connected (in a forwarding graph). In 5GTANGO, network services may also be recursive and contain other network services.
• Package Descriptors: describe which files are part of the package and to which flavor they belong.
• SLA template descriptors: incorporate metrics such as specific objectives or quality attributes, parameters and expressions (i.e., rules) between parameters. The proposed YAML schema, based on ISO/IEC DIS 19086-2, aims to specify the main building blocks of an SLA template and also presents an expression (i.e., function) that allows any service provider to specify any metric included in a template (e.g., availability, response time, etc.). As SLA templates are tailored to a service provider, they reference Network Services inside the service provider's catalogue using its UUID (rather than vendor/name/version). This allows to define separate SLA template descriptors for the same Network Service being used by different service providers, i.e., stored in their individual catalogues.
• Policy descriptors: are deployment templates optionally attached to Network Services referencing a set of enforcement rules upon which certain actions are taken in order to meet some objectives described by specific SLAs. In SONATA, a policy descriptor is attached to a specific Network Service, which may have more than one policy, but only one is active during instantiation. The basic ingredients of a policy descriptor are a set of policy rules that contain conditions and actions. Conditions may be recursive, i.e., contain other sub-conditions.
• Test descriptors: define the type and configuration parameters of a test as well as testing tags, which are used for test execution.

All descriptors are specified as structured YAML files, which are both human- and machine-readable. The structure of each descriptor type, defined by a schema, is also written in YAML. It specifies mandatory and optional fields as well as the format of file. Existing descriptors can easily be validated against the schemas to make sure their structure is correct. The schema checking is implemented as a small validation tool using JSON schema.

Descriptor Generator Tool (tng-sdk-descriptorgen)

Containing lots of details, descriptors are often quite complex and difficult to write manually and/or from scratch. The Descriptor Generator is a tool with a simple graphical web-interface for speeding up and easing the process of writing descriptors. The descriptor generator greatly relieves developers from performing repetitive, error-prone tasks and thus accelerates and simplifies the process of creating descriptors. To create a valid sample descriptor, only a single click is necessary. Clearly, the generated descriptors can still be edited and adjusted. In fact, the web interface of the descriptor generator allows in-browser editing with syntax highlighting and download buttons such that the generated descriptors can be modified and retrieved easily. 

In addition, a command-line version of the descriptor generator that may help advanced users generate descriptors more quickly without the graphical interface. Instead, high-level information may be specified in form of YAML configuration files or passed to the generator directly. 

The Descriptor Generator Tool is integrated in the Project Management Tool. It is written in JavaScript and HTML and can completely run on client side or inside a docker container with minimal installation effort. 

The Decision Support Engine (tng-vnv-dsm)

This tool aims to unburden the test developers from the selection of the tests to perform to check the functionality of their Network Services. The goal of this tool is to automate the process of the test selection, providing some recommendation preferences based on the users´ previous activity. Thus, the Decision Support Engine is a recommendation system that uses Collaborative Filtering Methods based on collecting and analyzing large amounts of information on users' behaviors, activities or preferences and predict what users will prefer based on their similarity to other users. Singular-Value Decomposition (SVD) is used for measuring the user/item similarity.

The tool can be used as a standalone micro-service. However, the V&V Platform needs to be installed and configured in order to make an effective use of the tool. An API has been implemented for interacting with it.

The Packager Tool (tng-sdk-package) 

The Packager tool simplifies the creation and extraction of packages. The SONATA package format and this tool are designed to be multi-platform, supporting the generation of other MANO platforms packages besides SONATA, like OSM and ONAP.

A CLI interface for local usage by a developer as well as a REST interface to be used by other services is provided. 

Validation Tool (tng-sdk-validation)

The Validation Tool supports the automatic validation of the generated descriptors against their schemas before downloading them. Four types of validations are enabled:

• Structure: check Project file structure.
• Syntax: just a syntactic check based on the defined in the schema repository.
• Integrity: it verifies that all the elements the Descriptor contains are valid and all the required elements to setup the topology are present.
• Topology: validates the network topology logic and tries to find design defects.

In addition, this tool can include specific checks which are called custom rules validations.

The Validation tool can be executed from the console using a CLI but it also can be used deployed as a micro service through a REST API. The service API can be executed in two different modes: 1) stateless, in which the tool works as a service that can be used by other applications, and 2) local, which is intended to be used by developers to validate the file descriptors as they are created/modified. 

Emulator (vim-emu)

The Emulator can act as a standalone tool to locally execute simplified test cases on the developer laptop. Such an environment is very helpful for VNF/NS developers as it allows quick turn-around times, because the on-boarding and deployment steps of a real service platform can be skipped. However, such a test tool is limited to functional tests and is also limited in terms of special platform or hardware requirements. 

A wrapper allows the SONATA Service Platform to orchestrate on the emulated PoPs of the Emulator, so it can be also used in a local setup. This way, Service Platform-associated workflows, such as Service and Function Specific Managers (SSM/FSM), can be tested locally as well. This feature is of particular interest for the Specific Manager testing framework, which will use it to create a local test environment. Further, this integration allows to use the emulation platform as test execution platform for a V&V platform connected to a Service Platform instance.

The Emulator is designed to use Docker container-based VNFs and VM-based VNFs. It is a light-weight emulation platform which can be deployed even on low-performance machines such as laptops. It can work as a VIM for SONATA Service Platform but also for the OSM one.

Testing Framework (tng-sdk-test)

The SONATA Testing framework is a Python-based framework for automated functional testing of VNF/NS. It can be used to create and run tests on different platforms and retrieve and analyze their test results.

The testing framework has a separate module for interacting with Virtual Infrastructure Managers (VIM). Currently, it supports the SONATA Emulator for local testing and the V&V Platform to execute tests on real environments, but it can be easily extended to support any other VIMs.

Benchmarking Tool (tng-sdk-benchmark)

This tool aims to be a framework for the end-to-end automation of VNF benchmarking processes. Its goal is to automate the benchmarking process in such a way that VNF performance profiles can be generated without further human interaction. This enables the integration of VNF benchmarking into continuous integration and continuous delivery (CI/CD) pipelines so that new VNF profiles are generated on-the-y for every new software version of a VNF.

Analytics Engine

The Analytics Engine is responsible for the realisation of analysis and extraction of insights and profiles at VNF / NS level from the results of the tests executed either in an experimental or operational context. Under this perspective, the Analytics Engine can either perform the analysis based on results coming from the SDK benchmarking tool or the V&V Platform. In the first case, the analysis results are mainly given as feedback to software developers in order to identify performance issues, capacity limits, etc. in the developed NFV / NS so they can proceed to implement corrective actions or appropriately dimension the requirements for the efficient deployment and operation of the software. In the second case, the results can also lead to the design and specification of effective policies or the incorporation of machine learning models for forecasting purposes

The resulted insights cover many different aspects, including: Resource Efficiency Analysis, Elasticity Efficiency Analysis, Correlation Analysis and Machine Learning Models, Time Series Decomposition and Forecasting or Graph Analysis. They are made available in the form of URLs, while they are also stored in the analytics engine database. In this way, they can be easily consumed by the interested parties.

The Analytics Engine is based on OpenCPU, a system for embedded scientific computing and reproducible research. The OpenCPU server provides a reliable and interoperable HTTP API for data analysis based on the R programming language, while big data analysis can be also realised based on SparkR. Furthermore, there is potential for incorporating other Python analysis scripts by using R packages that support embedded Python code.