In this blog post, we describe the integrated workflow with 5GTANGO's SDK from setting up a workspace to on-boarding a complete package with a desired network service. The SDK supports developers in all these steps through multiple tools that work together seamlessly and are available on public GitHub repositories.

Creating and Validating Network Service and VNF Projects

Developers using 5GTANGO's SDK can setup a workspace, containing configuration files that are used in subsequent steps of the SDK workflow and allow to manage multiple service projects targeting different domains, e.g., different service platforms. This setup simply requires issuing the tng-workspace command, which is provided by the tng-sdk-project tool. This automatically creates a directory with all required configuration files in the developer's home directory (or another custom-defined location).

To develop a new network service, developers have to define the service as such and involved virtual network functions (VNFs) using 5GTANGO's descriptors, NSD and VNFD, respectively. Additionally, developers can specify tests in standardized TTCN-3 format [1] to validate the functionality and performance of their network service. Test descriptors specify the type, configuration, and execution parameters of each test. The format of all these descriptors is defined by schemas (see tng-schema) that are publicly available and define a clear description model.

5GTANGO supports developers in creating NSDs and VNFDs by providing a descriptor generation tool (tng-sdk-descriptorgen). The descriptor generator offers a simple web-based GUI on which developers can specify high-level information about their network service and the involved VNFs, e.g., their name, description, the number of VNFs and their images. The tool then automatically generates the corresponding NSD and VNFDs based on this high-level information and sensible default values. For example, the tool assumes a typical linear service structure, i.e., all VNFs are connected in a chain with one input and output each.

The descriptor generator's GUI immediately shows the generated descriptors and allows developers to perform manual adjustments, e.g., regarding the resource requirements of individual VNFs. While such manual adjustments allow fine-tuning, the descriptor generation greatly reduces the number of manual steps to create the NSD and VNFDs and thus simplifies and accelerates the process and makes it less error-prone.
In fact, the setup time for a new network service or VNF project is reduced to minutes and the error-prone process of writing down the initial descriptor skeleton is entirely removed from the workflow.

After creating NSD and VNFDs, the final descriptors can be downloaded in as structured project with separate directories for the descriptors, images, and further files. Each project contains a project.yaml, which specifies the path and MIME type of all involved files as well as optional tags. These tags indicate to which service platform a file belongs, e.g., 5GTANGO, OSM, or others. The tng-sdk-project tool enables developers to easily add (or remove) files using the command line, automatically resolving wildcards and detecting the MIME type of files using a simple command-line interface.

To validate the syntax, integrity, and topology of the project and the included descriptor files, 5GTANGO provides the tng-sdk-validation tool. This tool allows to quickly find errors or potential problems in a project before even packaging and uploading it. In doing so, a developers have a first quick feedback cycle to support debugging and avoid problems during deployment. The tng-sdk-validation tool can be flexibly used with different options, controlled either through a command-line interface or running as micro service inside a Docker container.

 

Generic and Standard-compliant Package Format

In 5GTANGO, packages are the first-class artifact used to exchange network services, VNFs, tests or test results between 5GTANGO's main components, like verification and validation platform or service platform, and developers. To support this, 5GTANGO introduces a novel NFV package format that aims to be the most generic, reusable, feature complete, and compatible package format in the NFV landscape. To achieve this, we build up on the existing CSAR [2] and ETSI SOL004 [3] standards and extend them to explicitly support the following additional features:

  • Multiple package types: 5GTANGO packages can contain single VNFs, complex network services, or test results only. This is a major difference to SONATA packages, but aligns them more with the view of ETSI, OSM, ONAP, or OpenBaton.
  • Layering: 5GTANGO packages can contain different flavors of descriptors/artifacts for the same service, e.g., one NSD for 5GTANGO SP and one for OSM at the same time. This allows us to target different platforms with the same package and bypasses problems that occur if you try to automatically translate descriptors. We call this concept layering. Each layer is identified by one or more tags.
  • Artifact references: To support slim packages, it is possible to reference artifacts, e.g., disk images or any other file, from within the 5GTANGO package. The unpackager will try to resolve these references when the package is unpacked, e.g., download the referenced disk image. To reference artifacts, we follow an approach that is inspired by Unix filesystem symlinks: For each reference, a file with the ending *.ref is created as a placeholder for the referenced artifact inside the package. This file contains all information required to resolve the reference, e.g., URIs, protocol information, checksums, or credentials of an FTP server. The benefit of this approach is that it fully compatible with the CSAR and ETSI standards, which would not be the case if we try to put reference information inside manifest files or package descriptors.
  • Package references: 5GTANGO packages can reference other 5GTANGO packages using the vendor.name.version triple known from SONATA. With this, test result packages can reference the services to which they belong. Checksums allow to verify the integrity of referenced packages.
  • Signed packages and security: 5GTANGO packages contain checksums of all referenced or packaged artifacts to ensure integrity and underline the immutable nature of our packages. On-top, 5GTANGO packages can be signed to allow automatic authenticity checks when packages are exchanged between components and domains. This supports the end-to-end work flows envisioned for 5GTANGO [4].

We made the entire specification of the 5GTANGO package format available online. It is hosted on a GitHub page with the title "5GTANGO Package Specification (latest)". This has two advantages: On the one hand, the specification can be a living document which can be updated when needed. On the other hand, the package specification is available to the public from day zero, making it easy to pick up and use by other projects.

To simplify the creation and extraction of 5GTANGO packages, we develop a packager tool as part of 5GTANGO's SDK. This tool is called tng-sdk-package and is a complete rewrite of the SONATA packaging tool. The 5GANGO packaging tool does not only support and simplify the package creation but can also be used to unpack packages. For this, the packaging tool can be deployed as a micro service and used, e.g., by the service platform. This allows us to maintain only one common codebase that deals with both packaging and unpackaging. With its module structure, tng-sdk-package allows to be extended to generate and use other third-party package formats and can be integrated with various NFV catalogues, to which artifacts can be directly pushed when a package is unpacked.


5GTANGO's SDK: Simplicity and Openness

The described end-to-end SDK work flow supports developers from the creation of descriptors to the packaging and uploading of complete services. This accelerates and simplifies the whole process and enables faster time-to-market and higher quality services with less errors. Following the DevOps principle, feedback loops after each stage allow developers to go back to adjust their service or descriptors, e.g., after obtaining validation results. To avoid vendor lock-in, we are currently preparing a OSM-compatible version of this workflow, supporting the generation of OSM descriptors as well as their packaging and unpackaging using our novel, generic package format.


References

[1] ETSI - European Telecommunications Standards Institute: TTCN-3 (Testing and Test Control Notation Version 3), http://www.ttcn-3.org/ (accessed May 23, 2018)
[2] Gerd Breiter, Frank Leymann, Thomas Spetzier: TOSCA: Cloud Service Archive (CSAR), 2012
[3] ETSI - European Telecommunications Standards Institute: ETSI GS NFV-SOL004, 2017
[4] P. Twamley, M. Müeller, P-B. Bök, G.K. Xilouris, C. Sakkas, M. Peuster, S. Schneider, M.a. Kourtis, D. Kyriazis, P. Stavrianos: 5GTANGO: An Approach for Testing NFV Deployments. In IEEE European Conference on Networks and Communications (EuCNC). (2018)