n Data Bus Closed Loc Passive Data Anomalies Policy Engine Analytics Data Collection & Distribution Design Platform Telemetry& Usage (data) Events Configure Apps, VFs & Infrastructure Templates Control & Events Design Execution FIGURE 8.13 Control loop automation for network management in the Network Cloud. (From ECOMP [Enhanced Control, Orchestration, Management and Policy] Architecture White Paper, 2016, https://www. google.com/#q=ecomp+white+paper.) service composition in a manner that is verifiable at different stages of the software lifecycle. The goal is to create a catalog, which will provide readymade templates (e.g. VM restart, VM migrate, VM rebuild, VM evacuate, etc.) that can be customized for different services through a model- driven approach. 8.3.4.2 CLAMP System Architecture The CLAMP architecture uses all the relevant ONAP components to realize a closed loop in action. Once an application design is developed and distributed to ONAP, the following operations take place (Figure 8.14): 1. DCAE local (at the edge of the network) collects data from the relevant virtual functions and publishes the data into the data bus. Analytics MSs subscribing to the data are then applied to compute events. A MS may involve a simple anomaly detector that looks for changes in the signal. The MS may be placed in local or regional cloud centers depending on the level of performance required and the resources available. MSs may also be chained together by DCAE. 3. Per rules acquired and interrupted by the policy engine, the DCAE platform outputs a signature once it encounters an anomaly and publishes that to the data bus. 4. The policy engine subscribes to that signature and recommends the next best action. The action is typically predefined by the designer of the service, and may include a simple noti- fication to the operation team or some device reboot. The recommended action is published back to the data bus. 5. Per service design, the relevant controller (application, network, or infrastructure) picks up the action