D4.2 Final release of the service validation SDK toolset · 1.2.1 Cloud-native support Cloud-native design of services and NFs are therefore considered as the anticipated future of

Document 5GTANGOD42Date June 5 2019 Security PublicStatus To be approved by EC Version 10

3182 Architecture

Scope

5GTANGO allows developers to add Service and Function Specific Managers to the descriptorsof network services and functions This is a distinctive feature of SONATA and 5GTANGO asit enables customisation of otherwise rigid orchestration and configuration capabilities availablein other MANO platforms These specific managers are processes which interact with the ServicePlatform using a well-defined API over the SP pubsub bus [19] and incorporate service or functionspecific orchestration behaviour Service Specific Managers customise orchestration behaviour forNS life cycle events while Function Specific Managers customise VNF orchestration events Thedeveloper adds them to the relevant descriptor together with detailing which workflow they cus-tomise or extend When the Service Platform needs to execute a network service life cycle eventit will first check whether one or more SSMs are associated with this service and workflow Ifthat is the case the Service Platform will execute this SSM ie process instead of executing thegeneric workflow A similar behaviour can be expected for network function life cycle events andFSMs SM functionality enables NS- or VNF-specific placement START- and STOP behaviourconfiguration monitoring scaling migration and fail-over

Over the course of SONATA it was proven that developing and testing specific managers wasa slow process and error-prone For this reason D41 introduced tng-sdk-sm into the SDK atool that generates SSM and FSM templates and allows the developer to test their functionalitylocally after adjusting them speeding up their development significantly and overcoming the cum-bersome process of interacting with operator logging components to obtain debug information onthe functioning of these specific managers

Testing Service Specific Managers

With Release 50 tng-sdk-sm now supports local testing of SSMs From the toolrsquos perspectivethis is more challenging than FSM testing FSMs are used by the SP MANO Framework tointeract with the VNF VMs and containers making them the last shackle in the chain of a MANOFramework workflow Therefore they can be tested by mocking MANO Framework inputs andevaluate whether the resulting interaction with a VM or container was executed as expected SSMshowever are part of the MANO Frameworkrsquos core operations They can trigger new workflowsthey can alter workflows they can provide custom payloads to FSMs that will result in differentVM or container configurations etc

Because of this wide variety of SSM outcome mocking MANO Framework interaction to testSSMs quickly becomes very complex It would require anticipating all possible outputs of an SSMwith appropriate follow-up MANO Framework requests to continue the workflow in which the SSMis being tested Since this logic is already present in the actual MANO Framework it makes moresense to use the real MANO Framework instead of developing a mock with a lot of duplicate codeTherefore we refactored the SONATA MANO Framework so it can operate stand-alone withoutneeding most of the other SP components in a local environment The reason we deploy onlythe MANO Framework and not the entire SP is to have a quicker and more lightweight setup tofurther decrease testing times and reduce any stress on local resources These are the componentsthat are part of the local MANO Framework setup

bull RabbitMQ Message Broker

bull MongoDB

bull MANO Framework

5GTANGO Public 33

Document 5GTANGOD42Date June 5 2019 Security PublicStatus To be approved by EC Version 10

ndash Service Lifecycle Manager

ndash Function Lifecycle Manager

ndash Plugin Manager

ndash Placement Plugin

ndash Specific Manager Registry

bull Repositories

bull Emulator Wrapper

For the testing purposes we approach the MANO Framework as a black box We use its north-bound API (not through the Gatekeeper as is the case in the SP but through the message broker)to request it to execute certain workflows If these workflows include the use of an SSM the MANOFramework automatically deploys and uses them To test the functionality of the SSM we waituntil the MANO Framework is finished with the requested workflow and then evaluate the resultof this workflow For this evaluation we can access the SSM logs the MANO logs and the MANOoutcome report

Since almost all MANO Framework workflows require interaction with the infrastructure thatis being orchestrated we need to make sure that it receives valid responses when making requeststowards to infrastructure Since SSMs and FSMs might require to interact with VNF VMs or con-tainers directly mocking the infrastructure is not an option Indeed with a mocked infrastructurea specific managers will never be able to set up an SSH connection with a VM resulting in specificmanagers that canrsquot be tested As we donrsquot want to expect the developers to have actual infras-tructure available we make use of the SDKrsquos Emulator tool which allows any developer to emulateboth compute and networking resources in their local environment In order for the MANO Frame-work to be able to orchestrate on these emulated resources we developed an Emulator wrapperthat translates MANO Framework infrastructure requests into calls for the Emulator REST API

With the lightweight setup of the SONATA MANO Framework the Emulator wrapper and theEmulator we can now quickly test SSMs in a local environment Fig 310 shows the entire localsetup created by tng-sdk-sm in order to test SSMs

Simplification of the Specific Manager Model

As feedback on earlier releases the Specific Manager Model was deemed cumbersome Numerousfields (eg sm type sm name sm version sm id ) had to be present in both the specific managercode registration message and container name to obtain a successful on-boarding and attachmentof the specific manager within the SP To improve this a simplification of the model was proposedtogether with an associated refactoring of the MANO Framework From Release 50 onwards thereare no longer limitations on the container name of a specific manager and the only required fieldsin the registration message are

selfsm_id = ltidgt

selfsm_version = ltversiongt

3183 Installation

tng-sdk-sm tool is a golang application How to install it is described in the Readme of theassociated GitHub repository [13]

34 Public 5GTANGO

Document 5GTANGOD42Date June 5 2019 Security PublicStatus To be approved by EC Version 10

Figure 310 tng-sdk-sm local setup for SSM testing

3184 Usage

tng-sdk-sm can be used from the CLI as follows

usage tng-sm [--version] [--help]

These are the subcommands for lsquotng-smlsquo

new Create a new specific manager

delete Delete an existing specific manager

execute Execute an event of a specific manager

generate Generate artefacts to be used when executing specific managers

usage tng-sm new ltspecific manager namegt

--path Path where new specific manager should be stored

--type Type of specific manager to be created ssm or fsm

usage tng-sm delete ltspecific manager namegt

--path Path where specific manager can be found

usage tng-sm execute ltspecific manager namegt

--path Path where specific manager can be found

--event Event that needs to be executed

--payload Payload for the execution

5GTANGO Public 35

Document 5GTANGOD42Date June 5 2019 Security PublicStatus To be approved by EC Version 10

usage tng-sm generate ltname output filegt

--type Type of payload to be generated vnfr or nsr

--descriptor File that serves as input for generation should be a vnfd

or nsd

319 State management support

Most network functions need to store a certain amount of state The type and the extent of statethat a particular network function keeps depends on the purpose of a function as well as on its im-plementation Typically the state is kept locally inside the respective VNF For certain use casesthough the state needs to be transferred from one location to another As described in deliverableD22 [14] such use cases include in particular migration fail-over upgrade and scale-outin Fur-thermore as detailed in deliverable D41 [20] state management requires support from the MANOsystem for properly orchestrating the process for migration upgrade or scaling Although the typeof state is service-specific the processes for managing state can still be generalized and integratedwith most if not all services Such support includes run-time functions as well as tools whichfacilitate the development and testing of state-aware services Together they form an integral partof the NFV DevOps cycle

3191 Release 50

Release 50 is the first release in which state management functions are shipped as part of 5GTANGOAs a result no change log is given since all developments can be considered as new

3192 Patterns for state management

State management as required by the above mentioned use cases typically involves a small numberof basic activities These basic activities are exporting state importing state transferring stateand storing state Scaling processes might also include activities related to splitting and mergingstate upgrading might require the translation of state data

Based on these basic activities a number of state management patterns can be described Thesepatterns are (i) direct state transfer (ii) state replication and (iii) state proxying as shown inFig 311 and described in the following

bull Direct state transfer refers to transferring state directly from one VNF to another (Fig 311a)In this process the source VNF gathers all its internal state and puts it into some formatthat allows the complete state to be moved around In the direct state transfer case thestate data is then sent to the destination VNF eg via a direct TCP connection Thedestination VNF accepts that state data and translates it into its internal data structuresThe destination VNF can now seamlessly take over the work of the source VNF Related tothe basic activities introduced before this process executes the following activities exportstate transferring state and import state

bull State replication is similar to direct state transfer as state is also directly sent from thesource VNF to one or more destination VNFs (Fig 311b) But while direct state transfer isa one-shot activity transferring state upon receipt of some explicit trigger state replicationis a continuous activity where state updates are constantly sent from the source to thedestination The basic activities of exporting transferring and importing state are the samefor both patterns but the data transferred is different it consists of the whole state for direct

36 Public 5GTANGO

Document 5GTANGOD42Date June 5 2019 Security PublicStatus To be approved by EC Version 10

Figure 311 State management patterns

state transfer but only state updates (ie differences to previous state) in the case of statereplication

bull The pattern of state proxying does not transfer state directly between source and destinationVNFs (Fig 311c) It rather has a third component (ldquoproxyrdquo) in between the source andthe destination which temporarily stores state The source VNF sends its state to the proxywhich stores the state It then later on hands that state out to the destination VNF In termsof basic activities state proxying executes them in the following order export state (at thesource VNF) transfer state (to the proxy) store state (at the proxy) transfer state (to thedestination VNF) import state (at the destination VNF)

Besides these explicit state handling patterns the stateless function pattern well-known fromWeb and cloud applications can be used In this pattern VNFs do not keep internal state at allbut rather use some external service to manage it typically a data base (including SQL no-SQLin-memory key-value store etc) This pattern can be seen as a combination of the state proxyingand the replication patterns as data is kept externally but state updates are continuously sent tothe data base This pattern is not explored here as it is usually realized on the application layerwithout support of the MANO system

When looking at the basic activities it can be noted that activities for exporting and importingstate are specific to the function and implementation of each VNF Although these activities canbe supported by the programming language or framework (eg serialization in the Java language)they are not an NFV MANO-related activity and are therefore out of scope of the 5GTANGOproject

The activities for transferring and storing state can be generalized and used by many VNFsIn particular as they are part of the management and orchestration processes there should beappropriate support by the MANO system Such support has been investigated designed andimplemented prototypically by the 5GTANGO project

5GTANGO Public 37

Document 5GTANGOD42Date June 5 2019 Security PublicStatus To be approved by EC Version 10

3193 State transfer and storage support

In order to support state storage in a MANO environment a common storage space should beoffered by the system In particular the storage space should be managed by the MANO systemnot each individual network service or VNF In that way the lifecycle of the storage is independentof the lifecycle of the service This arrangement cleanly separates the responsibilities and tasksbetween the service developer and the service operator The service operator gains greater controlof the services and their environments as she can provision and manage the storage as fits herpolicies and priorities best Furthermore development of network services becomes easier andfaster as the application developer does not need to deal with acquiring and managing the storagespace himself As an additional benefit resource usage will drop if multiple services use the samestorage space instead of separate instances per service

Access to the storage space can be provided in many ways and needs to be in line with thecapabilities and requirements of the deployed services and VNFs Most existing software usedas VNFs already has some support for state transfer eg in the form of a replication scheme Ifsuch transfer mechanism already exists it is less invasive and usually less costly to use that existingscheme and not touch the code for adding a new one In these cases it makes sense to offer a storage(and transfer) interface that is matching the one already used by the VNF software eg the NFSprotocol

The choice of storage backend is largely independent of the access method used Data can bestored on the file system local to the MANO system or in cloud storage It can be in a key-valuestore or in an SQL data base In most cases multiple options will be available depending on thepreferences of the operator and the deployed services

In order to use a provided storage space a reference to it (eg IP address URL) must beprovided to VNFs How this happens is implementation specific but can generally be realizedvia adaptor components which on the one side receive information about storage spaces from theMANO system and on the other pass this information on to the VNFs in their specific fashionsA similar scheme of information transfer is needed for the direct state transfer pattern in order tomake the VNFs aware of their peer functions

3194 State management process support

Use of storage spaces as well as the orchestration of state management processes needs to be adaptedto the specific network services and VNFs The SONATA platform already provides such a service-specific adaptation mechanism via service-specific and function-specific managers (SSMsFSMs)These managers can be extended to also provide state management capabilities specific to theirmanaged entities

The managers need to map generic lifecycle events and associated information to the specificsof their managed services and functions For state management one such mapping is neededduring the configuration phase in which information about the location of a state storage spaceis communicated to the respective VNFs For example a VNF storing state in a key-value storeneeds to get information about where this store is located eg in the form of an IP address anda TCP port number Similarly a service storing state data as a file needs to get the location ofthe network file system (NFS) server the directory name and potentially access credentials Suchdata can be transferred to the VNFs in a specific way eg via Ansible or SSH The SSMsFSMscollaborate with the rest of the MANO system from which they retrieve details about availablestorage mechanisms and locations and pass the appropriate one on to the VNFs

The other lifecycle events which need to be mapped onto service-specific activities are the mi-gration upgrading and scaling processes In order to support these activities a number of lifecycle

38 Public 5GTANGO