...
The idea of using control loops to automatically (or autonomously) perform network management has been the subject of much research in the Network Management research community, see this paper for some background. However, it is only with the advent of ONAP that we have a platform that supports control loops for network management. Before ONAP, Control Loops have been deployed by hard-coding components together and hard coding logic into components. ONAP has taken a step forward towards automatic deployment of applications by allowing parameterization of Control Loops that work on the premise that the Control Loops use a set of analytic, policy, and control components connected together in set ways.
The goal of the work here is to extend and enhance the current ONAP Control Loop support to provide a complete open-source framework for Control Loops. This will enhance the current support to provide TOSCA based Control Loop definition, development, deployment and run-time management. The participants that comprise a Control Loop and the metadata needed to link the participants together to create a Control Loop are specified in a standardized way using the OASIS TOSCA modelling language. The TOSCA description is then used to deploy and manage the Apps in the run time system.
In this Activity, we move beyond this limited approach and support fully model driven Management App deployment using the TOSCA modelling language. As shown in the figure below, the Management App Designer will provide a system where management Apps can be designed and defined in metadata. This means that a Management App can have any arbitrary structure and the Management App developers can use whatever analytic, policy, or control components they like to implement their App. At deployment time, the user parameterises the App and deploys it. A design time catalogue is created. This catalogue contains the primitive metadata for any components that can be used to compose an App. An App SDK is used to compose an App by aggregating the metadata for the components chosen to be used in an app and by constructing the references between the components.
Once the App is composed, it is packaged (TOSCA uses a CSAR archive, a type of zip file). The package consists of the TOSCA file for the App together with any other artifacts that should be passed to components participating in an App when it is instantiated. The package is deployed to the run time part of the system, where it is stored in the run time catalogue and is available for instantiation.
When a user wishes to instantiate an App, they set values for the parameters of the App. Once the parameterization has been carried out, the App is instantiated, with the metadata and whatever other artifacts are required being passed to the participants in the App. At runtime, the App can be monitored and analysed. It can also be updated as required and can be deleted when it is on longer needed.
Performing a hot upgrade of the App at run time as well as handling an upgrade of the software in one or more of the participants in an App is a particularly challenging issue because upgrading must handle the following cases without tearing down the App:
- Upgrade and changes of the configuration data of participants
- Addition of or removal of participants in an App
- Upgrade of software in one or more participants in an App
- Maintenance of compatibility between participants when an update of more than one participant must be done together to ensure compatibility, for example, when a protocol being used by two participants to communicate is upgraded
The App Runtime Management will use Common SMO services for non-functional aspects such as inventory, topology and data delivery. It will also interact with orchestration components using the implementations of the ETSI/MANO standards developed in
The diagram below outlines the architecture of the TOSCA defined control loop management.
...