SONATA 4 - 5GTANGO · 2019. 5. 16. · The SONATA platform supports three main stakeholders in...

SONATA 4.0

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

SEPTEMBER 2018

SONATA 4.0 TUTORIAL | 1

© 5GTANGO Consortium –

Table of contents 1. Introduction .......................................................................................................... 3

1.1 Purpose of this tutorial ....................................................................................... 3

1.1 Document structure ............................................................................................ 3

2. Brief introduction to SONATA ............................................................................ 3

2.1 What´s SONATA? ............................................................................................. 3

2.2 Who is it for? .......................................................................................................... 4

3. General architecture .............................................................................................. 4

3.1 SONATA Modules ................................................................................................. 5

3.1.1 Service Development Kit .............................................................................. 5

3.1.2 V&V Platform .............................................................................................. 6

3.1.3 Service Platform ........................................................................................... 7

4. Release Notes information .................................................................................... 8

4. 1 SDK ........................................................................................................................ 8

4. 2 V&V Platform ...................................................................................................... 10

4. 3 Service Platform ................................................................................................... 10

4. 4 Portal .................................................................................................................... 14

5. Installation .......................................................................................................... 14

5.1 General instructions and main steps ..................................................................... 14

5.2 Service and V&V Platforms installation ............................................................... 14

5.2.1 Recommended specifications for the virtual machines .............................. 14

5.2.2 Installation Instructions .............................................................................. 15

5.3 SDK ....................................................................................................................... 16

5.3.1 Pre-requisites .............................................................................................. 16

5.3.2 Installation Instructions .............................................................................. 16

5.4 Emulator ................................................................................................................ 18

5.4.1 Bare-metal installation ................................................................................ 18

5.4.1 Docker-based installation ........................................................................... 19

6. Start using SONATA .......................................................................................... 19

6.1 Creating a network service with the SDK ............................................................. 20

6.1.1 Generate descriptors ................................................................................... 20

6.1.2 Create a workspace (only required once) ................................................... 20

6.1.3 Manage the project...................................................................................... 21



6.1.4 Validate the syntax, integrity and topology of the descriptors using tng-sdk-validate ................................................................................................................. 21

6.1.5 Create a package ......................................................................................... 21

6.1.6 Onboard the package into the SONATA Service Platform or Emulator .... 21

6.2 Creating a Function Service Manager ................................................................... 21

6.2.1 Clone and install the tng-sm tool () ............................................................ 22

6.2.2 Create a new FSM or SSM by executing .................................................... 22

6.2.3 Extend the FSM (or SSM) code .................................................................. 22

6.2.4 Test the FSM (or SSM) ............................................................................... 22

6.2.5 Build the Docker ......................................................................................... 22

6.2.6 Add the FSM (or SSM) correctly to the VNFD (or NSD) ......................... 22

6.3 Upload VNF to glance .......................................................................................... 22

6.4 Testing a network service with the EMULATOR ........................................... 23

6.4.1 Start the emulator: ....................................................................................... 23

6.4.2 Create a SONATA service package using son-cli: ..................................... 23

6.4.3 Deploy the created service package on the emulator:................................. 23

6.4.4 Instantiate the service: ................................................................................ 23

6.4.5 Check the running SONATA service: ........................................................ 23

6.5 Testing a network service with the V &V Platform ........................................ 24

6.6 Deploying a service with the Service Platform ................................................ 25

6.6.1 Package On-boarding .................................................................................. 25

6.6.2 Generation of SLA Templates associated to Services ................................ 25

6.6.3 Define Runtime Policies and set Service Applicability Rules .................... 27

6.6.4 Instantiating a Service ................................................................................. 29

6.6.5 Monitoring a Service .................................................................................. 33

6.6.6 SLA Violations ........................................................................................... 35

6.6.11 Terminating a Service ............................................................................... 36

7 Support ................................................................................................................ 36

8 List of acronyms ................................................................................................. 37



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 life-

cycle 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.



2.2 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:

https://5gtango.eu/project-outcomes/deliverables/2-uncategorised/31-d2-2-architecture-design.html



Figure 1: SONATA high level architecture

3.1 SONATA Modules

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.

3.1.1 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).



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.

3.1.2 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.



3.1.3 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.



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 sonata-nfv/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.



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.



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.

4. 2 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-3.

4. 3 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.



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.



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.



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.



4. 4 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

5.2.1 Recommended specifications for the virtual machines

SP VM

CPU: 4 cores RAM: 8 GB HDD: 80 GB

V&V VM



CPU: 1 cores CPU: 4 GB CPU: 60 GB

5.2.2 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 https://download.docker.com/linux/ubuntu/gpg | sudo apt‐key add ‐ sudo apt‐key fingerprint 0EBFCD88 sudo add‐apt‐repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(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 https://github.com/sonata‐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-vault-pass For V&V: sudo ansible-playbook roles/vnv.yml -i environments -e target=localhost --ask-vault-pass



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.

5.3.1 Pre‐requisites

The 5GTANGO SDK tools are all implemented in Python and bash:

Ubuntu 16.04 (or later). Python 3 (vim-emu: Python 2.7). Setup tools.

5.3.2 Installation Instructions

Step 1: Descriptor generation For simple use without installation, simply visit: https://sonata‐nfv.github.io/tng‐sdk‐descriptorgen/

Alternatively, for self-hosted use of the descriptor generator, use Docker as follows:

git clone https://github.com/sonata‐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+https://github.com/sonata‐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



sudo apt install curl wget qemu‐kvm cloud‐utils pip install shyaml Installation:

git clone https://github.com/sonata‐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+https://github.com/sonata‐nfv/tng‐sdk‐validation

Usage:

tng‐sdk‐validate ‐h Step 6: Packager

Single command installation:

pip install git+https://github.com/sonata‐nfv/tng‐sdk‐package

Usage:



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

5.4.1 Bare‐metal installation

Prerequisites

The emulator requires an Ubuntu 16.04 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 https://github.com/containernet/containernet.git

cd ~/containernet/ansible

sudo ansible‐playbook ‐i "localhost," ‐c local install.yml Step 3: Install the Emulator cd

git clone https://github.com/sonata‐nfv/son‐emu.git

cd ~/son‐emu/ansible



sudo ansible‐playbook ‐i "localhost," ‐c local install.yml

Installation videos

Installation video: https://www.youtube.com/watch?v=e6pgP-utSeE Demo video of son-emu year 1 version: https://youtu.be/cVJpkQ86aTs Demo video that shows son-emu with OSM (NetSoft’17 best demo award):

https://youtu.be/pFL9wDNOBho

5.4.1 Docker‐based installation

Prerequisites

The emulator requires an Ubuntu 16.04 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 https://github.com/sonata‐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.



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:

6.1.1 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 https://sonata-nfv.github.io/tng-sdk-descriptorgen/ 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.

6.1.2 Create a workspace (only required once)

tng‐workspace

Install all Sonata components(SP, SDK, V&V)

1Create a NS with the SDK

2

2.1 FSM creation

Upload VNF to glance

3

Test the NS with the emulator

4

Test the NS with the V&V platform

5

Deploying the NS with the SP6

5.1 Packageon‐boarding

5.2 Generationof SLA templates

5.3 Define run‐time policies

5.4 Instance a NS

5.5 Monitor a NS

5.6 SLA violations



6.1.3 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.

6.1.4 Validate the syntax, integrity and topology of the descriptors using tng‐sdk‐validate

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 6.1.5 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 6.1.6 Onboard the package into the SONATA Service Platform or Emulator

curl ‐i ‐X POST ‐F package=@misc/package‐file.tgo http://127.0.0.1:5000/packages

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:



6.2.1 Clone and install the tng‐sm tool ()

Please follow The README () install instructions to clone and install the tool correctly.

6.2.2 Create a new FSM or SSM by executing

tng‐sm new –type fsm

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.

6.2.3 Extend the FSM (or SSM) code

Do this by editing the python file located at

‐fsm//.py

6.2.4 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

6.2.5 Build the Docker

Build the container that packages the FSM and make it available in a public Docker Registry

Docker build ‐t / ‐f ‐fsm/Dockerfile. Docker push /

6.2.6 Add the FSM (or SSM) correctly to the VNFD (or NSD)

function_specific_managers: ‐ id: description: “Foo bar” image: /

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: ___

You can find this information in the NSD, specifically in the network_functions section:



‐ 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: https://github.com/sonata-nfv/son-emu/wiki/Example-2

The main steps are as follows (all executed in the son-emu folder cloned from GitHub):

6.4.1 Start the emulator:

sudo python examples/tango_default_cli_topology_2_pop.py

6.4.2 Create a SONATA service package using son‐cli:

tng‐pkg ‐p misc/tango‐demo‐service‐project/

6.4.3 Deploy the created service package on the emulator:

curl ‐i ‐X POST ‐F package=@misc/eu.5gtango.emulator‐example‐service.0.1.tgo http://127.0.0.1:5000/packages

6.4.4 Instantiate the service:

curl ‐X POST http://127.0.0.1:5000/instantiations ‐d "{}"

6.4.5 Check the running SONATA service:

vim‐emu compute list

The output will show you the running VNFs of the service and the emulated datacenters:



6.5 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 http://:32002/api/v3/tests/descriptors | jq []

2. Post a request to SONATA service package using curl:

test_id= curl ‐v ‐X POST "http://: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:



curl https:///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 http://:4012/trr/test‐plans | jq [];

6.6 Deploying a service with the Service Platform

6.6.1 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 network-based 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).

6.6.2 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 https://github.com/sonata-nfv/tng-schema/blob/master/sla-template-descriptor/sla-template-schema.yml. A set of existing SLA Template descriptor examples are made available in https://github.com/sonata-nfv/tng-schema/tree/master/sla-template-descriptor/examples. 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



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.



Figure 7: Show SLA Template details.

6.6.3 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 https://github.com/sonata-nfv/tng-schema/blob/master/policy-descriptor/policy-schema.yml. A set of existing Policy Descriptor examples are made available in https://github.com/sonata-nfv/tng-schema/tree/master/policy-descriptor/examples. Currently, to upload a Policy Descriptor, the operator has to do a POST call according the following API https://github.com/sonata-nfv/tng-policy-mngr#documentation---apis-and-swagger-support (in the future Policies descriptors will be defined via Portal).

Figure 8: CURL POST Request for Policy Descriptor creation.



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.



Figure 11: SLA-based Policy Selection.

6.6.4 Instantiating a Service

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.



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.



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.



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.



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.

Figure 21: List of generated actions per service instance.

6.6.5 Monitoring a Service

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 https://github.com/sonata-nfv/tng-monitor-infra/wiki/VM-monitoring.

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



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: "1.3.6.1.4.1.3495.1.1.3.0" metric_name: "cacheUptime" metric_type: "gauge" unit: "secs" mib_name: "SQUID-MIB" - oid: "1.3.6.1.4.1.3495.1.1.1.0" 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 http://:8000/api/v1/prometheus/vnf//metrics/list

Response: { "status": "Success", "vdus": [ { "metrics": [ { "user_id": "23a53028e98f4c2c957d6e307103c2b4", "display_name": "haproxy-vnf.vdu01-8aaf49d7-01dc-4093-9870-1f63bafa42a3.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": "10.100.32.227", "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": "10.100.32.227", "exported_job": "snmp",



"resource_id": "8d50d22b-46a9-43c0-a7b6-d3bd8ab37878", "snmp_port": "161", "__name__": "haproxy_Uptime_sec" } ], "vdu_id": "8d50d22b-46a9-43c0-a7b6-d3bd8ab37878" } ] }

Step 4: Get monitoring data. Get monitoring data for “cpu_util” metric for a specific function. curl -s \ -H "Accept: application/json" \ -H "Content-Type:application/json" \ -X POST --data '{"name":"cpu_util","start": "2018-08-30T10:51:07Z", "end": "2018-08-30T11:00:21Z", "step": "10s", "labels": []}' "http://:8000/api/v1/prometheus/vnf//metrics/data"

Response: {"metrics": { "resultType": "matrix", "result": [{ "metric": { "user_id": "23a53028e98f4c2c957d6e307103c2b4", "display_name": "haproxy-vnf.vdu01.86f36eb1-42c2-4d84-bdc1-3b0caf1153d1.instance0", "resource_id": "6cff3faa-def7-457c-bb26-1aaddf1c9b05", "pop": "athens1", "instance": "10.100.32.200:9091", "counter_unit": "%", "__name__": "cpu_util", "project_id": "425e1e692db848ed9d1a0f499b73e4e6" }, "values": [ [1532334927, "7.739714839579372"], [1532334937, "7.739714839579372"], [1532334947, "7.739714839579372"], [1532334957, "7.739714839579372"], [1532334967, "4.735440257536171"], [1532334977, "4.735440257536171"], [1532334987, "4.735440257536171"] ] }] } }

6.6.6 SLA Violations

Step 1: SLA Violation model. As described in the previous section, all VNFs are monitored through the Monitoring framework. The SLA Manager uses this framework to check the appropriate metrics associated to the service SLA Objectives (performance, reliability, etc.). The SLA sets thresholds on the desired metrics and gets notified when



those values are overtaken. After further examination, these notifications may lead to service violations, which will trigger a notification. Those can be shown by the operator in the Portal on “SLA” “Violations”.

Figure 22: List SLA Violations.

6.6.11 Terminating a Service

Step 1: Terminate a Service. The customer can go to “Network Services Instances” and see the list of his running service instances. The red button in each instance entry can be used to terminate the service. After pressing this button the terminate process will begin.

Figure 23: Network Services Instances

7 Support The 5GTANGO project team provides limited support on a best-effort basis. There are two different types of support: bug reporting and installation support.

If you encounter bugs in the software, please go to the SONATA GitHub repository (https://github.com/sonata-nfv), select the affected component and open an issue.

For support on the installation, deployment and operation of the Development Kit, the V&V platform and the SONATA Service Platform and, please send an email to [email protected].



8 List of acronyms 5G “5th Generation” Networks API Application Programming Interface BSS Business Support System CLI Command Line Interface CRUD Create, Read, Update, Delete DevOps Development and Operations (workflow and organizational concept) ETSI European Telecommunications Standards Institute (SDO) FSM Function Specific manager GUI Graphical User Interface KPI Key Performance Indicators MANO Management and Orchestration (layer of the ETSI NFV architecture) MSD Monitor Service Descriptor NFV Network Function Virtualization NFVO NFV Orchestrator (component of MANO) NS Network Service NSD Network Service Descriptor OSM Open Source MANO PoP Point of Presence REST Representational State Transfer SDK Software Development Kit SLA Service Level Agreement SP Service Platform SSM Service Specific Manager URL Uniform Resource Locator V&V Validation and Verification VIM Virtual Infrastructure Manager (component of MANO) VM Virtual Machine VN Virtual Network VNF Virtual Network Function VNFD Virtual Network Function Descriptor VNFM VNF Manager (component of MANO) WIM WAN Infrastructure Manager

SONATA 4 - 5GTANGO · 2019. 5. 16. · The SONATA platform supports three main stakeholders in...

Documents

Transcript of SONATA 4 - 5GTANGO · 2019. 5. 16. · The SONATA platform supports three main stakeholders in...