1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
3 .. _clamp-controlloop_architecture-label:
5 TOSCA Defined Control Loops: Architecture and Design
6 ####################################################
12 The idea of using control loops to automatically (or autonomously) perform network management
13 has been the subject of much research in the Network Management research community, see
14 :download:`this paper <files/ControlLoops.pdf>` for some background. However, it is only with
15 the advent of ONAP that we have a platform that supports control loops for network management.
16 Before ONAP, Control Loops have been implemented by hard-coding components together and hard
17 coding logic into components. ONAP has taken a step forward towards automatic implementation
18 of Control Loops by allowing parameterization of Control Loops that work on the premise that
19 the Control Loops use a set of analytic, policy, and control components connected together in
22 The goal of the work is to extend and enhance the current ONAP Control Loop support to provide
23 a complete open-source framework for Control Loops. This will enhance the current support to
24 provide TOSCA based Control Loop definition and development, commissioning and run-time management.
25 The participants that comprise a Control Loop and the metadata needed to link the participants
26 together to create a Control Loop are specified in a standardized way using the `OASIS TOSCA
27 modelling language <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/>`_. The TOSCA
28 description is then used to commission, instantiate, and manage the Control Loops in the run
31 .. image:: images/01-controlloop-overview.png
36 This section describes the terminology used in the system.
38 1.1 Control Loop Terminology
39 ----------------------------
41 **Control Loop Type:** A definition of a Control Loop in the TOSCA language. This definition describes
42 a certain type of a control loop. The life cycle of instances of a Control Loop Type are managed
45 **Control Loop Instance:** An instance of a Control Loop Type. The life cycle of a Control Loop
46 Instance is managed by CLAMP. A Control Loop Instance is a set of executing elements on which
47 Life Cycle Management (LCM) is executed collectively. For example, a set of microservices may be
48 spawned and executed together to deliver a service. This collection of services is a control loop.
50 **Control Loop Element Type:** A definition of a Control Loop Element in the TOSCA language. This
51 definition describes a certain type of Control Loop Element for a control loop in a Control
54 **Control Loop Element Instance:** A single entity executing on a participant, with its Life Cycle
55 being managed as part of the overall control loop. For example, a single microservice that is
56 executing as one microservice in a service.
58 **CLAMP Control Loop Runtime:** The CLAMP server that holds Control Loop Type definitions and manages
59 the life cycle of Control Loop Instances and their Control Loop Elements in cooperation with
63 1.2 Participant Terminology
64 ---------------------------
66 **Participant Type:** Definition of a type of system or framework that can take part in control
67 loops and a definition of the capabilities of that participant type. A participant advertises
68 its type to the CLAMP Control Loop Runtime.
70 **Participant:** A system or framework that takes part in control loops by executing Control Loop
71 Elements in cooperation with the CLAMP Control Loop Runtime. A participant chooses to partake
72 in control loops, to manage Control Loop Elements for CLAMP, and to receive, send and act on
73 LCM messages for the CLAMP runtime.
75 1.3 Terminology for Properties
76 ------------------------------
78 **Common Properties:** Properties that apply to all Control Loop Instances of a certain Control
79 Loop Type and are specified when a Control Loop Type is commissioned.
81 **Instance Specific Properties:** Properties that must be specified for each Control Loop Instance
82 and are specified when a Control Loop Instance is Initialized.
84 1.4 Concepts and their relationships
85 ------------------------------------
87 The UML diagram below shows the concepts described in the terminology sections above and how
88 they are interrelated.
90 .. image:: images/02-controlloop-concepts.png
92 The Control Loop Definition concepts describe the types of things that are in the system. These
93 concepts are defined at design time and are passed to the runtime in a TOSCA document. The
94 concepts in the Control Loop Runtime are created by the runtime part of the system using the
95 definitions created at design time.
97 .. _controlloop-capabilities:
102 We consider the capabilities of Control Loops at Design Time and Run Time.
104 At Design Time, three capabilities are supported:
106 #. **Control Loop Element Definition Specification.** This capability allows users to define Control
107 Loop Element Types and the metadata that can be used on and configured on a Control Loop Element
108 Type. Users also define the Participant Type that will run the Control Loop Element when it is
109 taking part in in a control loop. The post condition of an execution of this capability is that
110 metadata for a Control Loop Element Type is defined in the Control Loop Design Time Catalogue.
112 #. **Control Loop Element Definition Onboarding.** This capability allows external users and systems
113 (such as SDC or DCAE-MOD) to define the metadata that can be used on and configured on a Control
114 Loop Element Type and to define the Participant Type that will run the Control Loop Element when
115 it is taking part in in a control loop. The post condition of an execution of this capability
116 is that metadata for a Control Loop Element Type is defined in the Control Loop Design Time
119 #. **Control Loop Type Definition.** This capability allows users and other systems to create Control
120 Loop Type definitions by specifying a set of Control Loop Element Definitions from those that
121 are available in the Control Loop Design Time Catalogue. These Control Loop Elements will
122 work together to form Control Loops. In an execution of this capability, a user specifies the
123 metadata for the Control Loop and specifies the set of Control Loop Elements and their Participant
124 Types. The user also selects the correct metadata sets for each participant in the Control Loop
125 Type and defines the overall Control Loop Type metadata. The user also specifies the Common
126 Property Types that apply to all instances of a control loop type and the Instance Specific
127 Property Types that apply to individual instances of a Control Loop Type. The post condition for
128 an execution of this capability is a Control Loop definition in TOSCA stored in the Control Loop
129 Design Time Catalogue.
132 Once a Control Loop Definition is commissioned to the Control Loop Runtime and has been
133 stored in the Run Time Inventory, it cannot be further edited unless it is decommissioned.
136 At Run Time, the following participant related capabilities are supported:
138 #. **System Pre-Configuration.** This capability allows participants to register and deregister
139 with CLAMP. Participants explicitly register with CLAMP when they start. Control Loop Priming
140 is performed on each participant once it registers. The post condition for an execution of this
141 capability is that a participant becomes available (registration) or is no longer available
142 (deregistration) for participation in a control loop.
144 #. **Control Loop Priming on Participants.** A participant is primed to support a Control Loop Type.
145 Priming a participant means that the definition of a control loop and the values of Common
146 Property Types that apply to all instances of a control loop type on a participant are sent
147 to a participant. The participant can then take whatever actions it need to do to support
148 the control loop type in question. Control Loop Priming takes place at participant
149 registration and at Control Loop Commissioning. The post condition for an execution of this
150 capability is that all participants in this control loop type are commissioned, that is they
151 are prepared to run instances of their Control Loop Element types.
154 At Run Time, the following Control Loop Life Cycle management capabilities are supported:
156 #. **Control Loop Commissioning:** This capability allows version controlled Control Loop Type
157 definitions to be taken from the Control Loop Design Time Catalogue and be placed in the
158 Commissioned Control Loop Inventory. It also allows the values of Common Property Types
159 that apply to all instances of a Control Loop Type to be set. Further, the Control Loop
160 Type is primed on all concerned participants. The post condition for an execution of this
161 capability is that the Control Loop Type definition is in the Commissioned Control Loop
162 Inventory and the Control Loop Type is primed on concerned participants.
164 #. **Control Loop Instance Life Cycle Management:** This capability allows a Control Loop
165 Instance to have its life cycle managed.
167 #. **Control Loop Instance Creation:** This capability allows a Control Loop Instance to be
168 created. The Control Loop Type definition is read from the Commissioned Control Loop
169 Inventory and values are assigned to the Instance Specific Property Types defined for
170 instances of the Control Loop Type in the same manner as the existing CLAMP client does.
171 A Control Loop Instance that has been created but has not yet been instantiated on
172 participants is in state UNINITIALIZED. In this state, the Instance Specific Property Type
173 values can be revised and updated as often as the user requires. The post condition for an
174 execution of this capability is that the Control Loop instance is created in the
175 Instantiated Control Loop Inventory but has not been instantiated on Participants.
177 #. **Control Loop Instance Update on Participants:** Once the user is happy with the property
178 values, the Control Loop Instance is updated on participants and the Control Loop Elements
179 for this Control Loop Instance are initialized or updated by participants using the control
180 loop metadata. The post condition for an execution of this capability is that the Control
181 Loop instance is updated on Participants.
183 #. **Control Loop State Change:** The user can now order the participants to change the state
184 of the Control Loop Instance. If the Control Loop is set to state RUNNING, each participant
185 begins accepting and processing control loop events and the Control Loop Instance is set
186 to state RUNNING in the Instantiated Control Loop inventory. The post condition for an
187 execution of this capability is that the Control Loop instance state is changed on
190 #. **Control Loop Instance Monitoring:** This capability allows Control Loop Instances to be
191 monitored. Users can check the status of Participants, Control Loop Instances, and Control
192 Loop Elements. Participants report their overall status and the status of Control Loop
193 Elements they are running periodically to CLAMP. Clamp aggregates these status reports
194 into an aggregated Control Loop Instance status record, which is available for monitoring.
195 The post condition for an execution of this capability is that Control Loop Instances are
198 #. **Control Loop Instance Supervision:** This capability allows Control Loop Instances to be
199 supervised. The CLAMP runtime expects participants to report on Control Loop Elements
200 periodically. The CLAMP runtime checks that periodic reports are received and that each
201 Control Loop Element is in the state it should be in. If reports are missed or if a
202 Control Loop Element is in an incorrect state, remedial action is taken and notifications
203 are issued. The post condition for an execution of this capability is that Control Loop
204 Instances are being supervised by the CLAMP runtime.
206 #. **Control Loop Instance Removal from Participants:** A user can order the removal of a Control
207 Loop Instance from participants. The post condition for an execution of this capability is
208 that the Control Loop instance is removed from Participants.
210 #. **Control Loop Instance Deletion:** A user can order the removal of a Control Loop Instance
211 from the CLAMP runtime. Control Loop Instances that are instantiated on participants cannot
212 be removed from the CLAMP runtime. The post condition for an execution of this capability
213 is that the Control Loop instance is removed from Instantiated Control Loop Inventory.
215 #. **Control Loop Decommissioning:** This capability allows version controlled Control Loop Type
216 definitions to be removed from the Commissioned Control Loop Inventory. A Control Loop
217 Definition that has instances in the Instantiated Control Loop Inventory cannot be removed.
218 The post condition for an execution of this capability is that the Control Loop Type
219 definition removed from the Commissioned Control Loop Inventory.
222 The system dialogues for run time capabilities are described in detail on the
223 :ref:`System Level Dialogues <system-level-label>` page.
225 .. _controlloop-instance-states:
227 2.1 Control Loop Instance States
228 --------------------------------
230 When a control loop definition has been commissioned, instances of the control loop can be
231 created, updated, and deleted. The system manages the lifecycle of control loops and control
232 loop elements following the state transition diagram below.
234 .. image:: images/03-controlloop-instance-states.png
236 3 Overall Target Architecture
237 =============================
239 The diagram below shows an overview of the architecture of TOSCA based Control Loop
242 .. image:: images/04-overview.png
244 Following the ONAP Reference Architecture, the architecture has a Design Time part and
247 The Design Time part of the architecture allows a user to specify metadata for participants.
248 It also allows users to compose control loops. The Design Time Catalogue contains the metadata
249 primitives and control loop definition primitives for composition of control loops. As shown
250 in the figure above, the Design Time component provides a system where Control Loops can be
251 designed and defined in metadata. This means that a Control Loop can have any arbitrary
252 structure and the Control Loop developers can use whatever analytic, policy, or control
253 participants they like to implement their Control Loop. At composition time, the user
254 parameterises the Control Loop and stores it in the design time catalogue. This catalogue
255 contains the primitive metadata for any participants that can be used to compose a Control
256 Loop. A Control Loop SDK is used to compose a Control Loop by aggregating the metadata for
257 the participants chosen to be used in a Control Loop and by constructing the references between
258 the participants. The architecture of the Control Loop Design Time part will be elaborated in
261 Composed Control Loops are commissioned on the run time part of the system, where they are
262 stored in the Commissioned Control Loop inventory and are available for instantiation. The
263 Commissioning component provides a CRUD REST interface for Control Loop Types, and implements
264 CRUD of Control Loop Types. Commissioning also implements validation and persistence of incoming
265 Control Loop Types. It also guarantees the integrity of updates and deletions of Control Loop
266 Types, such as performing updates in accordance with semantic versioning rules and ensuring that
267 deletions are not allowed on Control Loop Types that have instances defined.
269 The Instantiation component manages the Life Cycle Management of Control Loop Instances and
270 their Control Loop Elements. It publishes a REST interface that is used to create Control Loop
271 Instances and set values for Common and Instance Specific properties. This REST interface is
272 public and is used by the CLAMP GUI. It may also be used by any other client via the public
273 REST interface. the REST interface also allows the state of Control Loop Instances to be changed.
274 A user can change the state of Control Loop Instances as described in the state transition
275 diagram shown in section 2 above. The Instantiation component issues update and state change
276 messages via DMaaP to participants so that they can update and manage the state of the Control
277 Loop Elements they are responsible for. The Instantiation component also implements persistence
278 of Control Loop Instances, control loop elements, and their state changes.
280 The Monitoring component reads updates sent by participants. Participants report on the
281 state of their Control Loop Elements periodically and in response to a message they have
282 received from the Instantiation component. The Monitoring component reads the contents of
283 the participant messages and persists their state updates and statistics records. It also
284 publishes a REST interface that publishes the current state of all Participants, Control
285 Loop Instances and their Control Loop Elements, as well as publishing Participant and
286 Control Loop statistics.
288 The Supervision component is responsible for checking that Control Loop Instances are correctly
289 instantiated and are in the correct state (UNINITIALIZED/READY/RUNNING). It also handles
290 timeouts and on state changes to Control Loop Instances, and retries and rolls back state
291 changes where state changes failed.
293 A Participant is an executing component that partakes in control loops. More explicitly, a
294 Participant is something that implements the Participant Instantiation and Participant
295 Monitoring messaging protocol over DMaaP for Life Cycle management of Control Loop Elements.
296 A Participant runs Control Loop Elements and manages and reports on their life cycle
297 following the instructions it gets from the CLAMP runtime in messages delivered over DMaaP.
299 In the figure above, five participants are shown. A Configuration Persistence Participant
300 manages Control Loop Elements that interact with the `ONAP Configuration Persistence Service
301 <https://docs.onap.org/projects/onap-cps/en/latest/overview.html>`_
302 to store common data. The DCAE Participant runs Control Loop Elements that manage DCAE
303 microservices. The Kubernetes Participant hosts the Control Loop Elements that are managing
304 the life cycle of microservices in control loops that are in a Kubernetes ecosystem. The
305 Policy Participant handles the Control Loop Elements that interact with the Policy Framework
306 to manage policies for control loops. A Controller Participant such as the CDS Participant
307 runs Control Loop Elements that load metadata and configure controllers so that they can
308 partake in control loops. Any third party Existing System Participant can be developed to
309 run Control Loop Elements that interact with any existing system (such as an operator's
310 analytic, machine learning, or artificial intelligence system) so that those systems can
311 partake in control loops.
313 4. Other Considerations
314 =======================
316 .. _management-cl-instance-configs:
318 4.1 Management of Control Loop Instance Configurations
319 ------------------------------------------------------
321 In order to keep management of versions of the configuration of control loop instances
322 straightforward and easy to implement, the following version management scheme using
323 semantic versioning is implemented. Each configuration of a Control Loop Instance and
324 configuration of a Control Loop Element has a semantic version with 3 digits indicating
325 the **major.minor.patch** number of the version.
328 A **configuration** means a full set of parameter values for a Control Loop Instance.
330 .. image:: images/05-upgrade-states.png
334 #. A Control Loop or Control Loop Element in state **RUNNING** can be changed to a higher patch
335 level or rolled back to a lower patch level. This means that hot changes that do not
336 impact the structure of a Control Loop or its elements can be executed.
338 #. A Control Loop or Control Loop Element in state **PASSIVE** can be changed to a higher
339 minor/patch level or rolled back to a lower minor/patch level. This means that structural
340 changes to Control Loop Elements that do not impact the Control Loop as a whole can be
341 executed by taking the control loop to state **PASSIVE**.
343 #. A Control Loop or Control Loop Element in state **UNINITIALIZED** can be changed to a higher
344 major/minor/patch level or rolled back to a lower major/minor/patch level. This means
345 that where the structure of the entire control loop is changed, the control loop must
346 be uninitialized and reinitialized.
348 #. If a Control Loop Element has a **minor** version change, then its Control Loop Instance
349 must have at least a **minor** version change.
351 #. If a Control Loop Element has a **major** version change, then its Control Loop Instance
352 must have a **major** version change.
357 The system is designed to be inherently scalable. The CLAMP runtime is stateless, all state
358 is preserved in the Instantiated Control Loop inventory in the database. When the user
359 requests an operation such as an instantiation, activation, passivation, or an uninitialization
360 on a Control Loop Instance, the CLAMP runtime broadcasts the request to participants over
361 DMaaP and saves details of the request to the database. The CLAMP runtime does not directly
362 wait for responses to requests.
364 When a request is broadcast on DMaaP, the request is asynchronously picked up by participants
365 of the types required for the Control Loop Instance and those participants manage the life
366 cycle of its control loop elements. Periodically, each participant reports back on the status
367 of operations it has picked up for the Control Loop Elements it controls, together with
368 statistics on the Control Loop Elements over DMaaP. On reception of these participant messages,
369 the CLAMP runtime stores this information to its database.
371 The participant to use on a control loop can be selected from the registered participants
372 in either of two ways:
374 **Runtime-side Selection:** The CLAMP runtime selects a suitable participant from the list of
375 participants and sends the participant ID that should be used in the Participant Update message.
376 In this case, the CLAMP runtime decides on which participant will run the Control Loop Element
377 based on a suitable algorithm. Algorithms could be round robin based or load based.
379 **Participant-side Selection:** The CLAMP runtime sends a list of Participant IDs that may be used
380 in the Participant Update message. In this case, the candidate participants decide among
381 themselves which participant should host the Control Loop Element.
383 This approach makes it easy to scale Control Loop life cycle management. As Control Loop
384 Instance counts increase, more than one CLAMP runtime can be deployed and REST/supervision
385 operations on Control Loop Instances can run in parallel. The number of participants can
386 scale because an asynchronous broadcast mechanism is used for runtime-participant communication
387 and there is no direct connection or communication channel between participants and CLAMP
388 runtime servers. Participant state, Control Loop Instance state, and Control Loop Element
389 state is held in the database, so any CLAMP runtime server can handle operations for any
390 participant. Because many participants of a particular type can be deployed and participant
391 instances can load balance control loop element instances for different Control Loop Instances
392 of many types across themselves using a mechanism such as a Kubernetes cluster.
395 4.3 Sandboxing and API Gateway Support
396 --------------------------------------
398 At runtime, interaction between ONAP platform services and application microservices are
399 relatively unconstrained, so interactions between Control Loop Elements for a given Control
400 Loop Instance remain relatively unconstrained. A
401 `proposal to support access-controlled access to and between ONAP services
402 <https://wiki.onap.org/pages/viewpage.action?pageId=103417456>`_
403 will improve this. This can be complemented by intercepting and controlling services
404 accesses between Control Loop Elements for Control Loop Instances for some/all Control
407 API gateways such as `Kong <https://konghq.com/kong/>`_ have emerged as a useful technology
408 for exposing and controlling service endpoint access for applications and services. When a
409 Control Loop Type is onboarded, or when Control Loop Instances are created in the Participants,
410 CLAMP can configure service endpoints between Control Loop Elements to redirect through an
413 Authentication and access-control rules can then be dynamically configured at the API gateway
414 to support constrained access between Control Loop Elements and Control Loop Instances.
416 The diagram below shows the approach for configuring API Gateway access at Control Loop
417 Instance and Control Loop Element level.
419 .. image:: images/06-api-gateway-sandbox.png
421 At design time, the Control Loop type definition specifies the type of API gateway configuration
422 that should be supported at Control Loop and Control Loop Element levels.
424 At runtime, the CLAMP can configure the API gateway to enable (or deny) interactions between
425 Control Loop Instances and individually for each Control Loop Element. All service-level
426 interactions in/out of a Control Loop Element, except that to/from the API Gateway, can be
427 blocked by networking policies, thus sandboxing a Control Loop Element and an entire Control
428 Loop Instance if desired. Therefore, a Control Loop Element will only have access to the APIs
429 that are configured and enabled for the Control Loop Element/Instance in the API gateway.
431 For some Control Loop Element Types the Participant can assist with service endpoint
432 reconfiguration, service request/response redirection to/from the API Gateway, or
433 annotation of requests/responses.
435 Once the Control Loop instance is instantiated on participants, the participants configure
436 the API gateway with the Control Loop Instance level configuration and with the specific
437 configuration for their Control Loop Element.
439 Monitoring and logging of the use of the API gateway may also be provided. Information and
440 statistics on API gateway use can be read from the API gateway and passed back in monitoring
441 messages to the CLAMP runtime.
443 Additional isolation and execution-environment sandboxing can be supported depending on the
444 Control Loop Element Type. For example: ONAP policies for given Control Loop Instances/Types
445 can be executed in a dedicated PDP engine instances; DCAE or K8S-hosted services can executed
446 in isolated namespaces or in dedicated workers/clusters; etc..
452 The APIs and Protocols used by CLAMP for Control Loops are described on the pages below:
454 #. :ref:`System Level Dialogues <system-level-label>`
455 #. :ref:`The CLAMP Control Loop Participant Protocol <controlloop-participant-protocol-label>`
456 #. :ref:`REST APIs for CLAMP Control Loops <controlloop-rest-apis-label>`
459 6 Design and Implementation
460 ===========================
462 The design and implementation of TOSCA Control Loops in CLAMP is described for each executable entity on the pages below:
464 #. :ref:`The CLAMP Control Loop Runtime Server <clamp-controlloop-runtime>`
465 #. :ref:`CLAMP Control Loop Participants <clamp-controlloop-participants>`
466 #. :ref:`Managing Control Loops using The CLAMP GUI <clamp-gui-controlloop>`