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. However,
The diagram below outlines the architecture of the TOSCA defined control loop management.
A TOSCA file contains the descriptor of the control loop. The entire control loop definition, including references to required artifacts, are included in the TOSCA file. The TOSCA file may be packaged in a CSAR, which also includes further artifacts that are required to deploy and instantiate a control loop.
A Control Loop service template is made up of several components, those which represent applications, those which represent dynamic config schemas, and the actual node_templates which makes up the loop itself.
Applications can be a DCAE microservice, an operational policy, or any other application as long as it can be modelled, and the targeted ecosystem to has a participant client waiting for the event distributions from CLAMP via DMaaP MR.
Dynamic config on the other hand can be a monitoring policy, or any other resource that provides config to parts of the loop, can be updated after the run time phase has started and is supported by the components hosting the applications in the control loop.
2.1: Control Loop TOSCA file definition
2.1.1 Application Definition
Application Node DefinitionExpand source
node_types:
org.onap.APP:
properties:
application_name:
type: string
description: Human readable name for the application.
required: true
provider:
type: string
description: Provider of the application and of the descriptor.
required: true
application_version:
type: string
description: Software version of the application.
required: true
resource_id:
type: string
description: >The ID of the resource,
should be provided if the resource was uploaded to the entity's inventory already.
required: false
resource_content:
type: string
description: the contents of the application resource, to be uploaded during deploy phase of loop.
required: false
monitoring_policy:
type: string
description: A reference to the monitoring policy if applicable.
required: false
version: 0.0.1
derived_from: tosca.nodes.Root
2.1.2 Loop Definition
The loop definition is implicit in the node_templates within the topology_template, any node contained within is expected to be a part of the control loop managed by CLAMP.
Loop DefinitionExpand source
topology_template:
inputs:
pm_docker_image:
type: string
description: docker image used for deploying the PMSH service.
required: true
operational_policy_name:
type: string
description: name of the operational policy to be triggered on MR when subscription is created.
required: true
outbound_topic_name:
type: string
description: Name of topic used for messages to policy.
required: true
feedback_topic_name:
type: string
description: Name of topic used for feedback from policy.
required: true
inventory_notification_topic_name:
type: string
description: Name of topic used for inventory inventory notifications.
required: true
node_templates:
...
2.1: Modelling from TOSCA to Deployment Data in Run Time Catalogue
2.2: Modelling from TOSCA to Instance Data Run Time Catalogue
