SONATA 4.0 GUIDE OF USE

Transcription

1 SONATA 4.0 GUIDE OF USE The purpose of this tutorial is to provide the reader with a general view about SONATA powered by 5GTANGO platform in the easiest and quickest way possible. Here you will find a brief explanation about what SONATA powered by 5GTANGO is, how to install it, how to use it and how to get technical support if required. This tutorial doesn t pretend to be an extended document where one can find all the information related to SONATA powered by 5GTANGO, but an umbrella document that will guide you to more extensive documentation if required. SEPTEMBER 2018

2 SONATA 4.0 TUTORIAL 1 Table of contents 1. Introduction Purpose of this tutorial Document structure Brief introduction to SONATA What s SONATA? Who is it for? General architecture SONATA Modules Service Development Kit V&V Platform Service Platform Release Notes information SDK V&V Platform Service Platform Portal Installation General instructions and main steps Service and V&V Platforms installation Recommended specifications for the virtual machines Installation Instructions SDK Pre-requisites Installation Instructions Emulator Bare-metal installation Docker-based installation Start using SONATA Creating a network service with the SDK Generate descriptors Create a workspace (only required once) Manage the project... 21

3 SONATA 4.0 TUTORIAL Validate the syntax, integrity and topology of the descriptors using tng-sdkvalidate Create a package Onboard the package into the SONATA Service Platform or Emulator Creating a Function Service Manager Clone and install the tng-sm tool () Create a new FSM or SSM by executing Extend the FSM (or SSM) code Test the FSM (or SSM) Build the Docker Add the FSM (or SSM) correctly to the VNFD (or NSD) Upload VNF to glance Testing a network service with the EMULATOR Start the emulator: Create a SONATA service package using son-cli: Deploy the created service package on the emulator: Instantiate the service: Check the running SONATA service: Testing a network service with the V &V Platform Deploying a service with the Service Platform Package On-boarding Generation of SLA Templates associated to Services Define Runtime Policies and set Service Applicability Rules Instantiating a Service Monitoring a Service SLA Violations Terminating a Service Support List of acronyms... 37

4 SONATA 4.0 TUTORIAL 3 1. Introduction 1.1 Purpose of this tutorial The purpose of this tutorial is to provide the reader with a general view about SONATA powered by 5GTANGO platform in the easiest and quickest way possible. Here you will find a brief explanation about what SONATA is, how to install it, how to use it and how to get technical support if required. This tutorial doesn t pretend to be an extended document where one can find all the information related to SONATA, but an umbrella document that will guide you to more extensive documentation if required. 1.1 Document structure This quick guide is organized in the following manner: Section 1 (this section) is an introduction to the guide. Section 2 provides a general presentation about SONATA: what SONATA is and for whom. Section 3 describes SONATA general architecture, and a brief description of its main modules, the Service Development Kit (SDK), the Validation and Verification (V&V) Platform and the Service Platform (SP). Section 4 gives information about the current SONATA software release. Section 5 explains the installation process for each of the SONATA components that can be installed and used individually. These are the SDK, the V&V, the SP and the Emulator that, although part of the SDK, has its own autonomy. In section 6, we describe briefly how to use SONATA once installed, from the creation of a service, how to test it using the emulator, to its deployment with the Service Platform. 2. Brief introduction to SONATA 2.1 What s SONATA? SONATA powered by 5GTANGO is a 5G Development and Validation Platform for global Industry-specific Network Services and Apps. SONATA puts forth the flexible programmability of 5G networks with: 1) A NFV-enabled Service Development Kit to support developers with the creation of innovative VNF/NS. 2) A V&V Platform with advanced mechanisms for VNF/NS qualification. 3) A modular Service Platform with a MANO framework to manage the full lifecycle of VNF/NS. The combination of the proposed toolkit, the V&V Platform and the Service Platform realizes an extended multi-modal NFV DevOps model between service developers, telecom operators and vertical industries, increasing operational efficiency, facilitating the creation and validation of new services and accelerating the adoption of NFV technologies.

5 SONATA 4.0 TUTORIAL Who is it for? The SONATA platform supports three main stakeholders in telecommunications service creation: service developers, service certification companies and service operators. SONATA s Network Service Development Kit (SDK) facilitates network service development for third-party service developers. Those services can be tested using the V&V Platform by third party service certification companies. Such services are then deployed and run on SONATA s Service Platform by service operators. Therefore, SONATA enables a DevOps workflow between the SDK tools, the V&V platform and the service platform, which allows third parties and operators to closely collaborate in providing an outstanding experience to customers. 3. General architecture The main architectural components of the SONATA powered by 5GTANGO platform are shown in Figure 1 below. In line with the support of service developers, service certification companies and service operators, SONATA distinguishes three main components SDK, V&V and Service Platform. Services developed and deployed by this system run on top of the underlying infrastructure accessible to the SONATA system via Virtual Infrastructure Managers (VIMs), abstracting from the actual hardware and software. Each of the three main components can be divided into a number of subcomponents, realized in a micro-service-based approach. Detailed information on the architecture and its components can be found in:

6 SONATA 4.0 TUTORIAL SONATA Modules Figure 1: SONATA high level architecture The SONATA platform consists of a number of software modules, which together provide the required functionality for network service creation, verification and validation, deployment and management. Most modules can be attributed directly to either the SDK, the V&V Platform or the Service Platform according to their use. Some modules are crosscutting and are used in the major components Service Development Kit The Service Development Kit (SDK) provides a collection of tools, empowering the service developer to rapidly build, validate and test NFV services. Although many tools can be used on their own, the SDK enables a typical developer workflow supporting the creation of an isolated workspace and project environment, the generation and validation of descriptors, the packaging and onboarding, as well as the testing and emulation in a local development environment. Figure 2: Development workflow The SDK consists of the following main modules: Project & workspace creation functionality: tng-workspace and tng-project are CLI tools enabling the assisted creation of isolated development environments (having GIT-like options).

7 SONATA 4.0 TUTORIAL 6 Descriptor generation functionality: tng-sdk-descriptgen is a web GUI functionality enabling rapid generation of descriptors based on a set of VNFs. Image conversion functionality: tng-sdk-img is a CLI-tool, which makes it possible to convert docker-based VNFs to equivalent Virtual Machine based (VM-based) VNFs. Docker-based VNFs can ease the testing and debugging phases of development, while VMs can ensure improved isolation in production environments. Service validation functionality: tng-sdk-validate consist of a CLI and GUI interface enabling to detect syntactical as well as semantic errors in descriptors (e.g., topological errors in the service graph). In addition, it enables to add customizable validation rules (e.g., ensure that resources are high enough in descriptors). Packaging functionality: tng-package is a CLI tool enabling to generate package files from project folders. This includes support for multiple Management and Orchestration (MANO) platforms (e.g., Open Source MANO - OSM). Onboarding functionality: tng-sdk-access contains CLI scripts to ease the process of onboarding on MANO platforms and the emulator (as an alternative to manual CURL commands). Emulator environment: vim-emu is CLI environment enabling to emulate a local MANO framework as well as a VIM locally on the pc of the developer. This allows the developer to locally deploy a developed service for testing and debugging purposes. tng-sdk-traffic is a tool to generate test traffic in the emulator. Testing functionality: tng-sdk-sm is a CLI tool, which eases the proses of writing and testing Specific Manager components V&V Platform The V&V Platform is a mechanism of ensuring that the uploaded services can be tested on the appropriate target Service Platform to ensure that the service is considered fit for purpose. The Platform currently will: 1. Identify and target the appropriate tests (via tag) for the target service 2. Prepare the target SP and corresponding test environment 3. Execute the sequence of tests via a test plan on the target service platform 4. Determine the success or failure of the test 5. Return the results for future analysis The main modules of the V&V are the following: Gatekeeper: A shared component with the SONATA SP and offering similar functionality, the V&V Gatekeeper controls access to the V&V platform and is responsible for all interactions with it. Lifecycle Manager: The lifecycle manager is responsible for the overall planning of the test execution including identifying target services to be tested, creating an associated test plan, ensuring that plan is executed and returning the results. Test Execution Engine: Responsible for the setup of the test environment and execution of the test against a target service platform.

8 SONATA 4.0 TUTORIAL Service Platform SONATA's Service Platform is where: 1. Users are created, authenticated and authorized; 2. Packages, containing (network) services and (virtual network) functions descriptions, are on-boarded, validated and stored in the catalogue. A service or a function can bring with it a specific manager, which may change the default behavior the SP has for a specific aspect of that service's or function's lifecycle (e.g., placement, scaling, etc.); 3. Services from the Catalogue are instantiated (with licenses verified) and orchestrated, through the MANO, in the abstracted infrastructure; 4. Instantiation records are generated and stored, providing instantiation data to the other components; 5. Monitoring data is collected and securely provided on demand to the service developer, thus allowing quick and frequent service improvements; 6. Key Performance Indicators (KPI) are collected, to show the overall business performance of the system; 7. Operator policies are defined, based on technical metrics and thresholds, as well as information about infrastructure utilization, triggering actions such as update, scaling or healing, among others; 8. Service Level Agreements (SLAs) are associated to end users, by using business metrics, checking whether those agreements are violated; 9. Network Slices templates can be defined, instantiating and terminating slices, or taking other more advanced management actions like updates or scaling, among others. The main modules of the SP are the following: Gatekeeper: controls and enforces whoever (and whatever) wants to interact with the SP and guarantees the quality of the submitted packages, by validating them against a schema (syntactically), the topology of the described service and its integrity. Catalogues: stores and manages (smart delete: only packages with services that do not have running instances can be deleted) package files, its meta-data as well as service's and functions' meta-data. Repositories: stores and manages service and function records, resulting from the instantiation, update and termination processes. MANO Framework: the orchestrator, who manages each service's lifecycle, including when the service and/or its functions bring specific managers with them to be used in certain segments of their lifecycle. Please note the clear separation between the two levels, the Network Function Virtualization Orchestrator (NFVO) and the Virtual Network Function Manager (VNFM) and Controller. This separation was originally recommended by ETSI, and it effectively corresponds to two very different levels of abstraction that is important to be kept separate. Infrastructure Abstraction: hides the complexity and diversity of having to deal with multiple VIMs and WIMs. Monitoring: collects, stores and provides monitoring data for the services and functions instances.

9 SONATA 4.0 TUTORIAL 8 Policy Manager: define policy rules based on metrics or infrastructure resources utilization, being able to suggest/order actions to be performed by external components, namely by the MANO Framework. Those actions can be scaling, healing, update, etc. SLA Manager: define SLAs with certain objectives to be guaranteed by the service provider to the end-users and notifies external components (namely the Portal) about the violation of such SLAs. Slice Manager: define Network Slice Templates by using multiple Network Services (NSs) interconnected, and is able to instantiate, terminate, and perform other advanced Slice management operations such as update, scale, etc. These are the high level modules. Further details on each one of them can be found in each one of those modules GitHub's repositories. 4. Release Notes information This is version 4.0 of the SONATA platform. The main enhancements of this release are organized by sub-system and GitHub repository: 4. 1 SDK tng sdk validation Syntax, integrity and topology validation as it was implemented in sonatanfv/son-cli tool. Added complete unit tests for validation function, CLI and Representational State Transfer (REST) API. REST API with synchronous and asynchronous modes. Added basic custom rule validation, unit testing and example rule descriptor. Descriptor schemas are downloaded from sonata-nfv/tng-schema repository. In future versions the Uniform Resource Locator (URL) to download to schema will be obtained from the Descriptor. REST API local mode with watchers implemented (only for functions). API refactor to follow REST API best practices. tng sdk img functionality for converting Docker-based VNFs to QEMU-based VNFs. separate processing of VDUs. support of local docker images. tng sdk descriptorgen Simple and responsive web-based GUI based on Bootstrap. Generation of NSD and VNFDs based on provided high-level information and sensible default values with one click. Users only need to specify high-level information. Generated descriptors can be edited in the GUI (with syntax highlighting) to quickly perform small adjustments.

10 SONATA 4.0 TUTORIAL 9 Final descriptors can be downloaded as zipped NFV project, including a generated project manifest (project.yml), which is necessary for further project management or packaging. tng sdk package Packaging using CLI. Unpackaging using CLI or REST. Docker-based micro service deployment. Basic (static) package validation. Multiple packager components. Multiple storage backends. son emu Integrated vim-emu with OSM release FOUR. Re-deploy network services without emulator re-start. Made complete codebase PEP8 compatibles. Added automated code style checks to the CI pipeline. Made port deletion process more robust. Better unit tests. Cleaned up examples. Added examples for OSM release FOUR. Many small bug fixes. tng sdk project Create new SONATA workspaces (e.g., with configuration files). Used by other SDK tools, e.g., to determine the MIME type of SONATA descriptors. Create new NFV projects containing arbitrary artifacts, e.g., descriptors or VNF images. Automatically generates a corresponding project manifest (project.yml), which states project information and lists all involved files. Project files can easily be added or removed with add and remove, supporting wildcards (similar to the well-known git CLI). The project status ( status) provides a quick overview of the project information and involved files. A translation functionality ( translate) automatically translates old SONATA projects to the new v4.0 format. Complementary to the simple descriptor generation GUI. Quick generation of descriptors for experienced users, preferring a CLI. To be integrated with the project management in the future (e.g., to automatically generate suitable descriptors when creating a new project). tng sdk sm Creation and removal of Service-Specific Manager (SSMs) and Function- Specific Manager (FSMs). Generating payloads that serve as input for tests for FSM routines. Execution and testing of SSM and FSM routines, with generated or custom payloads as input.

11 SONATA 4.0 TUTORIAL 10 tng schema Added descriptors for: Tests, Policies and SLAs. tng sdk access Onboarding using a ready-made CLI scripts (tng-onboard) instead of CURL. Support for onboarding on 5GTANGO platform. Support for onboarding on OSM V&V Platform tng vnv lcm API for notification of modified package in catalogue. API for manual test invocation. Initial integration towards SONATA SP. Ability to support creation of test execution plans via tagging mechanism. API for querying test results. tng vnv tee Ability to support creation of test execution plans via tagging mechanism. Support for three test plugin types: Bash, Wrk and TTCN Service Platform son mano framework Northbound API extension with a scaling API: It is now possible to request a scaling event of a running NS. Policy based placement: the Placement Plugin takes placement policies from NS developers, customers and the operator into consideration when calculating the optimal placement. ILP based algorithm: The generic placement algorithm is formulated and solved as an ILP problem. The SSM mechanism was extended so that it can now make scaling and migration requests to the MANO Framework. Improved ENV variable handling. CI/CD done through Jenkins pipeline. Minor bugfixes. tng probes moongen: The MoonGen probe based on the MoonGen packet generator. uperf: Network probe based on uperf network performance tool. owamp: (one-way active measurement protocol) to Prometheus. wrk: HTTP benchmarking tool based mostly on wrk. son sp infrabstract Cloud-init support for HEAT based stacks. Scaling out support for HEAT based stacks.

12 SONATA 4.0 TUTORIAL 11 Minor bugfixes. tng sla mgmt SLA Schema Introduced (YML, JSON). SLA Template examples provided (YML, JSON). Create a new SLA Template with one or more guarantee terms. Automatic formulation of the Agreement, when a Network Service is instantiated. Mark SLA (Agreement) as TERMINATED on service termination. Mark SLA (Agreement) as VIOLATED APIs for SLAs Management are introduced (Check WIKI pages). Consume SLA violation alert from Monitoring Manager (Through MQ). Publish violation alert to another topic (SLA manager driven). Unit tests developed. CheckStyle tests developed. Integration tests developed (tng-tests Github s Repository). Health Check developed (PING/PONG). tng policy mngr Policy Schema Introduced (YML, JSON). Create/Read/Update/Delete a runtime policy for a network service. Associate a runtime policy with an SLA. Define a runtime policy as default (to be enforced if no SLA is selected). Enforce a runtime policy. Request activation of monitoring rules associated with the runtime policy. Realize inference based on set of policy rules and real time monitoring alerts. Produce and enforce intelligent orchestration actions. Unit tests developed. Integration tests developed (tng-tests Github s Repository). tng slice mngr Network Slice Template/Instance Objects Defined. Network Slice manager REST API. Two work modes with SONATA SP (further information in this wiki page: About the work modes). tng gtk sp Allow for service records querying. Allow for function records querying. Allow a Network Service to be instantiated. Allow a Network Service instance to be terminated. Make available an endpoint to allow external entities to conclude about the availability of this micro-service. Make documentation on the supported API available from the root. tng cat Support for JSON and YAML formats for descriptors.

13 SONATA 4.0 TUTORIAL 12 Support of full-text search in the content of the descriptors and the corresponding metadata. Support of GridFS File System for storage of 5GTANGO Packages/Arbitrary Files. Developed Unit Tests for the component. Included in integration tests with several components. Enrichment of package descriptor files with additional metadata. Development of RESTful API for the exposure of the available Create, Read, Update, Delete (CRUD) operations. Intelligent delete of the entire 5GTANGO package from the delete operation of the corresponding package descriptor. Full mapping of the content of the corresponding 5GTANGO Package inside the Package Descriptor. Enrichment of virtualized network function descriptor files with additional metadata. Development of RESTful API for the exposure of the available CRUD operations. Enrichment of network service descriptor files with additional metadata. Development of RESTful API for the exposure of the available CRUD operations. Enrichment of 5GTANGO Package file with additional metadata. Development of RESTful API for the exposure of the available CRD operations of the metadata. Retrieval of the binary data from the GridFS File System. Full mapping of 5GTANGO Package with the included files. Enrichment of arbitrary files with additional metadata. Development of RESTful API for the exposure of the available CRD operations of the metadata. Retrieval of the binary data from the GridFS File System. Enrichment of policy descriptor files with additional metadata. Development of RESTful API for the exposure of the available CRUD operations Enrichment of network slice template files with additional metadata. Development of RESTful API for the exposure of the available CRUD operations. Creation of dynamic update mechanism of arrays included in the descriptors. Enrichment of service level agreement template files with additional metadata. Development of RESTful API for the exposure of the available CRUD operations. tng rep Store network service instance records. Store network slice instance records. Store VNF instance records. Store test suite results. Store tests plans. son monitor Addition of new APIs. Support Alerting for SLA and Policy Components. Support SNMP protocol. Upgrade notification mechanism. Bug fix.

14 SONATA 4.0 TUTORIAL 13 son monitor probe Update metric labels. Update metric labels. tng monitor infra Add collection mechanism from OpenStack ceilometer. Add collection mechanism from OpenDayLight controller. tng gtk vnv Test querying. Test plans querying. Test results querying. tng gtk common Allow the uploading of packages. Allow the query of the package processing status. Allow the validation of the uploaded packages. Allow the retrieval (download) of the uploaded package file. Allow the query of package s meta-data. Allow the notification of external systems about the successful un-packaging of a package. Allow the notification of the entity that as uploaded the package about the final result of the process. Allow the query of package s options.allow the query of services s meta-data. Allow the query of services s options. Allow the query of function s meta-data. Allow the query of function s options. Allow the query of the component s root content. Allow the query of the component s availability. tng api gtw A request redirection mechanism (NGINx web server) adequately configured for 5GTANGO s infrastructure. A simple routing mechanism, configurable at deployment time, to route requests from the outside to a specific (set of) micro-services. Support for the main HTTP verbs in the request: GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD. Basic request validation mechanisms, such as HTTP verb(s) allowed, user authentication needed, etc., to avoid invalid requests to proceed within the stack. Logging and KPI collection.

15 SONATA 4.0 TUTORIAL Portal tng portal Includes a Validation and Verification section containing a list of the packages, services, functions and tests. Supports the view of their detailed information including the test s results, as well as the execution of the tests from the interface. Includes a Service Platform section containing: Packages, Services, Functions, Placement Policy, Runtime policies, SLAs and Slices management. Supports the view of the detailed information, the creation of SLAs and slices and the removal of policies, SLAs and slices. Besides, the Portal allows to associate runtime policies with their related SLA, to set one runtime policy to be the default one and finally, the instantiation and termination of the slice templates. Includes a Service Management section containing: Network Services, Requests and Network Service Instances management. Supports the view of the detailed information and the instantiation and termination of the listed network services. Includes searching and filtering tools in the whole application. 5. Installation 5.1 General instructions and main steps The SONATA system consists of the Service Platform for deploying and orchestrating services and the Service Development Kit to create deployable service packages. For running services, the Service Platform uses the capabilities of a VIM (virtual infrastructure manager), specifically OpenStack. In order to use the Service Platform, you therefore need to have access to a running OpenStack installation. In general, the main steps to install a working 5GTANGO system are as follows: 1. Install the Service Platform. 2. Install the V&V. 3. Install the Service Development Kit. 4. Install the Emulator for testing purposes. 5. Install OpenStack (or get access to an existing installation). 6. Connect the Service Platform to OpenStack. 5.2 Service and V&V Platforms installation Recommended specifications for the virtual machines SP VM CPU: 4 cores RAM: 8 GB HDD: 80 GB V&V VM

16 SONATA 4.0 TUTORIAL 15 CPU: 1 cores CPU: 4 GB CPU: 60 GB Installation Instructions Step 1: Create a user sudo adduser tango sudo usermod a G sudo tango Step 2: Packages installation sudo apt get install y software properties common sudo apt add repository y ppa:ansible/ansible sudo apt get update sudo apt get install y ansible sudo apt get install y git sudo apt get install python3 sudo apt install python3 pip sudo update alternatives install /usr/bin/python python /usr/bin/python3 10 sudo pip3 install docker Step 3: Docker-ce sudo apt get update sudo apt get install \ apt transport https \ ca certificates \ curl \ software properties common curl fssl sudo apt key add sudo apt key fingerprint 0EBFCD88 sudo add apt repository \ "deb [arch=amd64] \ $(lsb_release cs) \ stable" sudo apt get update sudo apt get install docker ce Step 4: Create Docker network sudo docker network create tango Step 5: Repository cloning git clone nfv/tng devops.git cd tng devops Step 6: Execute installation For SP: sudo ansible-playbook roles/sp.yml -i environments -e target=localhost --ask-vaultpass For V&V: sudo ansible-playbook roles/vnv.yml -i environments -e target=localhost --askvault-pass

17 SONATA 4.0 TUTORIAL 16 Note: Password = sonata 5.3 SDK The goal of the 5GTANGO SDK is to assist the developer in designing services and/or functions. The SDK is mainly composed by a set of CLI tools, each with a specific purpose following the development workflow Pre requisites The 5GTANGO SDK tools are all implemented in Python and bash: Ubuntu (or later). Python 3 (vim-emu: Python 2.7). Setup tools Installation Instructions Step 1: Descriptor generation For simple use without installation, simply visit: nfv.github.io/tng sdkdescriptorgen/ Alternatively, for self-hosted use of the descriptor generator, use Docker as follows: git clone nfv/tng sdk descriptorgen.git cd tng sdk descriptorgen sudo docker build f Dockerfile t tng sdk descriptorgen:latest. sudo docker run d p 80:80 name descriptorgen rm tng sdk descriptorgen:latest Visit localhost:80 on the browser to access the locally running descriptor generator. Step 2: Project creation Single command installation: pip install git+ nfv/tng sdk project.git Usage: tng sdk project h Step 3: Image creation tng-sdk-img Additional pre-requisites wget curl cloud-utils kvm shyaml

18 SONATA 4.0 TUTORIAL 17 sudo apt install curl wget qemu kvm cloud utils pip install shyaml Installation: git clone nfv/tng sdk img cd tng sdk img sudo./install.sh Usage: tng sdk img h Step 4: Specific Manager Tester To use the component directly, without installation:./go/bin/tng sm To install the component, first golang needs to be installed. Set the GOPATH ENV parameter from the root of this repository: export GOPATH=$(pwd)/go Get the golang dependencies: go get gopkg.in/yaml.v2 go get github.com/nu7hatch/gouuid go get github.com/fatih/color Build and install the project: go build tng sm go install tng sm Step 5: Project Validation Single command installation: pip install git+ nfv/tng sdk validation Usage: tng sdk validate h Step 6: Packager Single command installation: pip install git+ nfv/tng sdk package Usage:

19 SONATA 4.0 TUTORIAL 18 tng sdk package h 5.4 Emulator This emulation platform was created to support network service developers to locally prototype and test their network services in realistic end-to-end multi-pop scenarios. It allows the execution of real network functions, packaged as Docker containers, in emulated network topologies running locally on the developer s machine. The emulation platform also offers OpenStack-like APIs for each emulated PoP so that it can integrate with MANO solutions, like OSM. The core of the emulation platform is based on. The original project was called son-emu and later renamed to vim-emu when the emulator was adopted by the OSM project. We keep the repository name son-emu to not break existing links in publications. The emulation platform vim-emu is developed as part of OSM s DevOps MDG. There are two installation options: Bare-metal and Docker-based Bare metal installation Prerequisites The emulator requires an Ubuntu LTS installation on a bare metal machine or a VM. The following packages need to be installed: ansible aptitude git Installation instructions Step 1: Install Ansible, etc. sudo apt get install ansible git aptitude Step 2: Install Containernet cd git clone cd ~/containernet/ansible sudo ansible playbook i "localhost," c local install.yml Step 3: Install the Emulator cd git clone nfv/son emu.git cd ~/son emu/ansible

20 SONATA 4.0 TUTORIAL 19 sudo ansible playbook i "localhost," c local install.yml Installation videos Installation video: Demo video of son-emu year 1 version: Demo video that shows son-emu with OSM (NetSoft 17 best demo award): Docker based installation Prerequisites The emulator requires an Ubuntu LTS installation on a bare motel machine or a VM. The following packages need to be installed: Docker Installation instructions These steps deploy and start the emulator inside a Docker container. See the GitHub page for further installation options. git clone nfv/son emu cd ~/son emu # build the container: docker build t vim emu img. # run the (interactive) container: docker run name vim emu it rm privileged pid='host' v /var/run/docker.sock:/var/run/docker.sock vim emu img 6. Start using SONATA Using the SONATA System is quite straight forward, you only need to follow the main steps shown in the general workflow figure bellow and explained in detail the following sections.

21 SONATA 4.0 TUTORIAL 20 1 Install all Sonata components (SP, SDK, V&V) 2 Create a NS with the SDK 2.1 FSM creation 3 Upload VNF to glance 5 4 Test the NS with the V&V platform Test the NS with the emulator 6 Deploying the NS with the SP 5.1 Package on boarding 5.2 Generation of SLA templates 5.3 Define runtime policies 5.6 SLA violations 5.5 Monitor a NS 5.4 Instance a NS Figure 3: SONATA use general workflow 6.1 Creating a network service with the SDK The recommended workflow when developing a SONATA network service starts with using the descriptor generation GUI to create suitable descriptors and download them as a project. Then the SDK s CLI tools can be used to create a workspace, manage the project (e.g., adding more descriptors or other files), validate it, and finally create a bundled service package. The required steps are as follows: Generate descriptors The descriptor generator GUI allows quick and easy generation of suitable descriptors (NSD and VNFDs) for a given service. The easiest way to access the descriptor generator GUI is by opening in a browser. In the GUI, fill in the high-level information about the service and involved VNFs. Clicking Add VNF / Remove VNF allows to adjust the number of VNFs in the service and to specify their individual image names and types. After entering the high-level information, click Generate to generate the descriptors and display them in the GUI. If necessary, you can perform further adjustments directly in the GUI (e.g., change the resource requirements). Once satisfied with the descriptors, click Download all to download a zipped 5GTANGO project containing the created descriptors Create a workspace (only required once) tng workspace

22 SONATA 4.0 TUTORIAL Manage the project Unzip the downloaded 5GTANGO project and check its status with: tng project p path/to/project status You can then add further files, e.g., logos or disk images, to the project simply by copying them into the project directory and calling: tng project p path/to/project add path/to/project/new_file After this step, the project should contain all desired files of the network service. Using the --status command, should show the type and number of involved files Validate the syntax, integrity and topology of the descriptors using tng sdkvalidate To validate the correctness of the VNFDs: tng sdk validate function path/to/project/source/vnfd/vnfd1.yml To validate the correctness of the NSD: tng sdk validate service path/to/project/source/nsd/nsd.yml dpath path/to/project/source/vnfd/ dext yml t Create a package tng package p path/to/project After this step, if everything is correct, a package with the file ending.tgo is created. A package can be also unpackaged and turned back into a 5GTANGO project by doing: tng package u path/to/package file.tgo Onboard the package into the SONATA Service Platform or Emulator curl i X POST F package=@misc/package file.tgo These are the most basic steps to develop a network service, however additional features may be used, and configuration procedures may take place when required. For the specific configuration and usage options of the different tools, refer to their individual GitHub Readmes and Wikis. 6.2 Creating a Function Service Manager To develop a new FSM or SSM the following steps need to be taken:

23 SONATA 4.0 TUTORIAL Clone and install the tng sm tool () Please follow The README () install instructions to clone and install the tool correctly Create a new FSM or SSM by executing tng sm new type fsm <fsm name> This command creates an FSM (similar for SSM) based on a generic template. It contains all the code to package the FSM as a container, to connect it with the Service Platform, and to communicate with the designated SP components Extend the FSM (or SSM) code Do this by editing the python file located at <fsm_name> fsm/<fsm_name>/<fsm_name>.py Test the FSM (or SSM) Test the FSM/SSM with the `execute` command in `tng sm`. More info on how to use this command can be found in the README. tng sm execute event start payload output.yml foo fsm Build the Docker Build the container that packages the FSM and make it available in a public Docker Registry Docker build t <registry_name>/<fsm_id> f <fsm_name> fsm/dockerfile. Docker push <registry_name>/<fsm_id> Add the FSM (or SSM) correctly to the VNFD (or NSD) function_specific_managers: id: <fsm_id> description: Foo bar image: <registry_name>/<fsm_id> 6.3 Upload VNF to glance This step can be useful in order not to wait until Infrastructure abstraction downloads the image from the external link. You can upload it to glance before instantiating the NS. The instantiation will be really fast. Notice that the VNF image name has to be composed by: <vnf_vendor>_<vnf_name>_<vnf_version>_<virtual_deployment_units_id> You can find this information in the NSD, specifically in the network_functions section:

24 SONATA 4.0 TUTORIAL 23 vnf_id: "vtc_vnf" '''vnf_vendor: "eu.sonata nfv"''' '''vnf_name: "vtc vnf"''' '''vnf_version: "0.1"''' And in the VNFD in the virtual_deployment_units section: ''' id: "1"''' The final name in glance will be: * eu.sonata nfv_vtc vnf_0.1_1 For the deployment, the platform will look at the attribute vm_image_md5 in the images list and will use that image. If not found it will search the image using the vendor, name and version information. 6.4 Testing a network service with the EMULATOR To deploy and test a network service on the emulation platform you can use the 5GTANGO SDK tools just like you would do when creating a service package for the service platform. You can find an example service package and a detailed description of the workflow at: The main steps are as follows (all executed in the son-emu folder cloned from GitHub): Start the emulator: sudo python examples/tango_default_cli_topology_2_pop.py Create a SONATA service package using son cli: tng pkg p misc/tango demo service project/ Deploy the created service package on the emulator: curl i X POST F package=@misc/eu.5gtango.emulator example service.0.1.tgo Instantiate the service: curl X POST d "{}" Check the running SONATA service: vim emu compute list The output will show you the running VNFs of the service and the emulated datacenters:

25 SONATA 4.0 TUTORIAL Testing a network service with the V &V Platform A particular test can be run by pressing the run icon from the tests perspective under the V&V control panel. Figure 4: V&V Platform control panel This task can also be executed via terminal commands by using the curl command. The main steps are: 1. List tests and pick the test id that you need to execute: curl target server>:32002/api/v3/tests/descriptors jq [] 2. Post a request to SONATA service package using curl: test_id= <the testid that you want to run> curl v X POST " target server>:6100/tng vnv lcm/api/v1/schedulers/tests" \ H "Content Type: application/json" d '{ "test_uuid": "'$test_id'"}' 3. You can see the test results through the command:

26 SONATA 4.0 TUTORIAL 25 curl vnv server>/api/v3/tests/results jq []; 4. While the test is completing, you can track the test plans and the network services that will be instanced for the execution using the following command: curl vnv server>:4012/trr/test plans jq []; 6.6 Deploying a service with the Service Platform Package On boarding Package on-boarding consists of a sequence of steps, in order to upload and store all the contained artifacts (services and functions) in a given package into the platform s Catalogues. These steps guarantee that only valid functions and services are made available to the platform owner s customers. That sequence of steps is described below. Step 1: Authenticate the developer submitting the package. The openness demanded for the 5G era of Service Platforms do not necessarily imply anonymity. Knowing who its users are, support not only security but also some still unforeseen and arbitrarily complex business models between the different stakeholders. Step 2: Authorize the developer submitting the package. With the expected networkbased relationships between all the stakeholders, access and usage restrictions can naturally be needed, which demands a flexible but strong authorization set of mechanisms to be in place. Step 3: Validating the submitted package. Packages, services and functions have to follow a predefined schema, enabling fully automatic processes to be put in place to orchestrate the service dependent instantiation. Package signing, if present, can also be verified in this phase of the on-boarding process. Furthermore, semantic and logical verifications can be made, e.g., to alert to invalid specified flows of traffic. Step 4: Submission for storage. Valid packages have to be stored, both as the whole file and a set of meta-data that can later be used by the MANO Framework when a service instantiation, update or termination is requested, without having to open and extract that information from the whole package again. With this last step concluded successfully, the service remains ready to be instantiated by any customer of the SP owner (see the following sub-section) Generation of SLA Templates associated to Services Step 1: Create and upload an SLA Template. The operator can create a new SLA Template descriptor for a specific service, based on the SLA Template schema made available in A set of existing SLA Template descriptor examples are made available in In order to generate and upload an SLA Template descriptor at the Catalogue, currently the operator may use the Portal, defining the associated service, the

27 SONATA 4.0 TUTORIAL 26 SLA Template name, an expiration date and by selecting the desired guarantee term. The formulation is easy and quick as the Portal supports a user-friendly interface. Figure 5: Create an SLA Template through the Portal. Step 2: View the list of available SLA Templates. The operator has access to the list of all available SLA Templates and their details at the Portal, in SLA Templates. Figure 6: List of Available SLA Templates.

28 SONATA 4.0 TUTORIAL 27 Figure 7: Show SLA Template details Define Runtime Policies and set Service Applicability Rules Step 1: Create and upload a Policy Descriptor. The operator can create a new Policy Descriptor for a specific service based on the Policy schema made available in A set of existing Policy Descriptor examples are made available in Currently, to upload a Policy Descriptor, the operator has to do a POST call according the following API (in the future Policies descriptors will be defined via Portal). Figure 8: CURL POST Request for Policy Descriptor creation.

29 SONATA 4.0 TUTORIAL 28 Step 2: View the list of available runtime Policies. The operator has access to the list of available Runtime Policies, and their details at the Portal, in Policies Runtime Policies. Figure 9: List of Available Runtime Policies. Step 3: Select a default Policy (optional). In the Portal, the operator is able to define which of the available policies, for a given service, should be applied when the service is instantiated. This Policy will be applied if no other more specific rule exists (see Step 4 below). Figure 10: Default Policy Selection. Step 4: Select an SLA-based Policy (optional). The operator is able to define a specific runtime Policy to be applied on service instantiation, in case a particular SLA is selected by the customer. This rule is more specific than the default rule and precedes it (see Step 3 above). The objective is to design specific runtime Policies, able to cope with the multiple Service Level Objectives (SLOs) defined in the SLAs. Note that higher SLAs levels (Premium) impose more exigent management actions, leading to more demanding resources utilization.

30 SONATA 4.0 TUTORIAL Instantiating a Service Figure 11: SLA-based Policy Selection. Step 1: List available Services. In the Service Management menu, the service customers can go to Available Network Services and see the list of on-boarded services, which are available for him to be instantiated. Figure 12: List the available Services. Step 2: Start the Service instantiation process. The customer can press the green Play button of the desired template to trigger a service instantiation. After pressing this button, the instantiation process will begin.

31 SONATA 4.0 TUTORIAL 30 Figure 13: Available Network Services. Step 3: Fill Ingress and Egress addresses. The customer can set the Ingress and Egress addresses which can be filled to configure the network service at the infrastructure level (optional). After adding this information, the NEXT button allows to continue with the instantiation. Figure 14: Example of Ingress address filling on Service instantiation. Figure 15: Example of Ingress address filling on Service instantiation. Step 4: SLA Selection. The customer selects an SLA to be associated to the service. That will define the level of service contracted, which will define the characteristics of service to be provided (performance, reliability, etc.). This has usually impact on the service cost.

32 SONATA 4.0 TUTORIAL 31 Figure 16: SLA selection on Service instantiation. Step 5: Service instance Naming. The customer can choose a name to identify the new service instance and click on INSTANTIATE to confirm the instantiation. Figure 17: Choose a name and confirm instantiation. Step 6: Check service instance request. The customer can check in Requests the requests for service instantiation and see the details.

33 SONATA 4.0 TUTORIAL 32 Figure 18: List ongoing Requests. Figure 19: Detailed ongoing Requests. Step 7: Check Service instance entry. When the service is successfully instantiated, it is now ready to be used by the customer. The associated SLA, the Policy applied, and other data can be seen in Network Service Instances. SLA and Policy Details can also be seen on the respective menus on the Service Platform. Once the service is instantiated the monitoring is started.

34 SONATA 4.0 TUTORIAL 33 Figure 20: List Service instances. Step 8: View Enforced Runtime Policy Actions. Upon a particular runtime Policy is applied to a service instance, the operator can have access to the list of actions produced. In this way, the operator can see the orchestration actions produced by the Policy and well as the result obtained, i.e. whether the enforcement was successful Monitoring a Service Figure 21: List of generated actions per service instance. Step 1: Collect metrics from NFVI. Metrics Exporter uses the pipeline mechanism provided by OpenStack Ceilometer in order to collect monitoring data for all the VMs inside OpenStack NFVI and expose them to the Prometheus server. The easiest way to use Metrics Exporter is to run it as Docker container and then configure the pipeline feature of the Ceilometer to send data to it. More detailed information is available in Step 2: Collect metrics using SNMP. Monitoring framework provides the ability to collect data using the SNMP protocol. In order to enable the SNMP functionality, the

35 SONATA 4.0 TUTORIAL 34 developer must provide the necessary information (metrics, SNMP OIDs, time interval, etc.) inside the VNF descriptor. snmp_parameters: version: "v2" auth_protocol: "None" security_level: "None" username: "public" port: 3401 interval: 7 oids: - oid: " " metric_name: "cacheuptime" metric_type: "gauge" unit: "secs" mib_name: "SQUID-MIB" - oid: " " metric_name: "cachesysvmsize" metric_type: "gauge" unit: "MB" mib_name: "SQUID-MIB" Step 3: Get Metric list of a VNF. Get list of metrics that are available for a specific function. curl Response: { "status": "Success", "vdus": [ { "metrics": [ { "user_id": "23a53028e98f4c2c957d6e307103c2b4", "display_name": "haproxy-vnf.vdu01-8aaf49d7-01dc f63bafa42a3.ed3c9655-9cb8-4e0a-8605-d6fb26355f11.instance0", "resource_id": "8d50d22b-46a9-43c0-a7b6-d3bd8ab37878", "pop": "athens1", "counter_unit": "%", " name ": "cpu_util", "project_id": "425e1e692db848ed9d1a0f499b73e4e6" }, { "exported_instance": "vnf:8d50d22b-46a9-43c0-a7b6- d3bd8ab37878", "snmp_ip": " ", "exported_job": "snmp", "resource_id": "8d50d22b-46a9-43c0-a7b6-d3bd8ab37878", "snmp_port": "161", " name ": "haproxy_backend_bin" }, { "exported_instance": "vnf:8d50d22b-46a9-43c0-a7b6- d3bd8ab37878", "snmp_ip": " ", "exported_job": "snmp",