Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

PAGE STATUS: UNDER CONSTRUCTION

STATUS: Project Approved (next step is Architecture Approval)

AAF (Application Authorization Framework):

1 High Level Component Definition and Architectural Relationships 



The CLAMP functional entity provides the capability to manage runtime control loops.  It provides the capability to

  • Create control loop from DCAE blueprint sent by SDC
  • Create configuration policy from the policy Tosca sent by SDC
  •  Configure DCAE applications of the control loop
  • Associate µService configuration policies to the DCAE application
  • Configure the operations to be taken by the control loop (by creating/updating/deleting operational policies)
  • Deploy/un-deploy control loop flow (blueprints) to DCAE
  • Control loop visualization. 

CLAMP relies on Policy to communicate to App-C/VF-C/SDN-C/SO in runtime, hence these are not part of CLAMP 

2. API definitions

CLAMP provides the following interfaces:

Interface NameInterface Definition Interface Capabilities
CLAMPE-1Control Loop Lifecycle Management Interface.   A user interface for:
  • Selecting the control loop flow
  • Entering configuration policy parameters
  • Entering operational policy parameters
  • Managing life cycle of DCAE control flow blueprint 
CLAMPE-2Control loop dashboard.  User interface to show the overall status of the control loop through DMAAP events

 Display and update:

  • Events received and actions taken on the control loop.

Note:   xxxI interface is a Component internal interface.  xxxxE interface is a component external interface

The current API documents can be found at:

AAF Consumes no Interfaces:

Interface NamePurpose Reason For Use



3. Component Description:

A more detailed figure and description of the component.

<< For later inclusion >>

4. known system limitations

Runtime: None

Clamp data redundancy is dependent on Kubernetes and the persistent volume.

Clamp application redundancy HA relies on Kubernetes

5. Used Models

AAF uses the following models:

  • Service model (received from SDC)
  • VNF model (received from SDC)
  • Policy Model.


6. System Deployment Architecture


AAF consists of x containers:

  • CLAMP container
  • MariaDB container
  • Kibana container
  • E_Search container
  • LogStash container 

7. New Capabilities in this Release

This release, AAF adds the following Capabilities:

  • AAF Locator differentiates public Fully Qualified Domain Name (FQDN) from Kubernetes FQDN

    • Internal Kubernetes FQDN generated when client declares its Container Namespace
    • Public FQDN are accessible for both:
      • GUIs/Management outside Cluster
      • Non-ONAP entities outside the Cluster
      • Other Clusters
  • Improved documentation and enhanced configuration
    • Example "Helm" init containers to setup Volumes
  • Refactored maintenance processes online for Open Source (meaning non company specific), including
    • Analysis of expiring Creds and Roles
    • Generation of Approval records
    • Notification of Approvals, Creds and Roles in an external company configurable way.

8. References

  1.  AAF Overview & User Guide: https://onap.readthedocs.io/en/latest/submodules/clamp.git/docs/index.html 
  2. AAF internal interfaces:  https://onap.readthedocs.io/en/latest/_downloads/d3c9f924c6586fe411d40a05ad9b1bb7/swagger.pdf 


  • No labels