Page History

...

It is possible to generate policy types using MDD (Model Driven Development) techniques. Policy types are expressed using a DSL (Domain Specific Language) or a policy specification environment for a particular application domain. For example, policy types for specifying SLAs could be expressed in a SLA DSL and policy types for managing SON features could be generated from a visual SON management tool. The ONAP Policy framework provides an API that allows tool chains to create policy types. SDC uses this approach for generating Policy Types in the Policy Framework, see the Model driven Control Loop Design page.

2.2.1.2 Programming Policy Type Implementations

For skilled developers, the most straightforward way to create a policy type is to program it. Programming a policy type might simply mean creating and editing text files, thus manually creating the TOSCA Policy Type Yaml file and the policy type implementation for the policy type.

A more formal approach is preferred. For policy type implementations, programmers use a specific Eclipse project type for developing each type of implementation, a Policy Type Implementation SDK. The project is under source control in git. This Eclipse project is structured correctly for creating implementations for a specific type of PDP. It includes the correct POM files for generating the policy type implementation and has editors and perspectives that aid  programmers in their work.

2.2.2 Policy Design

The PolicyCreation function of PolicyDevelopment creates policies from a policy type.  The information expressed during policy type design is used to parameterize a policy type to create an executable policy. A service designer and/or operations team can use tooling that reads the TOSCA Policy Type specifications to express and capture a policy at its highest abstraction level. Alternatively, the parameter for the policy can be expressed in a raw JSON or YAML file and posted over the policy design API described on the Model driven Control Loop Design page.

A number of mechanisms for  policy creation are supported in ONAP. The process in PolicyDevelopment for creating a policy is the same for all mechanisms. The most general mechanism for creating a policy is using the RESTful Policy Design API, which provides a full interface to the policy creation support of PolicyDevelopment. This API may be exercised directly using utilities such as curl. PolicyDevelopment provides a command line tool that is a loose wrapper around the API. It also provides a general purpose Policy GUI in the ONAP Portal for policy creation, which again is a general purpose wrapper around the policy creation API. The Policy GUI can interpret any TOSCA Model ingested and flexibly presents a GUI for a user to create policies from. The development of these mechanisms will be phased over a number of ONAP releases.

A number of ONAP components use policy in manners which are specific to their particular needs. The manner in which the policy creation process is triggered and the way in which information required to create a policy is specified and accessed is specialized for these ONAP components.

The following subsections outline the mechanisms for policy creation and modification supported by the ONAP Policy Framework.

2.2.2.1 Policy Design in the ONAP Policy Framework

Policy creation in PolicyDevelopment follows the general sequence shown in the sequence diagram below. An API_USER is any component that wants to create a policy from a policy type. PolicyDevelopment supplies a REST interface that exposes the API and also provides a command line tool and general purpose client that wraps the API.

The SDC GUI supports several types of policies that can be captured at design time. DCAE micro service configuration policies can be onboarded via the DCAE-DS (DCAE Design Studio).

@startuml
participant DCAE-DS <<API_User >>

@startuml
participant API_User

box "PolicyDesign" #LightBlue
  participant PolicyDesign
  database PolicyDBPolicyTypeDesign
end box

autonumber

APIONAP_UserGUI --> PolicyDesignPolicyTypeDesign : Get Policy TypeTemplate Reference
PolicyDesignPolicyTypeDesign --> PolicyDBONAP_GUI : GetReturn Policy Type Artifact and Metadata
PolicyDesign Template Reference and Metadata
ONAP_GUI --> PolicyTypeDesign : Get Policy Reference
PolicyTypeDesign --> APIONAP_UserGUI : Return Policy Type Reference and Metadata
API_User
DCAE-DS --> PolicyDesignPolicyTypeDesign : Get Policy Type Reference and Metadata
PolicyDesignPolicyTypeDesign --> PolicyDB : Get Policy Type Metadata
alt Policy Type Artifact exists
  PolicyDesignPolicyTypeDesign --> API_UserDCAE-DS : Return Policy Type Reference and Metadata
else Policy Artifact does not exist
  PolicyDesign exist
  PolicyTypeDesign --> DCAE-DS : Return New Policy Type Reference and Empty Metadata
end

DCAE-DS --> DCAE-DS : Create Policy Type Editing and Generation Session
activate DCAE-DS
deactivate DCAE-DS

DCAE-DS --> API_UserPolicyTypeDesign : ReturnCreate New Policy ReferenceType and Empty Metadata
end

API_UserPolicyTypeDesign --> API_UserDCAE-DS : Create Policy Editing and Generation Session
activate API_User
loop
  API_User --> PolicyDesign : Use Policy Type specification get Policy Parameters from user
end
API_User --> PolicyDesign : Create Policy
PolicyDesign --> PolicyDesign : Create Policy
activate PolicyDesign
deactivate PolicyDesign
PolicyDesign --> PolicyDB : Save Policy Artifact and Metadata
PolicyDesign --> API_User : Policy Creation Result
deactivate API_User
@enduml

A PolicyDevAPIUser first gets a reference to and the metadata for the Policy type for the policy they want to work on from PolicyDevelopment. PolicyDevelopment reads the metadata and artifact for the policy type from the database. The API_User then asks for a reference and the metadata for the policy. PolicyDevelopment looks up the policy in the database. If the policy already exists, PolicyDevelopment reads the artifact and returns the reference of the existing policy to the PolicyDevAPIUser with the metadata for the existing policy. If the policy does not exist, PolicyDevelopment creates and new reference and metadata and returns that to the API_User.

The PolicyDevAPIUser may now proceed with a policy specification session, where the parameters are set for the policy using the policy type specification. Once the PolicyDevAPIUser is happy that the policy is completely and correctly specified, it requests PolicyDevelopment to create the policy. PolicyDevelopment creates the policy, stores the created policy artifact and its metadata in the database.

2.2.2.2 Model Driven VF (Virtual Function) Policy Design via VNF SDK Packaging

VF vendors express policies such as SLA, Licenses, hardware placement, run-time metric suggestions, etc. These details are captured within the VNF SDK and uploaded into the SDC Catalog. The SDC Distribution APIs are used to interact with SDC. For example, SLA and placement policies may be captured via TOSCA specification. License policies can be captured via TOSCA or an XACML specification. Run-time metric vendor recommendations can be captured via VES Standard specification.

The sequence diagram below is a high level view of SDC-triggered concrete policy generation for some arbitrary entity EntityA. The parameters to create a policy are read from a TOSCA Policy specification read from a CSAR received from SDC.

Generation Result


@enduml

The GUI implementation in another ONAP component such as SDC or the DCAE-DS uses the API_User API to create and edit ONAP policies. Note that this puts an impact on those components.

2.2.1.2 Programming Policy Type Implementations

For skilled developers, the most straightforward way to create a policy type is to program it. Programming a policy type might simply mean creating and editing text files, thus manually creating the TOSCA Policy Type Yaml file and the policy type implementation for the policy type.

A more formal approach is preferred. For policy type implementations, programmers use a specific Eclipse project type for developing each type of implementation, a Policy Type Implementation SDK. The project is under source control in git. This Eclipse project is structured correctly for creating implementations for a specific type of PDP. It includes the correct POM files for generating the policy type implementation and has editors and perspectives that aid  programmers in their work

2.2.2 Policy Design

The PolicyCreation function of PolicyDevelopment creates policies from a policy type.  The information expressed during policy type design is used to parameterize a policy type to create an executable policy. A service designer and/or operations team can use tooling that reads the TOSCA Policy Type specifications to express and capture a policy at its highest abstraction level. Alternatively, the parameter for the policy can be expressed in a raw JSON or YAML file and posted over the policy design API described on the Model driven Control Loop Design page.

A number of mechanisms for  policy creation are supported in ONAP. The process in PolicyDevelopment for creating a policy is the same for all mechanisms. The most general mechanism for creating a policy is using the RESTful Policy Design API, which provides a full interface to the policy creation support of PolicyDevelopment. This API may be exercised directly using utilities such as curl. PolicyDevelopment provides a command line tool that is a loose wrapper around the API. It also provides a general purpose Policy GUI in the ONAP Portal for policy creation, which again is a general purpose wrapper around the policy creation API. The Policy GUI can interpret any TOSCA Model ingested and flexibly presents a GUI for a user to create policies from. The development of these mechanisms will be phased over a number of ONAP releases.

A number of ONAP components use policy in manners which are specific to their particular needs. The manner in which the policy creation process is triggered and the way in which information required to create a policy is specified and accessed is specialized for these ONAP components.

The following subsections outline the mechanisms for policy creation and modification supported by the ONAP Policy Framework.

2.2.2.1 Policy Design in the ONAP Policy Framework

Policy creation in PolicyDevelopment follows the general sequence shown in the sequence diagram below. An API_USER is any component that wants to create a policy from a policy type. PolicyDevelopment supplies a REST interface that exposes the API and also provides a command line tool and general purpose client that wraps the API.

@startuml
participant API_User

@startuml

participant SDC
participant DMaaP

box "PolicyDesign" #LightBlue
  participant PolicyDesign
 PolicyDistribution <<  database PolicyDB
end box

autonumber

API_User >>
  participant PolicyDesign
end box

autonumber
PolicyDistribution --> PolicyDesign : Get Policy Type Reference
PolicyDesign --> PolicyDB : Get Policy Type Artifact and Metadata
PolicyDesign --> DMaaPAPI_User : SubscribeReturn forPolicy SDCType Notifications\nonReference Entriesand of Interest
SDCMetadata
API_User --> DMaaPPolicyDesign : NewGet EntryPolicy ofReference Interest:and EntityAMetadata
DMaaPPolicyDesign --> PolicyDistributionPolicyDB : Get NewPolicy EntryMetadata
alt ofPolicy Interest:Artifact EntityA

PolicyDistributionexists
  PolicyDesign --> PolicyDesignAPI_User : GetReturn Policy Reference and Metadata
else Policy Artifact does not exist
  PolicyDesign --> PolicyDistributionAPI_User : Return New Policy Reference and Empty Metadata
end

PolicyDistributionAPI_User --> PolicyDistribution API_User : Create Policy Editing and Generation Session
activate PolicyDistributionAPI_User
loop
  PolicyDistributionAPI_User --> PolicyDesign : Use Policy Type specification toget read\nPolicyPolicy Parameters from TOSCA specification in CSAR
end
PolicyDistribution user
end
API_User --> PolicyDesign : Create Policy
PolicyDesign --> PolicyDesign : Create Policy
activate PolicyDesign
deactivate PolicyDesign
PolicyDesign --> PolicyDesignPolicyDB : GenerateSave Policy Artifact and Metadata
PolicyDesign --> PolicyDistributionAPI_User : Policy GenerationCreation Result
deactivate PolicyDistributionAPI_User

@enduml

PolicyDesign uses the PolicyDistribution component for managing SDC-triggered  policy creation and update requests. PolicyDistribution is an API_User, it uses the Policy Design API for policy creation and update. It reads the information it needs to populate the policy type from a TOSCA specification in a CSAR received from SDC and then uses this information to automatically generate a policy.

Note that SDC provides a wrapper for the SDC API as a Java Client and also provides a TOSCA parser. See Policy Platform - SDC Service Distribution Software Architecture

In Step 4 above, the PolicyDesign must download the CSAR file. If the policy is to be composed from the TOSCA definition, it must also parse the TOSCA definition.

A PolicyDevAPIUser first gets a reference to and the metadata for the Policy type for the policy they want to work on from PolicyDevelopment. PolicyDevelopment reads the metadata and artifact for the policy type from the database. The API_User then asks for a reference and the metadata for the policy. PolicyDevelopment looks up the policy in the database. If the policy already exists, PolicyDevelopment reads the artifact and returns the reference of the existing policy to the PolicyDevAPIUser with the metadata for the existing policy. If the policy does not exist, PolicyDevelopment creates and new reference and metadata and returns that to the API_User.

The PolicyDevAPIUser may now proceed with a policy specification session, where the parameters are set for the policy using the policy type specification. Once the PolicyDevAPIUser is happy that the policy is completely and correctly specified, it requests PolicyDevelopment to create the policy. PolicyDevelopment creates the policy, stores the created policy artifact and its metadata in the databaseIn Step 9 above, the PolicyDesign must send back/publish status events to SDC such as DOWNLOAD_OK, DOWNLOAD_ERROR, DEPOLY_OK, DEPOLY_ERROR, NOTIFIED.

2.2.2.

...

2 Model Driven VF (Virtual Function) Policy Design via

...

VNF SDK Packaging

VF vendors express policies such as SLA, Licenses, hardware placement, run-time metric suggestions, etc. These details are captured within the VNF SDK and uploaded into the SDC Catalog. The SDC Distribution APIs are used to interact with SDC. For example, SLA and placement policies may be captured via TOSCA specification. License policies can be captured via TOSCA or an XACML specification. Run-time metric vendor recommendations can be captured via VES Standard specification.

The sequence diagram below is a high level view of SDC-triggered concrete policy generation for some arbitrary entity EntityA. The parameters to create a policy are read from a TOSCA Policy specification read from a CSAR received from SDCThe SDC GUI supports several types of policies that can be captured during design time. DCAE micro service configuration policies can be onboarded via the DCAE-DS (DCAE Design Studio).

@startuml

participant SDC
participant DMaaP

box "PolicyDesign" #LightBlue
  participant PolicyDistribution ONAP_GUI<< <<APIAPI_User >>

box "PolicyDesign" #LightBlue
  participant ConcretePolicyDesignPolicyDesign
end box

autonumber

ONAP_GUIPolicyDistribution --> DMaaP : Subscribe for SDC Notifications\non Entries of Interest
SDC --> ConcretePolicyDesignDMaaP : New GetEntry Policyof TemplateInterest: ReferenceEntityA
ConcretePolicyDesignDMaaP --> ONAP_GUIPolicyDistribution : ReturnNew PolicyEntry Templateof Reference and Metadata
ONAP_GUIInterest: EntityA

PolicyDistribution --> ConcretePolicyDesignPolicyDesign : Get Policy Reference
ConcretePolicyDesignPolicyDesign --> ONAP_GUIPolicyDistribution : Return Policy Reference and Metadata

ONAP_GUIPolicyDistribution --> ONAP_GUIPolicyDistribution : Create Policy Editing and Generation Session
activate ONAP_GUIPolicyDistribution
loop
  ONAP_GUIPolicyDistribution --> ConcretePolicyDesignPolicyDesign : Set Models, Rules, Tasks and Flow for Policy
end
ONAP_GUI Use Policy Type specification to read\nPolicy Parameters from TOSCA specification in CSAR
end
PolicyDistribution --> ConcretePolicyDesignPolicyDesign : Generate Policy
ConcretePolicyDesignPolicyDesign --> ONAP_GUIPolicyDistribution : Policy Generation Result
deactivate ONAP_GUI
@endumlPolicyDistribution

@enduml

PolicyDesign uses the PolicyDistribution component for managing SDC-triggered  policy creation and update requests. PolicyDistribution is an API_User, it uses the Policy Design API for policy creation and update. It reads the information it needs to populate the policy type from a TOSCA specification in a CSAR received from SDC and then uses this information to automatically generate a policy.

Note that SDC provides a wrapper for the SDC API as a Java Client and also provides a TOSCA parser. See Policy Platform - SDC Service Distribution Software Architecture

In Step 4 above, the PolicyDesign must download the CSAR file. If the policy is to be composed from the TOSCA definition, it must also parse the TOSCA definition.

In Step 9 above, the PolicyDesign must send back/publish status events to SDC such as DOWNLOAD_OK, DOWNLOAD_ERROR, DEPOLY_OK, DEPOLY_ERROR, NOTIFIEDThe GUI implementation in another ONAP component such as SDC or the DCAE-DS uses the API_User API to create and edit ONAP policies. Note that this puts an impact on those components.

2.2.2.4 Scripted Model Driven Policy Design

...